📢The Crescendo Hardfork Node Version v1.0.0 is out! This release signifies the fulfillment of all the development efforts that have been poured onto Kaspa over the past few years, starting from KIP1 all the way to KIP15. It introduces the Crescendo Hardfork, transitioning the Kaspa network from 1 BPS to 10 BPS thus marking a significant increase in transaction throughput and network capacity, as well as improved network responsiveness due to shorter block intervals, enhancing the overall user experience. 𝆓 Crescendo is scheduled to activate on mainnet at DAA Score 110,165,000, projected to occur on 🚀May 5, 2025, at approximately 15:00 UTC. See links in thread to Github upgrade guide and Node Setup

Updated stats from today courtesy of @coderofstuff_ Mainnet DAG structure is looking nice and healthy

The ultimate sequencer/a late night braindump on all things Kaspa Going forward, I imagine Kaspa as a ~terabyte/day-magnitude stream of (securely pruned) data mined in consensus by thousands of solo-asics across the globe, providing world-wide linear ordering/conflict resolution and censorship-resistance. There’s a reason the distributed systems literature refers to consensus participants as replicated state machines. Reaching global consensus is a hard problem, requiring at the very least that each participant observes all data. However at the same time, the amount of useful data that truly benefits from such global and irreversible ordering is limited as well, or at least has a varying degree of importance for different usages. Thus a system that scales to fully utilize commodity hardware and home-level bandwidth as these evolve with Moore’s law can suffice for providing the sequencing and data availability required for top-of-the-pyramid applications which require it (global finance at scale, cross continents energy trade, etc). Zero-knowledge tech was the last missing piece to make such a sequencer expressive enough for general computations/dapps while remaining decentralized and verification-focused, but it is now maturing exactly on time to meet this need. We “only” need to do it right design-wise (based, atomic-composable) and social consensus-wise (defragmented), so that the economy built above it doesn’t suffer from tragedies of the commons and unconvergable mechanism design. I ack this possibly requires prophetic abilities, but go search for ‘supernova’ @ “In which we’ll bе reduced to a spectrum of gray*” and you might be starting to wonder like me, is it possible that such prophets/visionaries might just be wandering between us?

And a bold prediction moments before

RK #Crescendo update. See the attached image in relation to the blog post timeline. Working hard on this top-notch performance version so that node spec requirements and configuration for 10BPS can be finalized. A lot is also happening in other coding/design areas, including but not limited to: - KIP6 implementation by a new RK contributor (a breath of fresh air...) - ZK opcodes L1 design - DK incremental algos design and...implementation - KIP9 research paper finalization (on pause due to all other stuff) - KIP10 formal proposal

1/ A clarification about #kaspa Rust hashrate migration which seemed to reverse during stable version release: Kaspa-Pool, a major early adopter of the rust node, was recently DDoS attacked on pool APIs. This caused the percentage of mainnet Rust hashrate to drop significantly.

A braindump of all things crescendo, what’s included, what are the benefits, etc This might contain many details, so hold tight. 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. Other things I wanted to write about but will wait for another time: survey the increased-yet-limited hardware costs of this upgrade, why I conjecture the mainnet DAG width will not grow tenfold post crescendo (hints: the continent claim above; i.e., locality in the P2P net), and more. Please ask about anything unclear or that requires elaboration.

Kasplex has officially launched its Layer 2 public testnet: Kasplex zkEVM, a fully EVM compatible Based Rollup built on the Kaspa Network. This marks a major milestone on the road to mainnet and a pivotal step in bringing smart contract functionality to Kaspa. Kasplex zkEVM introduces: - Full EVM equivalence. Deploy Ethereum-native contracts with minimal changes - Bridged $KAS as the native testnet token - Integration with all standard EVM wallets (e.g., MetaMask, Hardhat) - Decentralised sequencing and data availability anchored to Kaspa L1 - Live faucet, explorer, and growing developer tooling ...and many more Testnet Connection Details: Network Name: Kasplex Network Testnet RPC URL: rpc.kasplextest.xyz ChainID: 167012 Explorer: frontend.kasplextest.xyz Documentation: docs-kasplex.gitbook.io/l2-n… Native token: Bridged Kas ($KAS) This testnet is not just a preview. It's a live environment for developers and infrastructure teams to deploy, experiment, and stress test smart contracts and DeFi protocols in real-world conditions. We invite the broader community to actively engage with the testnet, report bugs, and help refine performance, tooling, and reliability. Kasplex zkEVM is designed for long-term scalability and decentralisation, eliminating centralised sequencers while inheriting Kaspa’s security model and high-throughput DAG architecture. Let’s build.

