Post-Crescendo Mining Observations
On May 5, 2025 Kaspa went through the historical Crescendo hardfork that speeds up the Kaspa’s block production rate from 1 block per second (BPS) to 10 BPS, among other significant advances in blockchain/DAG tech. It is the first time that a cryptocurrency using proof-of-work has been able to achieve this feat without so much as breaking a sweat.
As one of the developers that contributed to this hardfork, I’m curious about finding out how the 10BPS now behaves given mainnet conditions. Mainnet conditions are significantly different from testnet as you have several other participants and considerations in play that simply don’t exist in testnet such as a larger global P2P network, different mining pool implementations, various exchanges and the list goes one.
In this post, I will share some initial observations related to mining during this first week after the Crescendo Hardfork. My hope is not to simply report all the observations and explain why things are happening the way they are but to inspire you, the reader, to become more curious about how Kaspa is reshaping the cryptocurrency landscape post-Crescendo and to maybe look into some of the open questions and challenges to be posted here. Perhaps, you’ll leave with even more questions.
DAG Complexity
Let’s take a look at the mainnet Kaspa Graph Inspector (KGI)
Wow, that’s a very complex DAG structure. In contrast, the testnet-10 KGI is a much simpler DAG
We sometimes see the DAG structure of become complex, especially when blocks are filled to the max with transactions and the mempool is full. But the above represents the “normal” for both mainnet and testnet where blocks are filled and the mempool is clear.
So, question: Why is the DAG structure of mainnet is so much more complex than what we saw in testnet?
My intuition is that ultimately the reason must boil down to latency and the various contributors to it. I don’t know the definitive answers (yet), but let’s explore some ideas:
- P2P network width — I learned about this from Michael Sutton. The P2P network width (aka. diameter) is the maximum minimum distance between the most remote nodes of the network from each other. This diameter is logarithmic to the size of the full network. If your network’s two most remote block-producing nodes have a minimum hop of 5 nodes between each other, then each of these nodes will see the blocks produced by the other after combined latency between each of the 5 hops. In the interval that it takes to propagate a block between these nodes, several blocks may have been created in parallel to it already from the other side. The larger the P2P network width, the wider and more complex the DAG we can expect. I currently do not have an easy way to measure the P2P network width of the network, so I leave this exercise as an open challenge for someone to explore and create.
- Latency between mining pools and miners. Pools usually (1) request block templates from Kaspa nodes and then (2) propagate a job for the miners of this pool to work on related to a block template. The important thing to note is that each of these steps incur latency. More on this in the next section.
Mining Pools, Miners and Block Templates
I was talking to Andrei, a pool admin of Kryptex, as he was inquiring about the increased network costs post-Crescendo and we got into the conversation of saving on bandwidth for his pool. Crescendo produces 10 blocks per second, and produces close to about 5–10 new block notifications per second (since notifications are sent per virtual resolution, not per block). Pools typically would subscribe to the node for new block notifications, ask the node for the block template and then propagate these new blocks to their miners as soon as possible.
If you have 1000 miners on your pool, and you get 10 new block notifications per second, you would have to send 10,000 messages overall every second. I’m not going to go into just how much bandwidth that is, but I assert that it’s a lot. Definitely about 10x more bandwidth than what it was when Kaspa was at 1BPS. That increased bandwidth means increased operational cost.
So what are the strategies that pools are applying to limit the bandwidth consumption of their pools? Andrei gave me a script that measures the notification rate (how many new block job notifications per second) of some target pool. In summary, the script connects to the target pool, measures the number of notifications it receives over a minute and then calculations the notification rate. Using his script, I was able to get some measurements for some of the most common pools in use. The data is as follows:
Caveat: Data may have changed by the time of this post. As you can see, the different pools have different notification rates.
Most of the pools listed above have a notification rate of 0.48–0.92. 0.92 notification rate of HeroMiners means it sends new jobs roughly once per second, and ~0.5 notification rate of HumPool and WhalePool means they second new jobs every 2 seconds and ignores/skips the rest of the jobs. This strategy of throttling notifications only to some interval saves significantly on bandwidth, however it puts the pool in a position where it may miss out on mining blocks that have better rewards in the interval between it’s notifications. To elaborate even further, if a pool takes the latency to the extreme and send a single block message every 10 seconds, for example, then they will end up producing red blocks which receive no rewards at all.
On the other end of the spectrum, f2pool at 5.33 notification rate basically means it sends almost all new block notifications to all miners at once. This allows the pool to have access to the latest templates, meaning it’s also in the best position to mine transactions that have the highest rewards. However, due to the frequency of sending these new jobs all at once f2pool will incur significant costs to broadcast these notifications both in bandwidth and cpu (since sending messages require processing time).
Kryptex is at 2.77 means they’re sending a new block template roughly every 250ms — which aligns with what I suggested to them. This 250ms figure is something I vaguely determined as a workable value while I was fixing another issue I observed while solo mining (more on this later).
This a new space for competitions for pools where they must balance how often to send notifications to save on operational costs vs the opportunity cost that they incur on missing out on high reward txs. The pool that is able to optimize or balance their broadcasting pipeline to minimize on costs while being able to increase notification rates will have an edge in terms of finding rewards.
To be clear, the GhostDAG protocol will tolerate these increased latency figures added by the pool with regards to their communication between the pool and miners.
Disclaimer: I don’t advocate for any of the pools I mentioned. In fact, if you know me, I’m a proponent of solo mining in Kaspa.
The Stratum Bridge
Now, where did I get the 250ms figure that I suggested above. I solo mine and I’m running a compiled version of the Kaspa Stratum Bridge. It started with me observing that my KA Box Pros were mining with less hashrate than they are expected to. The KA Box hashrate dipped right around the HF activation, so my gut instinct is to check anything that has changed in terms of mining at that time.
Get coderofstuff’s stories in your inbox
Join Medium for free to get updates from this writer.
After chatting with pbfarmer (from Discord), he was wondering whether the ASICs are able to handle the increased number of jobs being passed onto them. In addition, I had another conversation with Michael about this observation and he suggested I try mining to a pool that I know is stable. So I did — I moved my KA Box Pro temporarily to HeroMiners and this was the result in hashrate:
That part with the dip is when I made the switch. Visually, it shows that the hashrate went back to it’s expected rate. So with this short experiment giving conclusive results, I know the issue is only with my stratum bridge.
Taking into consideration pbfarmer’s idea, I put up a quick fix that throttles job notifications such that only one is sent every 250ms. I chose 250ms because I know the average block time is 100ms and I wanted to try and choose a throttling figure that was close to the average to ensure I’m mining to as “latest” as a block template as possible without overloading my ASIC with jobs. If 250ms didn’t work, I would’ve continued incrementing towards 1 second. Thankfully, the first figure I started with did work, and the result is as follows:
After this I tried some lower figures like 100ms or 200ms, but the results were inconsistent so I stuck to 250ms. This is how I got the figure that I shared with Andrei. I wonder if ASICs can be made to handle more frequent job notifications? Think in terms of 100BPS — would a 250ms throttling figure still work for then?
Read more about this finding in my X posts here:
- https://x.com/coderofstuff_/status/1920191272347971775
- https://x.com/coderofstuff_/status/1920883888974352833
If you are solo mining with the bridge and are experiencing this reduced hashrate issue too after Crescendo, I created a v1.3.0 dev Kaspa Statum Bridge Pre-release where you can run the bridge with my fix. You can also try out Aglovale’s v1.3.0 dev version which contains a few more additional features supporting Canxium with the bridge.
Newfound Viability of Solo Mining
A common argument against solo mining is variance. However, with the coming of 10BPS, Kaspa has made solo mining viable again. Given the more frequent number of blocks to be found, a solo miner will experience less variance in their rewards and will be able to see daily rewards more consistently. To be clear, your chance of finding blocks is the same now as it was before the fork since the chance of finding blocks is solely dependent on your hashrate. Specifically:
chance_to_find_block = (your_hashrate / network_hashrate)
Obviously, your hashrate and the network hashrate do not increase with the block production rate. However, if you know your chance_to_find_block, you can then estimate your expected daily rewards (on average). What changes with the higher block rate is how close you get to this expected daily reward. The variance of solo mining is reduced because there are more blocks mined per day, even though each block’s reward is 1/10th of what it was before.
To help visualize this, I created this Kaspa Solo Mining Rewards Simulator.
This is how solo mining with 4.0TH/s at 1BPS may have looked like.
As you can see, there are several days where a miner would not have seen any blocks. In the Simulation Statistics, 10 different miners solo mining would have widely variant results over 30 days in terms of their rewards relative to the expected daily reward. Some get just 47% of their expected, some get 142% of it — the range is too wide!
In contrast, this is how 4.0TH/s solo mining looks like post-Crescendo
From these graphs, it’s easy to see that a miner would see a reward daily proportional to their hashrate. The amount expected amount is equivalent to what you would get back in 1BPS but with the more frequent blocks now, you can expect to see a more spread out acquisition of your expected rewards over time.
The results in the end are much closer to the expected rate, ranging from 83%-111% of the expected value. 10 different miners all with 4th/s over 30 days would have very comparable results, all because variance is reduced. If you run this simulation multiple times, you’ll be able to observe this range even better.
The post-Crescendo Age
This is the first time we are seeing 10BPS on a POW network on mainnet live and running. We are at a new frontier where we will see new exciting technological challenges arise. It is my hope we would also see more new people rise up to the challenge.
