Without Knowing F

Kaspa ($KAS) core R&D - what developers discussed, debated, and shipped. May 13-May 27, 2026.

TN10 Gets One Last Toccata Hardening Fork

Toccata moved into what looks like the final hardening loop before mainnet. Michael Sutton said the final ZK audit found Groth16 verifier fixes that should be included before mainnet finalization. PR #1013 adds activation-gated hardening: stricter Groth16 input, verifying-key, and proof handling, plus per-public-input pricing to avoid worst-case constructions that could exceed the 10ms-per-block benchmark target. ^[1] (PR #1013)

The same update added one last SMT polish: an inactivity_shortcut link in the seqcommit context hash, pointing back to the seqcommit from F-time earlier. Sutton said this lets inactivity proofs hop through shortcuts instead of walking long linear paths, while avoiding a dependency inside the ZK guest on the exact inactivity threshold. ^[1]

By May 27, Sutton had merged PR #1013 and announced tn10-toc3, a final TN10 hardening hard fork on top of the already-activated TN10 Toccata logic. The release includes stricter Groth16 verifier handling, updated public-input pricing, and the SMT/seqcommit inactivity shortcut. Activation was scheduled for May 28, 2026 at about 16:00 UTC, DAA score 476,232,000. Sutton was explicit that mainnet is not affected by this TN10 activation. ^{[2] [3]} (release)

Inactivity Proofs Stop Walking Every Step

Hans shared the draft spec for the new inactivity shortcut construction, including algorithms for guests to prove inactivity spans with sublinear complexity. ^[4] (spec)

The design was still being tightened during review. Hans said the backlink commitment was changed to reduce the change surface and make the shortcut more self-contained, while keeping the general structure intact. ^[5]

The work landed quickly. Sutton merged PR #1018, said "This seals KIP21/SMT," and Hans posted the final spec. Sutton then merged PR #1019 and highlighted Maxim's summary of the shortcut: "It lets guests walk inactivity spans in O(N/F) hops instead of O(N), without knowing F." ^{[6] [7] [8] [9] [10]} (PR #1018) (PR #1019)

Header Versions Become the Fork Boundary

Before the TN10 hardening release, the channel spent time on how Toccata should express the fork boundary. coderofstuff argued that if the meaning of the seqcommit field changes, the block header version should be bumped. Sutton said the point was that outside entities should be able to verify header logic from the header itself, without needing the Toccata activation DAA score. ^{[11] [12] [13]}

The working shape was: miners produce the next block version after Toccata activation, header processing allows only that new version after activation, and virtual processing checks seqcommit the Toccata way for the new version while keeping the Crescendo check for older versions. coderofstuff wrote that down, Sutton called it the correct direction, and the discussion then narrowed around testnet compatibility and which checks should remain activation-score based. ^{[14] [15] [16] [17] [18] [19]}

That thread turned into active PR cleanup. Sutton marked PR #997 ready for review, then merged it the next day. He also merged PR #995, PR #998, and a side fix in PR #1003, while PR #1001 picked up SMT activation-flow review around metadata and pruning behavior. ^{[20] [21] [22] [23] [24] [25]} (PR #997) (PR #1001)

Fee Policy Gets an Interim Safety Debate

The pending Toccata branch also changes fee policy. Sutton said it raises the minimum standard feerate from 1 somp/gram to 100 somp/gram, and that the PR had already been merged into toccata with unanimous reviewer agreement to the best of his knowledge. ^[26]

The open question was not the target fee policy, but the rollout gap. Once the Toccata mainnet version is released, updated nodes would reject lower-fee transactions at both RPC and P2P level, and fee estimation would return 100 somp/gram as the lower bound. Non-updated nodes, however, could still accept and propagate lower-fee transactions for a while, which creates a risk that a user sees a transaction accepted before it later disappears from practical relay/mining paths. Sutton framed the choice as either treating that as low probability, or allowing an interim period where RPC rejects low-fee transactions while P2P continues accepting and broadcasting them until closer to the hard fork. ^[26]

Wallet Work Narrows Around Migration and Multisig

Wallet work also got pulled toward a cleaner scope. Demisrael said his wallet PR aimed to use the existing wallet and wallet-daemon infrastructure, with a binary matching the old Go wallet's arguments and output, and support for kaspa-cli wallet, multisig, Ledger, KDX 12-word seeds, and Tangem. ^{[27] [28]}

Maxim pushed for splitting the work into smaller PRs and avoiding storage-level fragmentation. His suggested direction was to add missing wallet-framework features first, including RBF, multisig, and ECDSA; migrate old wallets to the new storage format; and add a non-interactive CLI that mirrors Go kaspawallet while making the naming clear. ^[29] IzioDev agreed that the main reasons to keep using the Go CLI were missing multisig support and the interactive-only flow, and argued for filling multisig gaps, then adding a non-interactive CLI, then migrating the old Go keystore. ^[30]

The multisig thread continued into the wallet framework itself. IzioDev said he had a branch adding standard PSKT-based multisig support in both kaspa-cli and the wallet framework, with the main open question being the desired user flow for collecting cosigner xpubs and initializing accounts. ^[31]

Public API Planning Splits Into Short-Term Capacity and Long-Term Data Design

The REST API discussion from the previous article kept moving. elldeeone framed three separate problems: historical reconstruction and account balance verification, current REST freshness under high-UTXO caching pressure, and capacity/funding plus long-term data growth. ^[32]

The short-term track is more capacity for the current public API stack so it is not constantly operating at the edge. The long-term track is reducing the storage and indexing cost curve: pruning or scoping unnecessary indexes, separating hot and cold data, using append-only or cold storage for finalized history, and preserving API guarantees without keeping every expensive explorer-style index in the hot path. ^[33] elldeeone suggested the next practical output should be a short plan covering immediate infrastructure needs, what can be validated from existing data, when forward-looking historical balance tracking can be added, integrator-facing API guarantees, and the remaining unknowns. ^[34]

Script Time Checks Get a Sharp Edge Clarified

One smaller but important Silverscript/txscript clarification came from the age-lock discussion. manyfestation asked how OP_CHECKSEQUENCEVERIFY can be a solid timelock if the spending transaction's sequence field can be set by the spender. ^[35]

Sutton clarified that the consensus check only enforces one direction: the reported time must be at least the current consensus time. In Silverscript terms, (this.age >= X) == true is meaningful, but (this.age >= X) == false does not prove that the time has not passed, because the transaction builder can write a smaller value into the lock. He said the same applies to both this.age and tx.time. ^[36]

All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.