Kaspa ($KAS) core R&D - what developers discussed, debated, and shipped. Apr 22-May 1, 2026.
TN12 Relaunch #3 Goes Live
Michael Sutton posted the relaunch notice on May 1: "TN12 Relaunch #3" is live. The reset includes KIP-21 sequencing commitment support, updated script pricing, script engine additions and improvements including OpCheckSigFromStack and non-minimal encoding support, and additional consensus and node improvements from the Toccata development branch. (source)
The stable branch for running TN12 is now tn12, with repo and instructions linked directly from Sutton's message. Existing tn12 checkouts do not need a local reset this time; they can update normally with git checkout tn12 and git pull. (source)
Mining also has a new floor: the minimum supported miner is cpuminer v0.2.7, or the latest main branch. Sutton also noted that the previous covpp-reset-2 dev branch has been renamed to toccata, and will serve as the development branch until the Toccata changes are merged to master, expected in about one to two weeks. (source)
The Last Toccata PR Before Reset
Michael Sutton opened PR #963 on April 22, calling it ready for review and tying it to the final remaining item before a TN12 reset. (source) (source) (PR #963) The PR adds Toccata lane and gas limits to consensus and implements the corresponding mempool policies. Its stated goal is to bound how much sequencing-commitment active-set churn one block can cause, while still allowing many lanes to be active over time. (PR #963)
Sutton described the PR as the least-complex minimum viable solution for a combinatoric problem, and said it leaves room for future mempool policy optimization. (source) The next morning he said the target was to reset TN12 the following Monday. (source)
Ori Newman spotted one consensus-shape detail during the review: non-native subnets should be enabled only for v1 transactions. (source) He found the relevant check in Sutton's PR, where only post-Toccata non-system lanes may carry gas while reserved system lanes stay gas-free. (source) Maxim Biryukov pointed to the matching validation code in tx_validation_in_isolation.rs. (source)
By April 27, Sutton posted the short message everyone was waiting for: "Merged." (source)
Devnet Finds the Sharp Edges
The reset did not happen cleanly on the first target date. Sutton reported that internal devnet testing found several SMT-related issues, and said the team would most likely not make the Monday reset. (source)
Two follow-up fixes landed fast. Sutton merged PR #968, Maxim Biryukov's Fix slo promotion, on April 27. (source) (PR #968) The next morning, he merged Biryukov's PR #966, SMT: fix incorrect blue score during ibd, and added that the two PRs covered all found issues. (source) (source) (PR #966)
Once those fixes were in, Sutton said the devnet looked good and that IBD had passed successfully. The new goal became a TN12 reset the next day if nobody objected. (source)
Backward-Compatible Databases for Toccata
Maxim's PR #956, nicknamed aDBptation, handled another reset blocker: post-Toccata nodes still need to read databases written by pre-Toccata nodes. (PR #956) The PR adds backward compatibility for persisted consensus data, including EOF-tolerant decoding of pre-Toccata UtxoEntry data and version-aware CachedDbAccess for stores whose on-disk layouts change across the hard fork. (PR #956)
Ori approved the PR on April 29. (source) Sutton said the main goal was to hit the same numbers intended for mainnet after the hard fork, so that master could be used for TN12 after the merge. (source) He wanted to finalize the numbers before the reset, and leave activation logic for later. (source) Ori merged it shortly after. (source)
Hash Opcodes Get Priced
With the reset getting close, Sutton opened PR #971 for script pricing benchmarks and hash opcode pricing. (source) (PR #971) The PR adds focused kaspa-txscript Criterion benchmarks for script-pricing workloads and uses them to tune hash opcode pricing under the new compute-budget model. (PR #971)
Sutton summarized the finding directly: edge-case benchmarks showed hashing opcodes were not properly priced. The proposed costs were 2 units per hashed Blake2b byte and 1 unit for Blake3/SHA-256. (source) The PR distinguishes normal multi-transaction workloads, where Rayon parallelism helps, from adversarial single-transaction workloads, where no script parallelism is available and the pricing boundary is defined. (PR #971)
On April 30, Sutton posted that the pricing work had been merged, thanking Ori and Maxim. (source) A final cleanup PR followed: Ori's PR #976 finalized txscript limits, benchmark tuning, and TODO cleanup. (source) (PR #976)
The Patch That Closed The Reset Path
The reset finished with one more patch. On May 1, Sutton merged PR #977, supertypo seeder + minor const fix. (source) (PR #977) One minute later, he posted: "tn12 branch is updated." (source)
That line set up the relaunch notice that followed. A week earlier, TN12 was still behind a feature freeze, KIP-21 review, gas commitments, and reset prep. By May 1, the lane/gas limit work, SMT fixes, backward-compatibility work, script-pricing benchmarks, final constant cleanup, seeder patch, and relaunch instructions had all landed into the reset path. (source)
Stable TN12 vs Local Devnet
The channel also clarified which branch integrators should use. coderofstuff asked whether tn12 is the branch integrators should use to test the new features. (source) Ori answered that tn12 is the stable branch for Toccata and has its own testnet network. For the newest features, he said developers should run covpp-reset2 in a local devnet. (source)
That distinction matters for anyone building against Toccata before mainnet. TN12 is the public stable target. covpp-reset2 is where the newest work appears first, but it can move quickly enough that local devnet testing is the safer expectation.
Lane Proof RPC Moves Toward Integrators
The week also brought a new integration-facing RPC. Maxim opened PR #961, adding get_seq_commit_lane_proof(block_hash, lane_key) for gRPC and wRPC. (source) (PR #961) The PR returns the witness a client needs to verify one KIP-21 active lane against the seq_commit in the block header without running a full node. (PR #961)
Maxim said he used the branch in devnet to perform CLI tests against his rollup example, and that Hans needed the same API for framework work. (source) Hans confirmed: "Yeah, I need that exact API as discussed." (source)
IzioDev then raised a shape question: vProgs may need to track and prove multiple lanes at the same time, so a consumer that passes a list of lane keys may want a response grouped by lane rather than client-side reshaping. (source) (source) (source) That is the kind of API detail that looks small until real integrators start wiring against it.
Silverscript Fixes KCC20 State Arrays
Silverscript kept moving too. Manyfestation opened PR #111 to fix State[] field access for array fields. (source) (PR #111) Ori tested it against the KCC20 example, said it was working well, and merged it. (source) (source)
Ori also asked about the VS Code debugger extension. (source) Manyfestation said it had been paused when covenant declarations were introduced, but that it was a good time to return to it. He has an older open PR to adapt first, then plans to iterate on IzioDev's feedback. (source)
The Data-Service Problem Surfaces Again
The heaviest discussion outside the reset was not consensus code. It was data infrastructure for integrators.
IzioDev opened the topic after an integrator struggled with Kaspa historical data. The use case was straightforward: verify address history transparently by taking every UTXO an address received or spent, summing plus and minus, and reconstructing the balance over time. (source) The current REST API, maintained by Supertypo, has historical gaps before March 2022, so it is insufficient when an address touched one of those gaps. (source) IzioDev stressed that this is not a Kaspa network issue: the network prunes data after the pruning period and provides cryptographic proofs for UTXO-set integrity. The issue exists for actors that require transparent historical records. (source)
Supertypo added another operational caveat. UTXO counts on api.kaspa.org are not always exact for active addresses with many UTXOs. Small-address counters are cached with increasing TTL, and very high-count addresses currently refresh roughly hourly. Anyone needing accurate or frequent UTXO queries should query their own kaspad node. (source) He also pointed to simply-kaspa-utxo-exporter, a tool for dumping subsets of the kaspad UTXO set, or the whole set, into Postgres. (source) (repo)
5bb 55b then shared a new standalone project, go-kaspabook, using vspc2-rpc, RocksDB, and a simple built-in REST API for a local limited index database. (source) He later described it as a short-term indexed-data system rather than a browser-scale full archive database. The current estimate: about 1 million block headers plus 100 million transactions in roughly 45 GB of disk, with high-speed NVMe handling 50-100K transactions per second through a single-threaded transaction database. (source)
IzioDev sketched a bigger architecture with hot, warm, and cold storage: hot data for days, warm data for one to twelve months on cheaper storage, and cold data in glacier tiers. (source) The gateway above it would act as a query planner, deciding where to hit based on the request, while cold retrieval would be slow and limited to prepared async jobs such as full address history. (source) In the worst case, he estimated warm storage around 40 TB, or 80 TB if block size doubles. (source)
The conclusion was not that every node should become an archive service. It was that enterprise-grade users, wallets, exchanges, auditors, explorers, and integrators have different retention needs, and those needs are distinct from consensus pruning. (source) (source)
UTXO Pagination and Secondary Indexes
The same data-service thread exposed more concrete API work. 5bb 55b asked whether node RPC UTXO query results can be paginated. (source) Ori answered that he did not think so, but that pagination should probably be added. (source) Maxim pointed back to an earlier discussion. (source)
D-Stakes shared a compare branch indexing utxoindex by DAA score. (source) His current issue is that simple limit pagination is not efficient or intuitive when many addresses are scanned by script public key first and DAA score lower in the hierarchy. (source) He floated a per-address call as an alternative, but noted it may be too breaking when exchanges may own hundreds of thousands of addresses. (source)
IzioDev also questioned whether CachedDbAccess::seek_iterator should strip the bucket prefix when returning results. For secondary indexes, he argued, returning only the stripped suffix makes it less convenient to reconstruct the primary key. (source) Sutton said the change sounded legitimate, but should be reviewed through a PR. (source)
Dependency Cleanup and Android Side Effects
Alexander Saefstroem opened PR #965 to switch workflow-perf-monitor to the updated kaspanet fork so development could use the latest bindgen. (source) (PR #965) The motivation was time pressure before the hard fork: the upstream crate issue needed to be resolved quickly. (PR #965)
A few days later, Maxim opened PR #970 to address cargo audit and cargo deny advisories, replacing unmaintained crates and bumping dependencies. (source) (PR #970) IzioDev noticed one useful side effect: dropping intertrait also supports the Android target. (source) Maxim then asked why the codebase had intertrait, downcast, and downcast-rs at the same time. (source)
What If Every Block Is Disqualified?
One consensus edge case got a crisp answer. dimdumon asked what happens if all blocks in a current interval are disqualified from the selected-parent chain, and whether that is possible. (source) Sutton said it is possible if all miners modify rusty-kaspa not to follow the correct block-building rules, or if a bug causes it. In that case there is no virtual progress and no accepted transactions, but DAG tips still progress. Once a qualified miner arrives, it slowly merges the disqualified block bodies and accepts the valid transactions from its point of view. (source)
That answer is a useful reminder of the design boundary. DAG growth alone is not the same thing as accepted virtual-chain progress.
All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.