Kaspa ($KAS) core R&D - what developers discussed, debated, and shipped. Apr 5-12, 2026.
KIP-21 Lane Limits Move From Theory Toward Implementation
zlnck shared his first concrete implementation plan for lane-limited block selection under KIP-21. (source) The idea is to bucket mempool transactions by lane, calculate a value per lane from the top fee-rate transactions, sample up to 50 lanes, and then run the usual weighted-random transaction selection inside those chosen lanes under the block mass limit. (source)
Sutton pushed for a conservative rollout. If the mempool has fewer than 50 lanes, he sees no reason to change anything: fee market pressure alone should decide what gets into a block. (source) His suggestion was to optimize for the case that actually matters before the hard fork, and only fall back to a simpler, non-optimal strategy when lane count exceeds the protocol cap. (source)
That led to a more precise design argument about what the "ideal" block-filling algorithm should even mean once lane limits exist. Sutton argued that the benchmark should be an unconstrained ideal solution first, then a practical approximation can be measured against it. (source) zlnck's concern was that naive heuristics could produce ugly outcomes like a single lane taking 80% of a block. (source) The discussion did not settle the final algorithm, but it did clarify the immediate target: minimal, reviewable logic for Toccata rather than a perfectly tuned fairness engine.
Script Pricing Rules Finally Landed
Sutton approved PR #884 by Ori Newman, calling out that it handles the new script pricing mechanism and saying the resulting rules should probably be extracted into a KIP for more abstract review. (source) (PR #884)
The merged change adds more granular script pricing and a compute_budget field for v1 transactions. (PR #884) Sutton also described it as "a delicate PR" and explicitly asked for heavy testing over the new behavior before moving on. (source)
That matters because script pricing is no longer just background plumbing. With covenant-heavy usage coming closer, pricing rules shape what kinds of scripts are practical, how block space gets allocated, and how safe it is to expose new programmability without accidental resource underpricing.
Docs Shift From Primitive Lists to Opinionated "How Do I Do X?"
IzioDev published a wider Kaspa docs portal draft and explained the direction clearly: not a catalog of primitives, but documentation that answers practical builder questions like how to listen to accepted transactions, with opinions where it matters. (source) The draft lives at kaspa-docs.kaspa.workers.dev for now. (source)
That builder-first approach also showed up in the bridge tooling work. IzioDev's stated goal for the bridge app is a self-contained package with everything needed to get started: download, extract, click, and only edit config later if needed. (source) Dablacksplashjastar13 followed with PR #936, adding Linux double-click launch support, release-build packaging updates, a stop feature when the node falls out of sync, and bundled config plus launch scripts. (source)
Real usage numbers are starting to appear too. Dablacksplashjastar13 reported 46 miners using RK-Stratum and 34 still using the older Go bridge. (source) (source) It's a small datapoint, but it suggests the Rust bridge is already pulling ahead in real deployments.
Silverscript Keeps Sanding Off Language Friction
Ori Newman merged two Silverscript PRs aimed squarely at developer ergonomics. PR #95 changes function-call behavior so helper functions can call other helper functions regardless of declaration order, while explicitly rejecting recursion, mutual recursion, and any calls into entrypoints. (source) (PR #95)
PR #96 extends single-return ergonomics further. Single-return signatures can now omit parentheses, return statements can use bare syntax, and single-return helper calls can participate directly in normal expressions. (source) (PR #96)
None of this changes Kaspa's programmability model on its own. What it does change is the day-to-day cost of writing and refactoring covenant code. That's usually how adoption happens in practice: not through one giant feature, but by removing the little bits of friction that make developers hesitate.
Reset2 Trips Over Old State, While ZK Tooling Moves Forward
Manyfestation hit an invalid merkle root error while trying to finish IBD on the latest covpp-reset2 branch. (source) The diagnosis came quickly: the node likely did not have a fresh database, and recent changes to v1 transaction hashes could affect merkle roots. (source) There was a second gotcha too - the right branch to run was tn12, not covpp-reset2 as assumed. (source) (source) Once Manyfestation switched to a fresh DB, the issue was resolved. (source)
Around the same time, Saefstroem posted PR #953 and said the ZK SDK is ready for review, even if the pipeline still needs to pass cleanly. (source) (source) The stated goal is to lower the knowledge barrier for working with UTXO-based ZK systems by letting developers convert RISC Zero receipts into native Kaspa scripts. (PR #953)
Taken together, those two threads tell the same story from opposite ends. The protocol and tooling stack is still rough enough to punish stale assumptions like an old database or the wrong branch name, but it is also getting steadily more packaged, more opinionated, and more accessible to the next wave of builders.
All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.