Rusty Kaspa Python bindings (beta) are now available on pypi! The implementation was mainly carried out by @smartgoo_ and @CryptoAspect Already put to good use on the kaspa api. More info in comments.

That escalated quickly 😅 We now have 34 builders across 21 teams in our Dev Discord — working on everything from network analytics to bridges, stablecoins, and perp DEXs. This community is our biggest motivator. Want in? Apply docs.google.com/forms/d/e/1F….

Checked Kaspa code again recently, it has multisig support now, so can be integrated with Rosen bridge for getting on Ergo / Cardano / Ethereum / BSC DEXes , just Kaspa community efforts towards integration needed (no integration fee!) @DesheShai @armeanio

Little test with mainnet nodes #KaspaGlobe

Our long-awaited decentralized Point of Sale is here. 😎 Kasway is now LIVE on Mainnet! kasway.xyz Start accepting payments in $KAS on a team-driven manner, and enjoy low-fee and blazing fast confirmation times powered by Kaspa 10 BPS BlockDAG. Visit the new docs to learn more about the project, and how to use it: docs.kasway.xyz

Encrypted p2p images and file transfer over $kas 📁

dropped a few thoughts on moneyness culture + some context on the kas unofficial saga hashdag.medium.com/in-which-…

Our miners will experience the biggest change after Crescendo. Kaspa creates 10 blocks per second, and that's 864,000 blocks per day. Because rewards are relatively small but constant, miners are getting payouts frequently. This means luck balances out quickly, and income is steady and predictable. If we compare it to our older brother Bitcoin, solo miners can get nothing for months or even years because it hits one block every 10 minutes. This means 144 per day. With millions competing, variance is extreme, and income is random. This pushes most miners to join pools to survive. Kaspa fixes this with frequent blocks - it reduces variance, and solo mining becomes viable for small and moderate-sized miners. Pools are optional. More miners stay independent. Centralization is reduced. Kaspa makes mining fair, stable, and realistic - even for small miners

#TN11 some final tests and benchmarks. Here I'm running a controlled experiment where a transaction generation tool (named "Rothschild" if you wondered) is sending ~1200 TPS to the node. The node does not broadcast txs in order to make the test focused >

QED github.com/kaspanet/rusty-ka…

DeepWiki now covers the full Rusty Kaspa codebase, turning it into a searchable reference. You can ask how parts like consensus, DAG, networking, or wallet logic work, and get direct links to code or documentation. It helps developers understand Kaspa faster, without reading the full repository or waiting for explanations. Some areas still need more detail, but the structure is already strong. Everything is indexed, linked, and easy to explore, even with simple questions. This makes building, learning, and contributing more accessible for everyone

#Kaspa GHOSTDAG Protocol Visualizer Visualize efficient ordering ! We'll connect to the API later.

In case the question was genuine, I'd like to add more transparency. The image shows general commits to RK since its inception followed by my personal stats. Getting something like RK rolling from zero required making a huge personal effort and writing huge parts of the codebase extremely fast. And I really don't think anyone could of done that faster than we did. It was mostly based on the original core contributors who knew the tech really well and only needed to translate (while redesigning for performance). Eventually it became clear that fast is slow in the sense that: (i) knowledge remains within a few so the workforce isn't scaling, and (ii) that me and others are getting worn out + cannot make progress in research and in other areas not less essential for Kaspa (for instance L1/L2 design). So we turned to "slow" which is really fast. Getting more and more developers on board, while "bearing" the learning curve for the sake of a scaled out core taskforce which is clearly the way to go for the long run. In that sense perhaps the biggest accomplishment of RK isn't 10bps but rather the fact that more brilliant people such as @Tiram_88 @coderofstuff_ @Max143672 were now part of creating the software which gives them intrinsic knowledge which cannot be obtained otherwise. So the "slowness" you are mentioning is in fact a short-term artifact of having more and more development power. For instance, following crescendo this larger group of contributors will allow us to split forces between DK and ZK efforts and to advance both orthogonal efforts in parallel. Hope this gives more clarity.

