Kaspa ($KAS) core R&D - what developers discussed, debated, and shipped. Mar 18 - 24, 2026.
Most Miners Still on v1.0.0
Two weeks after the v1.1.0 stable release, coderofstuff sampled the last 1,000 mainnet blocks. The network is 99.6% Crescendo, but 86% of miners are still running v1.0.0. Only about 4% have moved to v1.1.0 or its release candidates. (stats) Sutton: "I was expecting more miners on v1.1.0 by now." (Sutton) coderofstuff: "In mainnet? People don't tend to move unless someone's asking." (coderofstuff) smartgoo noted that a good number of PNN nodes also appear to be running versions older than v1.1.0. (PNN)
What Does a Node Actually Cost?
hashdag asked what it costs to run a full node with the recent TPS surge. (question) The answers gave a clear picture.
wbbw55 reported a Contabo VPS at $20/month running smoothly - 8 cores, 24GB RAM, 400GB NVMe. (Contabo) He stressed that NVMe is essential and SSD alone is too slow. (NVMe)
smartgoo shared a more detailed cost journey. He moved a node from AWS EC2 at $200/month to an OVH VPS at $25/month, then to an OVH dedicated server at $125/month after the VPS fell out of sync under sustained high TPS. The VPS disk was the bottleneck. The dedicated server synced in about two hours with mainnet at 125GB, and all utilization stayed low. (smartgoo)
wbbw55 added that CEX infrastructure and node infrastructure are separate problems. CEXs rely on the indexer built by supertypo, which has much higher hardware requirements than kaspad itself. (CEX context)
Explorer Under Pressure
coderofstuff opened a discussion on explorer API performance under load. The network recently sustained 1,500-3,000 TPS, and this exposed areas that need improvement - particularly around the explorer API, database, and archive data. (topic)
supertypo explained the core problem. The API database has over one billion transactions and nearly doubled in size in a week due to mass self-send transactions. He called it "unsustainable in the near future." (TLDR) The API handles around 20 million queries per day and needs fast NVMe for the most recent data. He proposed splitting into a hot tier for recent data on fast drives and a cold tier for older data on cheaper storage or archived backups. (split proposal)
wbbw55 suggested distributed SQL solutions like PostgreSQL with Citus or TiDB for handling the full archive at scale. (distributed) Dstakes proposed sharding by pruning period with a load balancer routing queries to the right shard. (sharding)
supertypo noted the current back-to-genesis API database sits at 1.6TB on compressed ZFS, while coderofstuff's archival kaspad node uses 9.6TB of unoptimized data. (comparison) He emphasized that adding txindex to the node directly would only make the problem worse by orders of magnitude. (txindex)
Indexer Gets a --light Flag
supertypo confirmed work on a --light flag for simply-kaspa-indexer. The indexer can already be configured to persist only accepted transactions, but it still polls from both block and virtual chain endpoints. He said he was 90% there - only missing the ability to disable the get_blocks subscriber entirely. (progress)
wbbw55 asked if a specific lightweight indexer for CEX integration was feasible. (request) supertypo replied it made more sense to support it within the existing indexer rather than building something separate. He also proposed adding a corresponding light API directly in the indexer for a more all-in-one solution. (light API)
Pools Need a Better Way to Check Block Rewards
IzioDev inspected what pools need to determine if a mined block has been paid for. With help from pool operators, he identified the requirements and proposed a new GetBlockRewardInfo response that returns block color, confirmation count, merging chain block hash, and reward amount. (proposal)
coderofstuff had shared pseudo-code guidance for pools using the existing getVirtualChainFromBlockV2 RPC - walking the virtual chain and checking mergeset blue hashes against the pool's mined blocks. (guidance) But the current approach relies on GetBlocks, and coderofstuff said the goal is to steer pools onto something simpler and more reliable, like GetBlockColor. (steer)
Feature Freeze: Behind Schedule
Sutton stated the team is aiming for feature freeze by end of March. "Which means we're 2-3 weeks behind schedule." (Sutton) coderofstuff asked for an ETA on the hard fork release. (ETA) No specific date was given.
KIP-21 Implementation and Timestamp Questions
PiDAGorass asked if KIP-21 is live on TN12 yet. Maxim said he is actively working on it and shared a branch with consensus integration tests. (code) PiDAGorass is planning changes required for ATAN with regards to KIP-21 and asked to see the implementation. (ATAN)
Maxim raised a design question around KIP-21 sequential commitments. The mergeset hash depends on a timestamp known only to the miner, making it impossible to calculate the virtual sequential commitment without miner-side enrichment of the block template. (timestamp issue) Sutton replied that the timestamp should just come from the selected parent - a consensus-agreed source - rather than being delegated to miners. (Sutton)
PiDAGorass also noticed that KIP-17 defines OpBlake2bWithKey while KIP-21 uses Blake3, and suggested adding OpBlake3WithKey for consistency. (mismatch) Sutton said he did not see a direct relation to seqcommit hashing but had nothing against it conceptually. (Sutton) Ori added that he is generally ok with it but does not expect it to be needed after covenant ID changes. (Ori)
Silverscript PRs Continue
Ori merged Silverscript PR 78 from Manyfestation. (merge) He then flagged a conflict in PR 79 that needed resolving before merge. (conflict) Manyfestation submitted PR 79 as a debug session cleanup, noting he wants it merged before the DAP and VS Code extension PR. (PR 79)
Ori opened PRs 923 and 924 in rusty-kaspa. PR 923 adds opcode display functionality that Manyfestation can use for showing opcode execution in the debugger. (PR 923) smartgoo opened PR 924 after discussing needed tweaks with IzioDev. (PR 924)
All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.
