Kaspa ($KAS) core R&D - what developers discussed, debated, and shipped. Mar 28 - Apr 4, 2026.
TN12 Mempool Bug: Blocks Going Out Empty
Ross_ku_963 noticed TN12 blocks were being produced empty while the mempool reported over 1,400 pending transactions. (report) supertypo confirmed via tn12.kaspa.stream that a steady stream of transactions was flowing in, but the mempool count stayed stuck at 1,465. (confirmation)
Sutton traced it to a minor mempool bug in the tn12 branch. The mempool was accepting transactions with more compute mass than the block limit, meaning they could enter the mempool but never fit into a block. (diagnosis) The standard transaction mass limit needed to be set to 500,000. (fix) zlnck submitted PR 942 with the fix. (PR 942) Sutton merged it. (merged)
Ross_ku_963 dug deeper into the RebalancingWeightedTransactionSelector and flagged that if an oversized transaction is sampled first, the break on mass overflow stops selection entirely - potentially blocking valid smaller transactions. (analysis) Sutton acknowledged the issue: "It's a good thing you noticed this." (response)
Silverscript Gets a Big Refactor
someone235 pushed a major refactor of Silverscript. (PR 91) He also temporarily removed debugger recording from the compilation path, asking Manyfestation to collaborate on bringing it back. (note)
Ross_ku_963 filed detailed bug reports from covenant testing on TN12. He found that extremely large KAS literals like 99999999999999999 kas compile without error due to silent saturating multiplication. In debug builds, const X = 9223372036854775807 + 1 panics, but in release builds it wraps around - meaning compiled code can silently produce wrong results. He also noted that checkDataSig was pushing OpTrue without actually checking anything, though a TODO comment suggested it was known. (bugs)
someone235 clarified that OpAdd uses a subset of i64, not big integers. (clarification) He fixed the issues in PR 88. (fix)
Ross_ku_963 then raised a deeper concern: the runtime (OpAdd) uses i64 while eval_const_int also uses i64, but silent wrapping in release builds means the user's source code is correct but the compiled output is wrong - and you can't reproduce it in debug because it panics instead of wrapping. (deeper issue)
Manyfestation submitted a Silverscript PR adding source-level debugging support for covenant declarations and complex state-transition scenario creation, with support for prev_states and next_state. (PR 89)
Covenants vs Based Apps: The Developer Experience Debate
IzioDev shared a draft overview of Kaspa programmability and asked for feedback. (doc) Sutton opened a dedicated topic for the discussion, framing the main challenge: helping developers navigate between native L1 covenants and based zk apps. (topic)
Sutton proposed the framing question should not be "do I need execution concurrency" but rather "do I have many reads/writes from the same shared state variables, or is my app p2p by nature?" Shared state points to based apps. P2P points to covenants. (framing)
Manyfestation pushed back, arguing that directing developers toward covenants first makes more sense because of the high-level Solidity-like language and the ability to prototype instantly on testnet without dealing with ZK proving. "I cannot think of a simple, good use case for a based app, only complex ones." (pushback) He later elaborated that concurrency problems in DeFi could potentially be solved at the application layer - imagine a DEX pool split across multiple covenants that rebalance each other behind the scenes. (application layer)
IzioDev countered that if developers need to read a whole page just to pick the right tool, they'll abort the process and pick what feels easier - possibly on another platform. He argued for building for the 95% happy path. (DX argument)
BitCat1234 noted it's hard to imagine DeFi use cases for covenants without concurrency support, and suggested that most developers will get started by vibe coding anyway - so having a single place with plenty of full app examples would work better than a detailed user guide. (practical view)
Post-Quantum ZK: Ship Now or Wait?
dimsun argued against shipping non-post-quantum ZK in the hard fork. "Implementing non PQ zk in a new hf and allowing progs and covenants to be built using math that is likely to be cracked within the next few years seems like a blunder." He said he wouldn't use Groth16 in his protocols and that future-proofing should be the priority. (PQ argument)
saefstroem disagreed: "ZK as-is should be introduced right now to boost ecosystem growth. G16 is still widely used and an industry standard. If anything STARKs are much more vulnerable and have shown to be, recently." He pointed out that they already have r0 (RISC Zero) on TN12 and referenced KIP-16. (counter) He later added that there are concerns from key stakeholders about adding STARKs to the hard fork, given past vulnerabilities. (concerns)
UTXO Index Overhaul for Covenant Infrastructure
dimsun raised a practical infrastructure need: with 10,000-100,000+ UTXOs on a single vProg address, retrieving all UTXOs just to find the new ones wastes massive bandwidth. He proposed adding a DAA score filter to notifyUtxosChanged so local indexers can catch up efficiently after being offline. (proposal)
Dstakes looked into the current utxoindex structure and said ordering by DAA score is feasible. The current scheme indexes by script public key + transaction outpoint, which could be changed to script public key + DAA score + outpoint. (feasibility) He estimated 1-2 weeks to build an utxoindex API with inputs for address, from_daa_score, to_daa_score, and limit. (estimate)
Maxim noted that if UTXOs are stored in DAA score order, you can stream directly from the database to the socket without collecting and filtering - effectively pagination for free. (optimization)
dimsun and Dstakes split the work into milestones: utxoindex API changes, new database layout, database migration, and then the subscription endpoint changes. (plan)
Covenant ID Indexing for Subscription API
zlnck asked the group which API design would be better for covenant-aware UTXO queries: expanding the current subscription schema by adding covenant_ids, or creating a separate endpoint. (question)
IzioDev weighed in on the filter design: the key question is whether the new filter parameters are available at the same level as existing parameters in the notification trigger code, or if extra fetches would be needed. (design)
Ross_ku_963 noted that subscriptions handle real-time events, but every covenant app needs to rebuild state on restart. He suggested a script-prefix or covenant_id filter on getUtxos as the query-side counterpart. (cold start) IzioDev confirmed that creating a new storage index referencing UTXOs by their covenant_id has been discussed. (confirmation)
Toccata Hard Fork Outlook
Sutton published a Medium article outlining the Toccata hard fork. (article) He noted the hard fork will not be on May 5th as previously targeted, but about a month later. (timeline)
IzioDev said he was surprised by the expected 20-50% disk usage increase. (surprise) Sutton clarified it's mostly storage space from number-of-active-subnets worst-case scenarios, not average expected usage, and can be reduced by trading off another parameter. He later added the word "disk space" to clarify. (clarification)
ZK Programmability: Three Layers
pptheanon shared a framework for thinking about Kaspa programmability as three layers: regular covenants (pure L1, no proofs), zk inline (L1 enforced with off-chain computation proofs), and zk based (full off-chain execution anchored to L1). The real split, he argued, isn't covenants vs based - it's enforcement without proofs vs enforcement with proofs. (framework)
IzioDev pushed back that this framing misses the real limitation: the UTXO model, with one transition per UTXO and no native shared state. pptheanon acknowledged this but argued UTXOs define how state transitions are structured locally, while proofs determine how much you can abstract over. (debate)
Maxim shared benchmarks for his ZK covenant rollup example: under 30 seconds for 5 blocks with under 10 transactions on GPU. For 3,000 non-active transactions, about 4 minutes. He expected more precise results with KIP-21 the following week. (benchmarks)
Fast Transaction Relay and VPS Benchmarks
Dstakes got a transatlantic fast relay running between two nodes, each with 24 connected peers plus perigee for regional peer optimization. Results showed 30-50% of block relays happening via the fast transaction relay on both nodes - close to the theoretical ideal of 50% under uniform assumptions. (relay results)
He also discovered somewhat hidden "sp" (special promo) servers from Contabo that offer extra RAM, storage, and supposedly better CPU for about a euro more per month. The 250GB NVMe option at VPS-20 tier might just work as a minimum spec. (VPS tip)
Bridge UI and AppImage Packaging
dablacksplashjastar13 continued work on the rusty-kaspa bridge UI, adding Linux AppImage packaging with both .AppImage and .tar.gz formats. The tar preserves execute permissions for Linux users. (AppImage) H_YAALLH tested and reported everything working, with only occasional incorrect network hash readings on the web UI. (testing)
Flaky CI Tests
Maxim flagged flaky integration tests in CI, where timeout errors cause test failures. He asked whether this should be treated as a serious signal related to the notification system and latency, or simply a matter of increasing timeouts. (question)
Ross_ku_963 analyzed it: the 500ms timeouts in mine_block are called 12 times with 2 notifications and 2 clients, creating 48 timeout windows where any single miss fails the test. With worker_threads set to 1, async notification delivery gets starved under CI load. He suggested bumping timeouts to 5 seconds. (analysis)
All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.
