Kaspa Vision

The consensus stack of Kaspa is designed to address what we believe to be leading challenges for the second decade of crypto. As the technology matures and its adoption and integration with other web applications gain momentum, we identify two primary vectors which require a deep revisit of the base consensus: the speed of transaction-inclusion in the ledger, and the control over transaction-ordering in the ledger.

We postulate that instant time-to-inclusion (a.k.a. first confirmation) in the ledger is of primary importance to user- and developer-experience, and to integration with other web applications, as well as fast (probabilistic) finality. Kaspa optimizes for minimizing the latency imposed by the consensus engine on transaction flow and user experience. Additionally, we contend that the ability of peripheral nodes that control a small fraction of the hashrate to mine blocks very frequently, in an asynchronous fashion, is key to mitigating serious frontrunning and MEV threats referring to the ability of miners, and of trading bots, to manipulate transaction ordering and gain an unfair and occasionally undetected advantage over ordinary users. Sub-second block times enable pre-trade privacy, and pre-trade stealth transactions, to protect the users from such manipulations.

Providing instant confirmation is not a trivial task, less of course one is willing to compromise on the principles of decentralization, or to operate under strong assumptions on the network’s topology and with minimal safety margins. Kaspa took the hard path of designing the system based off Satoshi’s paradigm and first principles. There has yet to be, in the blooming field of cryptocurrencies, a serious attempt at following Satoshi’s v1 protocol, and proving and providing new capabilities based yet on the same fundamentals. While Bitcoin is becoming the Internet’s ultimate reserve asset, we believe there is still demand—and an urgent one, at that—for an implementation of Satoshi’s original vision: a peer-to-peer electronic cash system.

Since transaction ordering is the main challenge of any consensus protocol, Kaspa’s base layer focuses on becoming a fast and scalable transaction sequencing (a.k.a. proof-of-publication) engine. The base consensus will therefore maintain the state of payments only (a.k.a the UTXO set), whereas computing the more general and expressive state will be outsourced to Layer Two operations. This should be done by adopting the thought process and innovation led by several Ethereum researchers and developers who are building rollups. The rollups technology reduces the cost of running base consensus nodes by decoupling computation from data availability.

In fact, a rollups-centric Ethereum will fragment the network, hinder composability, and dramatically change the underlying assumptions and dynamics. Smooth operation between the siloed rollups will require special liquidity providers that serve the purpose of bridging the gap—specifically, providing instant confirmation to circumvent the prohibitive finality periods required for securing optimistic rollups. Providing these rollups with a shared scalable transaction sequencing layer, allowing shorter finality times, enabling stealth pre-trade transactions which protect against censoring miners, and bootstrapping an ecosystem of cross-silo communication, is another natural way in which Kaspa network aims to solve a timely pain point for crypto projects and users.

Join & Follow the COmmunity

We are a growing community and always looking for energetic people to join the project.  If you are a coder, marketer, vlogger, community manager or other, join Discord and say, “hi!”


Manual donations dev-fund-address: kaspa:precqv0krj3r6uyyfa36ga7s0u9jct0v4wg8ctsfde2gkrsgwgw8jgxfzfc98

Mining dev-fund-address: kaspa:pzhh76qc82wzduvsrd9xh4zde9qhp0xc8rl7qu2mvl2e42uvdqt75zrcgpm00


The wallet is managed by 4 members of the community (msutton, Tim, The SheepCat and demisrael) who were publicly voted in to become the Treasurers.

The is a multi-signature wallet with a 2/4 signing formula, so it needs at least 2 of the Treasurers to sign the spending transaction for it to become commutable. All spendings are published in the #devfund channel and are performed according to the results of public votes in either #funding-pools or #votes channels