✈️Pack your bags, Kaspians! We are thrilled to announce that #Kaspa is LIVE on @travalacom! You can now book millions of hotels, flights, and activities all around the world and pay with $KAS 😍 Follow the link bit.ly/47AW2U8 to sign up or sign in to redeem $50 in travel credits to use towards flights, hotels, and activities around the world. #Travel #KaspaAcceptedHere #GlobalAdoption

So I'm done with the most heavy research post I had to write. Let's start crescendoizinggg 🎼💃 Are you in for the ride @coderofstuff_ ? we got some stuff to code 😀

I see a few slightly concerned voices about the #Kaspa rust rewrite and the fact that it's not “done” yet. Well, let me announce it load and clear: the rust rewrite as per the original proposal is completed (long ago I'd say). The node is functioning extremely well, including >

Huge news $kas! I'm so excited that I physically cannot get straight to the point without gushing a little bit, so bear with me (or skip ahead). The tl;dr is that @MichaelSuttonIL revolutionized cryptocurrency (yes, again). When asked what makes $kas stand out from other projects, my answer is usually "the scientific standard". Building and developing means constantly facing pressure to quickly deliver. A pressure that is obviously in tension against the exact deliberation required to provide high-quality solutions established via rigorous reasoning. (This is essentially why we keep seeing projects launching half-baked ideas, and realizing a bit too late that they are crippled by being committed to a debilitatingly flawed tech). Kaspa's unprecedented technological achievements are a testament to the huge long-run benefits of adhering to a stringent academic standard. Only patience can allow radical new ideas to grow into landscape changing technologies that are landscape changing, yet understood well enough to be used safely. Even if this patience means taking more than half a decade of development before even launching, or delaying a much anticipated release by a few months. Kaspa is cavalcade of groundbreaking ideas. Most community members know that, at the core, there is GHOSTDAG, the first trilemma solving consensus protocol. But there is so much more. Kaspa is packed with groundbreaking theory and engineering feats that were required to make it work without compromising its quality. Designing the pruning algorithm required developing the previously unexplored theory of pruning attack in DAGs. Understanding the effective capacity of the network relies on deep game theoretic analysis of how transaction inclusion works in light of parallelism. Implementing GHOSTDAG required tackling, and partially solving, a major open problem in the theory of data structures, and so on. And today, we present a new solution to another old problem: state bloat. The problem is, essentially, that each node in the network must carry a list of all positive balances (namely, the UTXO set). As the network sees more usage, and more wallets are created, the storage requirements of each node grows. This grow can be either organic or malicious (via a dust attack). This problem is deceptively hard and crucial, and previous attempts to tackle it are unsatisfactory for many reasons. All that I know of rely either on using accumulators to delegate maintaining the state to the users, or restricting the storage period of data by charging rate or depreciating the value (demurrage). I will not digress into discussing the disadvantages of these approaches, but they are formidable. At least this was the landscape, until Michael had this crazy idea: what if we somehow found a way to make wasting storage quadratically expensive? That is, set some policy for pricing transactions (in terms of the block space they consume) such that wasting n times the storage costs n^2 times the blockspace? For people who are familiar with the matter, the mere suggestion seems absurd, delusional even. I mean, the cost must be computed per transaction so surely, no matter how you price it, it couldn't grow much faster than the number of transactions, right? So no matter your pricing policy, a clever attack should always be able to find some way to only pay linear costs for a storage attack, right? Wrong! I was wrong, and M was right. He indeed managed to find a formula, and an infuriately simple one at that, with the magic "local-to-global" property we desired: the cost of a transaction only relies on the data within that transaction, yet, an adversary attempts to waste storage will pay a price quadratic in the amount of storage they have wasted, regardless of how they structured their transaction! (Well, at least it seemed to have this property, actually proving it turned out surprisingly difficult, and required several weeks of combined effort). This insight affords a brand new way to mitigate state bloat. The first one that does not require a complete overhaul of how accounts are managed, and is in fact almost completely transparent to end-users. I strongly believe this fabulous discovery will have a huge impact on how many projects approach the state size problem. In KIP9, we present 1. a Kaspa-centric specification of the new anti-bloat technology, 2. a broader, yet still informal, discussion of the theory supporting the specification: github.com/kaspanet/kips/blo… For those who want to participate in professional discourse about the proposal, we have created this thread: research.kas.pa/t/quadratic-… For a less emotional and more composed statement, more concentrated on the rusty-kaspa perspective, see the Discord announcement: discord.com/channels/5991532… All of the theoretic assertions required for the security of this implementation have been rigorously proved. In the following weeks, we will post a research paper presenting the theoretic work as well as discussing the generality of the result (which goes will beyond the UTXO model). As usual, h/t to @rhubarbmedia for the graphic, adapting the cover of the charming book "Dr. Euler's Fabulous Formula" (which is, btw, a delightful read I encourage you all to pick up).

