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

 

The Testnet-11 (TN11) 10BPS network has now been running continuously for nearly a year. The latest testnet-11 release at https://github.com/kaspanet/rusty-kaspa/releases/tag/v0.15.4-rc1 contains all the optimizations that the team has been working this past year. We believe the optimization state of the node is very close to what it will be on mainnet and so our development will now focus on Enhanced User Experience. This is where you, the pools, the exchanges and other integrators come in. We would like to invite you to run a testnet-11 node and try your pool/exchange/other software on it to check how your integration behaves in the 10BPS network. We would love to hear from you, the good feedback and any opportunities for improvement.

Make sure that you get the updated message.proto and rpc.proto from the rusty-kaspa repo at https://github.com/kaspanet/rusty-kaspa/tree/master/rpc/grpc/core/proto
Working with the TN11 network requires using the latest proto available.

• 8-core CPU
• 16 GB RAM
• 256 GB SSD
• 5MB network

If you are using a higher-spec node for your mainnet node, please continue to try that same spec out when trying out this node. If you are using specs lower than the above in mainnet, please use at least the above specs for your TN11 testing.

Note: These minimum recommended specifications are subject to change as we gather feedback from mainnet node operators about their experience running a TN11 node.

Download the binary from the release at https://github.com/kaspanet/rusty-kaspa/releases/tag/v0.15.4-rc1

To run the node on TN11, use:

./kaspad --utxoindex --testnet --netsuffix=11 --disable-upnp --rpclisten=0.0.0.0

If you’re running your software on the same machine as the node, use --rpclisten=127.0.0.1

You may want to compile the node from source. To do so, follow the instructions at here to setup the dependencies https://github.com/kaspanet/rusty-kaspa?tab=readme-ov-file#installation
And then run your node with:

cargo run --bin kaspad --release -- --utxoindex --testnet --netsuffix=11 --disable-upnp --rpclisten=0.0.0.0

If you’re running your software on the same machine as the node, use --rpclisten=127.0.0.1

Written by Shai Wyborski

Hi $kas, meet @coderofstuff_ from the rusty crew! Coder is a self-taught developer in the Great White North working in the tech industry for over a decade. Coder started making contributions to the Kaspa echosphere since as early as 2022, around mid 2023, he made his first contribution to the rust code base, and has been growingly involved ever since.

