This event marks the culmination of nearly three years of monumental effort by the core development team, who have undertaken a complete architectural redesign and rewritten Kaspa’s core code from Golang to Rust, focusing on performance optimization across all possible fronts simultaneously. Thanks to this feat, Kaspa will become, by a wide margin, the fastest pure Proof-of-Work (PoW) coin in history, while maintaining the highest level of decentralization and transaction processing and confirmation speed in a permissionless, asynchronous system.
Moreover, this block generation speed, combined with linking blocks not in a chain but in a directed acyclic graph, creates a truly unique multi-leader consensus mechanism. This consensus has the potential to serve as the foundation for achieving the holy grails of crypto: a security budget, MEV (Miner Extractable Value) avoidance, and the implementation of reliable decentralized oracles.
At the same time, the code is written in such a way that running a full Kaspa node is possible on ordinary household PCs with standard internet connections, which is itself a unique feature for crypto projects offering this level of capability. It fully aligns with, and realizes in practice Satoshi’s vision of complete autonomy and self-sovereignty for every network participant, from large corporations and governments to ordinary individuals.
Last but not least, a new WASM interface for RPC requests was created along the way, greatly simplifying how wallets and apps interact with Kaspa nodes. It sparked a surge in Kaspa-compatible wallets, thanks to the sub-team that simultaneously worked on the node’s WASM subsystem and developed the Kaspa-NG wallet (https://kaspa-ng.org/) to replace the retiring Kaspa web and KDX wallets. People are gathering to watch and celebrate the transition online, so join us:
- @Kaspa Silver 𐤊 – Watch party: https://www.youtube.com/live/lLuT89eXmHY
- Blockchain Banter X Spaces: https://x.com/levendipro/status/1918000727378587861?t=m8Y4n7ycbtA6FkZtZcz7kQ
If, for some reason, you haven’t yet upgraded to the hardfork-ready node version, here’s the link to it: https://github.com/kaspanet/rusty-kaspa/releases/latest, and here’s the link to the post-fork working version of the Kaspa-stratum bridge which enables solo mining: https://github.com/aglov413/kaspa-stratum-bridge/releases/tag/v1.3.0
Today, without any doubt, will go down in crypto history as the day when the efforts of human intellect once again proved that the bastions of what seemed impossible inevitably fall under the pressure of talent and selfless dedication!
_____________________________________________________________________________________
X Post excerpts from Lead Developer, Michael Sutton about Crescendo
Kaspa’s 10 bps crescendo upgrade, activated today on mainnet, allows the innovation and scalability of the Ghostdag protocol (@hashdaget al) to truly shine for the first time. While the theory behind this multi‑leader, parallel‑structured DAG protocol has been implemented at 1 bps as well, a 1000‑millisecond block time is still sufficiently above modern internet RTT; thus, by tightening latency and network assumptions one can imagine a linear blockchain structure at 1 bps as well (cf. Solana’s 400 ms block time with a linear structure). Increasing the block rate to 10 per second, achieved by reducing block time to 100 ms (< 200 ms ≈ global RTT), can only be secure with a consensus protocol that inherently allows parallelism = multi‑leader consensus. Passing the RTT threshold is thus a qualitative, not merely a quantitative, leap. Link
A brain dump of all things crescendo, what’s included, what are the benefits… Link
Increasing the block per seconds from 1 to 10 bps while keeping block capacity ~fixed (more on that later). Throughput: obviously, transaction throughput increases. How much? almost tenfold but not exactly 10x. Having more parallel blocks increases the collision rate to some degree.
On TN10 and with current mempool txn selection policy, we observe ~80-90% efficiency (i.e., 80-90% of the txns are unique). If the mempool gets over congested and demand significantly exceeds capacity, this efficiency value goes towards 100%. So to conclude, TPS is increasing 8-9x. The missing info is mainnet average DAG width post-activation vs. today. Mempool policies can be finetuned in the coming future without a hardfork based on such real-world data. Frequency: average block time (=interval between blocks) is being reduced from 1 second to 100 milliseconds. This means blink-of-an-eye txn inclusion time. A transaction need not propagate to the whole network in order to be included; for instance, it can reach miners in its continent in 50ms and get mined after 200ms. The frequency also decreases post-inclusion confirmation times due to the increased density of the mining sampling process. Not to say confirmation times decrease tenfold, because they are now dominated by block latency which hasn’t changed. Rather, by back-of-the-envelope calculations, they have improved 30% (for the advanced: the tail of the Poisson governing worst-case DAG width diminishes faster, thus K can be set relatively lower, from 18 (1bps) to 124 (for 10bps) and not to 180 as one might expect).
Block parallelism: block parallelism increases with the block rate, and that, contrary to what you might think, is good. Despite collisions being slightly increased due to block parallelism, parallelism is crucial for creating a more fair system. It means there isn’t a monopoly of a single winning miner per round, but rather blocks must compete and make wise and competitive decisions within the latency round. The implications can be huge and far-reaching.
Oracle systems and MEV kickback auctions are some of the preliminary efforts. Going more into this is out-of-scope. I also need to justify why finance is becoming more relevant post-crescendo… assuming that’s the case, I think that even without implementing MEV kickback designs explicitly in consensus (yet), the mere intra-round “chaos” of the parallel DAG at 10 bps will already make economic manipulation much harder than in other, leader-based systems.
Other changes included in crescendo. How do I start, there’s so much.
KIP-9 is integrated into consensus, baking our unique state bloat solution inherently into the system. By the way, we call this “harmonic” sub-protocol the name STORM (for STORage Mass). In the process, KIP-9 was extended to include UTXO storage plurality (i.e., taxing a UTXO which consumes more storage appropriately), making it more futureproof.
KIP-10 adds support for basic covenants and additive addresses.
KIP-13 regulates transient storage requirements more strictly. Smart contract-related changes: KIP-14 enables payloads, allowing txns to carry arbitrary data (e.g., smart contract function calls).
KIP-15 is a technically minor upgrade — comprising one line of code — but enables a conceptually meaningful feature, allowing nodes to archive only transactions and prove their sequencing and acceptance trustlessly. This is significant for allowing pre-zk era L2 nodes to store and prove full SC execution to new syncers at a reasonable cost—hence effectively making such systems possible right after crescendo. The change proposed is a tiny subset of the zk design proposal (see Kaspa research forum—based rollups design posts) where such a mechanism was proposed as a necessary requirement for zk systems to operate over Kaspa, and turned out to have significant value also pre-zk. Overall, this means that preliminary SC L2s are possible over post-crescendo Kaspa (or Kaspa 2.0 as @hashdag refers to it internally) with sufficient trust models.
Crescendo is an historical moment in permissionless distributed systems, showing that a multi-leader consensus real-world system can achieve block times shorter than global internet round-trip time (RTT) without artificially suppressing the P2P network size or assuming proximity. Link