KIP14 — The Crescendo Hardfork, the exact spec and design of the upcoming Kaspa Crescendo is out for public review and discussion See link below >>

#Kaspa on #Rustlang *release candidate* (RC) for mainnet is coming soon - KIP9 mempool rules ✅ - Optimized UTXO notification system (for supporting large-scale wallets) ✅ - Important showstopper bug fix (pending merge as we speak) ✅

1/ Regarding solo mining, I noticed my KA box pros dropped a bit in hashrate while mining with my stratum bridge while my KS0 ultras were mining fine. After doing some investigation, it appears that some asics may struggle with receiving several new block notifs/jobs too fast.

As a curious observer of the anticipated KRC20 load on Kaspa's mainnet, I prepared a mempool stats collector by customizing my local node. Although more data could have been collected with finer granularity, this is what I managed to compile just a few minutes before the launch on September 15th. In any case, I thought I’d share some of the raw data here as well. Full links to my code and a Jupyter notebook with self-contained data will be provided below. The first two figures offer an overview of the processing throughput, with the first showing the average number of transactions per block (TPB)

Bitcoin, Kaspa & Proof of Work with @hashdag (Bitcoin Takeover Podcast S16 E41) nitter.app/i/broadcasts/1OwxWejLM…

The reason #Kaspa hard forks make the system insecure in the long term is not only because individuals with sufficient power can enforce a negative change, but also because a single error could potentially devastate the system.

🗓️Mark your calendars! #Kaspa's Testnet 11 (#TN11) is going public this Sunday, January 7th at 8 PM UTC. Testing the new ⚙️#Rust codebase at an impressive 10 blocks per second!🚀 More details coming! #DigitalSilver #10BPS #CryptoTwitter $KAS

PR github.com/kaspanet/rusty-ka… by @Max143672 & @OriNewman was just merged. This PR is a huge milestone for Kaspa and its script engine in particular. It adds 1. support for introspection** opcodes which allow inspecting the script public key and amounts of inputs and outputs (from within script execution). 2. support for 8-byte arithmetic operations These additions allow the implementation of KIP-10 additive addresses [1][2][5]; see kip-10 example therein. They are also essential for future ZK opcodes (which require this contextual knowledge as proof public inputs). In terms of #Crescendo roadmap, this was the last major milestone before moving to the 10BPS node configuration & spec stage. ** Also named sometimes “covenants” [3][4]: > “In the context of Bitcoin, the most useful definition of covenant is that it’s when the scriptPubKey of a UTXO restricts the scriptPubKey in the output(s) of a tx spending that UTXO.” —Anthony Towns [1] research.kas.pa/t/auto-compo… [2] github.com/kaspanet/kips/pul… [3] bitcoinops.org/en/topics/cov… [4] gitlab.com/GeneralProtocols/… [5] nitter.app/MichaelSuttonIL/status…