Coder was first compelled to contribute by one of the most powerful powers known to man: irritation. The only block explorer available at the time was far from optimized, providing slow loading times of up to 10 seconds, a terrible annoyance for users and miners who want to keep track of their balance. Coder decided to take the initiative. He analyzed the causes for the slowdown, and worked with Rob (lAmeR1 on Discord) to put up a pull request that greatly improved the waiting times. This first contribution compelled him to use his skillset to help out and make things better for himself and the community in general. Among his contribution to the community is a CSV report generator (https://kaspa-transaction-report.vercel.app/) and an ASIC ROI calculator (https://kas-breakeven-calc.vercel.app/) as well as a long list of fixes, reviews and improvements to preexisting ecosystem software. Coder also supports third party integrations of exchanges, wallets and pools. He supported the integrations of Kaspa into Uphold, ByBit, OKX web3 wallet, XT, Poloniex, Antpool and more.

I asked Coder to choose the favourite three of his many contributions.

Third favorite: Local address management
This contribution fixes an issue (discovered in the first run of TN11) that prevented nodes from sharing their addresses, harming network discoverability and connectivity. It also lays the foundation for the client address management.
While not the most impressive contribution under Coder’s belt, he is particularly fond of it because it was his first contribution to the Rusty-kaspa codebase.
Relevant PRs:
https://github.com/kaspanet/rusty-kaspa/pull/222
https://github.com/kaspanet/rusty-kaspa/pull/227
https://github.com/kaspanet/rusty-kaspa/pull/230

Second favorite: Optimize P2P block processing latency
Whenever a block is added to the DAG, it goes a long process. A part of the process is validating the block, but there are many other time consuming tasks that follow, such as computing the GHOSTDAG ordering. In the old design, a node will only transmit the block to its peers once this process is done. This means that blocks are retransmitted much later than they could have. In 1BPS, this is not an issue, but in 10BPS this added latency becomes noticeable. This contribution refactors the block processing pipeline so that blocks are retransmitted as soon as possible.
Coder likes this contribution because it is the first contribution that required him to understand how the block processing mechanism works, and some of the components of Kaspa’s complicated consensus layer.
Relevant PR:
https://github.com/kaspanet/rusty-kaspa/pull/295

Favorite: Transaction relay throttling on high P2P load
This contribution implements the logic that limits the resources available to the peer-to-peer network when loads get high (such as when a lot of people are running Rothschild).
Coder likes this contribution because it was highly important for making Testnet 11 run smoothly, and because it was a chance to take relevant load off @MichaelSuttonIL so he could focus on other things.

Alongside direct contributions to the Rusty kaspa client, Coder is driving the work to get Rust 1BPS onto mainnet, negotiating with 3rd parties and helping them out to try their tools on the rust node.

Besides contributing code, Coder fosters an impressive habit of reviewing all changes and additions to the codebase (which anyone who ever worked on a large codebase would know is extremely impressive). He does so to maintain a broad and deep understanding of the codebase, and in doing so he improves on the already stringent code-review standard the Rusty crew is committed to. He is also devoted to tracking all node-related issues that come up in discussions, so that they could be tackled down the line.

Coder was first exposed to Kaspa by following @SonOfATech, finding that the Kaspa mining content piqued his curiousity. In his words: “The reasons SOAT mentioned for why Kaspa was different from other coins stuck to me: “It (Kaspa) has pedigree in the developers. It’s built from the ground up – it’s not a fork. It has a specific use case – speed of transactions”. I was just a hobbyist miner back then (still am), so anything that was green that had a chance of making profits was interesting to me. I joined the Kaspa Discord, put my mining rigs on Kaspa and started immersing myself with the tech.”

When asked about his motivations to do so, Coder states two of them: “I have stake in the coin because I was mining and holding it too, so I might as well do what I can to try to improve things. My other motivation for contributing is the continuous learning that comes with it. Reading the code base and working with really big-brained folks pushes me to improve further. I joined for the mining, but I stayed for the learning.”

Coder’s word of advice for upcoming developers who want to get involved with Kaspa are: “even if you don’t have all the skills yet, you can start immersing yourself by:
1. Trying to compile the rust codebase locally,
2. Going over GitHub Issues and Pull Requests in different Kaspa project repositories, and
3. Going over to Discord and checking the messages that come up in #research and #development channels.

Salamat!”

If you want to follow Coder’s work, keep on eye on his Github profile:
HTTPS://github.com/coderofstuff

From a Concept to a Cutting-Edge Deployment

An Evolution, Not a Replication

Those who follow Kaspa understand the monumental work the developers are undertaking. It’s far from just another entry in the crowded space of crypto-nonsense; it’s not another Bitcoin clone, meme token, or even a blockchain; it’s a project set on a course to redefine the foundations of crypto technology and, by extension, the financial ecosystem.

Yet, there’s a narrative out there, fueled by a mix of misunderstanding, hype, and the fast-paced expectations common in the crypto world, that paints Kaspa’s progress as slow. But let’s be clear: The past eighteen months have been anything but stagnant for Kaspa. This period has been marked by a genuine push towards innovation, the application of cutting-edge scientific methods, and significant advancements, all of which together define the Kaspa standard.

A group of approximately 20 developers is central to this transformative journey. Through their collaborative efforts, Kaspa has experienced significant changes in its operations, carving a path for a future where scalability and efficiency in crypto are optimized and expected.

This rapid evolution and substantial work achieved in just a year and a half spotlight the commitment and expertise behind Kaspa, challenging any notions of slow progress and emphasizing the project’s role in setting new benchmarks for technological excellence in the cryptosphere.

The Rust Rewrite

In what’s commonly referred to as the Rust rewrite, the developers have realized a comprehensive overhaul of Kaspa’s codebase. To describe this effort as merely a ‘rewrite’ would be to undersell its magnitude; it was, in reality, a complete reconstruction, outstanding in its approach and execution. The mission extended beyond routine updates or refinements; it’s a visionary goal to reimagine Kaspa’s architecture from scratch. This foundational revamp demanded technical understanding and a profound reevaluation of Kaspa’s core principles, ensuring the revamped codebase would reflect and amplify these foundational ideals.

Throughout this intricate process of the Rust rewrite, the developers thoroughly examined each line of code, aspiring to transcend the established benchmarks of efficiency, scalability, and reliability set by the previous Go standards, pushing the envelope of blockDAG technology and setting new precedents for the future. A critical element of this overhaul was guaranteeing a seamless transition from the existing Go-based system with the Rust implementation, syncing at 1 block per second (BPS) to ensure backward compatibility. This is a critical move to provide a frictionless evolution and ongoing network functionality, laying a solid and versatile codebase for ramping up the Rust version to an insane 10 BPS. This exhaustive reconstruction reimagines Kaspa’s technological basis. It has also opened doors to a vast network of untapped potential, limited solely by the collective imagination of the Kaspa community.

Innovating Network Performance

While going into full detail of this major transition is beyond the scope of this article, here are some highlights to underscore the magnitude of the work involved.

Kaspa comprehensively reworked the mempool alongside significant segments of the network’s validation logic and difficulty adjustment algorithms – a re-engineered design to embrace throughputs that were once deemed unfeasible. With unprecedented grace, the Kaspa network is now adept at managing an influx of transactions, upwards of 500,000 pending transactions, establishing a new high-water mark for throughput within proof-of-work.

 

 

Streamlining API

Understanding the pivotal role seamless integration plays in widespread adoption, the Kaspa developers have thoroughly retooled the API. An endeavor that aims to simplify the developer interface, rendering it more intuitive and accessible. The outcome is an API that offers enhanced flexibility and power and significantly lowers the entry barrier for developers and integrators, promoting a more inclusive Kaspa ecosystem.

 

 

Embracing WebAssembly

In a strategic pivot towards the future, Kaspa has embraced WebAssembly (WASM), laying the foundation for progressive applications like the Kaspa Next Generation (KNG) — which I have dubbed Kaspa’s New Groove. This enhancement widens the scope of potential applications for Kaspa — another shift towards more user-centric network interactions and bringing with it the future with browser extensions.

 

 

Addressing UTXO Bloat

Kaspa has addressed the challenge of UTXO set bloat, a concern related to the increasing storage demands on full nodes caused by the growing database of unspent transaction outputs (UTXOs). This issue impacts storage requirements and hinders the efficiency of syncing new nodes to the network, as larger UTXO sets can slow down the process significantly. By devising innovative strategies to mitigate this problem, Kaspa is lowering the entry barrier and creating a more scalable and efficient network. An upcoming paper outlining their solutions will explore more details on this approach.

Transitioning to Rust

As you read, Kaspa is initiating the implementation of Rust on the mainnet, beginning with about 3–5% of its hash power. It’s worth noting the meticulous planning behind this transition. This careful migration from 1 BPS in Go to 1 BPS in Rust isn’t an upgrade; it’s more of a bridge, ensuring that Kaspa’s new design translates seamlessly from theory to practice within the live network.

This phase is crucial for the technical shift and maintaining the network’s integrity and user confidence. The quiet and controlled approach to moving hash power was deliberate, aiming to manage this significant change with precision and to be prepared for any contingencies. This decision recognizes that a successful deployment in cryptocurrency requires a well-planned integration of new features without disrupting the existing ecosystem.

If Kaspa had not already been a project valued in the billions, the push towards the mainnet might have come sooner. Yet, the scale of the project demands a cautious, controlled approach. This approach distinguishes the careful deployment from the creative development.

Development is the creative phase, where new ideas are born and tested in a safe environment, allowing for innovation without immediate real-world impact. Deployment, however, involves integrating these innovations into the live network. This process demands cautiousness to maintain stability, security, and efficiency. This method ensures that Kaspa continues to lead in innovation and guarantees a stable and scalable network for its users, balancing introducing new features with the imperative of preserving network integrity.

TN11

Also, it’s important to note that Kaspa’s TN11 has been operating at an impressive 10 BPS since the beginning of 2024.

KNG Visualizer — TN 11

Diving into 10 BPS in a world-scale peer-to-peer system, as evidenced by the development and deployment of TN11, Kaspa has ventured into previously unexplored territories of crypto technology. Achieving this level of implementation was a giant leap into new cutting-edge territory that necessitated pushing the boundaries of concurrency in computation and communication to their absolute limits. The complexity of producing such a high-throughput system, where every millisecond counts, demanded unparalleled precision in the design and execution of Kaspa’s network protocols.

This initiative of high-frequency block production upends how blockchain networks operate at scale. The engineering challenge here is profound — there’s a critical threshold where the system’s components must synchronize flawlessly. Any deviation, no matter how minor, can lead to cascading failures, transforming minor hiccups into major disruptions. The Kaspa developers’ ability to navigate this tightrope, ensuring that every part of the network operates in perfect harmony, emphasizes the technical prowess and innovative spirit driving the project forward.

Kaspa’s Testnet 11 has proven formidable in demonstrating stability, security, and speed. It operates at 10 BPS while managing a transaction throughput of 3,000 TPS and handles a mempool queue of over 500,000 transactions with remarkable stability.

 

 

Kaspa Delivers

All of this plus more, in a relatively short span of eighteen months, Kaspa has undergone a metamorphosis that is the envy of many projects (proven by the seemingly endless forks). The Kaspa developers have achieved remarkable advancements with unwavering dedication and a visionary future transcending current crypto horizons. It’s important to remember that Kaspa isn’t just progressing; it’s leading the charge, reigniting the foundational crypto vision of a decentralized, efficient, and open financial system that once sparked the inception of Bitcoin.

 

Tip: Check the Block DAG tab on the top of the https://kaspa-ng.org/ page to see the visualizer.

KASPA | KASPA WIKI | MEDIUM | TELETYPE | DISCORD | TELEGRAM

TWITTER | GITHUB | N. R. Crowningshield | Bubblegum Lightning