TL;DR

• KIP-21 sequencing component merged: A lane-based transaction ordering system with verifiable commitments was integrated into rusty-kaspa, establishing a foundation for programmable features ahead of the Toccata feature freeze and TN12 reset.

• STARK proof trade-offs discussed for Toccata: Supporting larger zk proofs could double block data and disk usage, prompting discussion of higher minimum fees as a node-level filter rather than a consensus change.

• Multisig test leads to draft wallet KIP: A successful 2-of-3 Kaspa multisig transaction exposed undocumented behaviors, prompting a proposal to standardize wallet conventions and prevent implementation errors.

• Oracle research framework published: Eliott Mea released a draft paper outlining a mathematically grounded design for price oracles on Kaspa, focusing on provable security, fair pricing, and resistance to manipulation; no deployment timeline announced.

• 20 BPS devnet test reveals memory limits: Sustained ~6k TPS runs led to node crashes at ~15 GB RAM, indicating that 16 GB systems lack headroom for higher throughput despite stable storage and CPU performance.

• Node resource study identifies storage bottleneck: Testing at ~10 BPS / ~3k TPS shows disk performance, not CPU or RAM, as the primary constraint, with 8 vCPU / 16 GB RAM + SSD emerging as the lowest stable configuration under sustained load.

• Genesis Proof CLI v1.0.0 released: Luke Dunshea published a Rust-based tool that adapts Kaspa’s original genesis verification notebook to modern nodes, enabling full chain-to-genesis validation on pruned nodes with added checkpoint supply verification via MuHash.

• Kaspa surpasses 2B transactions: Cumulative network activity crossed 2 billion, reflecting sustained high-throughput usage at ~10 BPS.

KIP-21 Sequencing Component Merged Ahead of Toccata Freeze

Michael Sutton confirmed the approval and merge of a major component tied to KIP-21 into the rusty-kaspa codebase, describing it as a near-final step before the Toccata feature freeze and TN12 testnet reset. The implementation introduces a lane-based sequencing commitment system built on a 256-bit Sparse Merkle Tree. Kaspa Core Developer Michael Sutton shared:

“I think one day we will look back and better understand, myself included, how important this component is for Kaspa and for the sequencing and programmable capabilities it opens up.”

The work, led by Maxim Biryukov, enables transactions to be organized into structured “lanes” with verifiable ordering, using compact cryptographic commitments that allow this order to be proven without processing the full dataset.

This establishes a reliable foundation for applications that depend on predictable and provable execution, including covenants and other programmable systems. The merge marks a transition from active development toward stabilization ahead of the upcoming testnet reset.

Moreover, Sutton addressed questions about the potential hardware and resource implications of the upcoming Toccata hard fork, citing a recent technical note on STARK proof support and block sizing.

“STARK proofs require double the byte-size of the current Kaspa block limit (125kb→250kb).”

The discussion centers on whether enabling STARK proofs on mainnet, already active on TN12, should be paired with adjustments to network assumptions. STARK proofs are cryptographic proofs that verify computations off-chain, but are significantly larger than typical transactions. Supporting them would increase block data requirements, potentially doubling current limits and raising disk usage under high-throughput conditions.

“Doubling the disk requirements… requires increasing the min fee ratio 10–100x so that max-throughput usage is organic and economic, and not driven by stretch testing.”

Sutton frames this as a standardness-level consideration rather than a consensus change, meaning it would affect how nodes choose which transactions to accept and relay, not what is considered valid by the network. In this context, higher minimum fees would act as a filter to discourage large, low-value transactions from filling blocks at minimal cost.

More complex approaches, such as dynamic block size elasticity, remain an open research area and are not yet ready for inclusion in Toccata.

The exchange highlights a broader design tension: enabling advanced features such as ZK-proof verification while maintaining sustainable resource use and economic incentives across the network.

KasSigner Multisig Test Leads to Draft KIP for Wallet Conventions

KasSigner reported a successful 2-of-3 multisig transaction broadcast on Kaspa mainnet using the PSKT/PSKB wire format end-to-end, without relying on custom intermediate representations. The transaction was accepted into a block in approximately 752 milliseconds, demonstrating a fully native signing and broadcast flow.

The test surfaced several Kaspa-specific behaviors that are not currently well documented for wallet developers, including requirements on sigOpCount ranges, the absence of Bitcoin’s OP_0 dummy in CHECKMULTISIG unlock scripts, and the use of signature variant tagging within PartialSig fields. These conditions fail at broadcast if implemented incorrectly, preventing invalid transactions from entering the chain.

Following this, a draft KIP titled “Multisig Wallet Conventions for Kaspa” was submitted by InKasWeRust. The proposal is informational and introduces no consensus changes; instead, it defines wallet-level conventions such as derivation paths, cosigner key ordering, redeem script construction, and descriptor formats. It also documents existing consensus behaviors and outlines optional transport and size optimizations to enable participation from constrained hardware devices.

The proposal is positioned as a developer-facing reference layer on top of existing PSKT infrastructure, aiming to standardize multisig implementations across wallets. Without this, developers porting multisig logic from Bitcoin are likely to encounter subtle incompatibilities that can cause transaction failures, underscoring the criticality of clear documentation for reliable implementation.

Eliott Mea Advances Formal Oracle Framework, Seeks Broader Support

Eliott Mea shared progress on an ongoing research effort to develop a mathematically rigorous framework for price oracles on Kaspa, outlined in his draft paper “A Mathematical Framework for Price Oracles.” The work, currently funded by Kaskad, is positioned as foundational infrastructure for future DeFi systems. In the announcement post, Mea wrote: 

“Oracles are not optional infrastructure for DeFi: they are the foundation everything else is built on… I’d rather we have something mathematically sound than ship something that gets exploited six months later.”

The draft framework defines a “fair price” across multiple exchanges using a consolidated order book model and analyzes its stability under market perturbations. It further models a decentralized arbitrage network to study convergence toward accurate pricing, alongside a formal adversary framework showing that manipulation requires capital proportional to the value being settled. The work also derives an optimal publication delay, highlighting a tradeoff between precision and staleness.

Mea indicated plans to expand the research alongside a separate L1 auction design initiated under Yonatan Sompolinsky, and is seeking additional funding to continue development. The framework remains in a draft research phase, with no deployment timeline announced.

This Week’s Hero: Luke Dunshea Introduced and Upgraded Signigicant Kaspian Tools 

Luke Dunshea shared results from a devnet experiment targeting ~20 BPS and ~6,200 TPS, highlighting emerging resource constraints at higher throughput levels. The test used a multi-node topology with a primary bootstrap node handling transaction load, a relay node performing IBD and syncing, and separate hosts for transaction generation and supplementary mining.

During the run, the bootstrap node maintained target throughput for approximately 7.5 hours before the kernel terminated it due to memory exhaustion, with kaspad reaching ~15.2 GB RSS. The relay node completed IBD and pruning without failing during the valid window, and storage performance remained stable, with low write latency and no RocksDB stalls.

However, memory usage on the relay steadily increased throughout the run, rising from ~2 GB at startup to over 12.5 GB during operation and continuing to increase after pruning. While CPU utilization was elevated—particularly on the bootstrap node—it did not appear to be the primary bottleneck; memory pressure emerged as the dominant failure signal.

The results suggest that while ~20 BPS / ~6k TPS can be sustained for extended periods with tuning, nodes in the 16 GB RAM class may lack sufficient headroom for stable long-term operation under these conditions. Further testing is planned on higher-spec configurations (e.g., 12 vCPU / 24 GB RAM) to better define the resource envelope at elevated throughput levels.

Node Resource Study Defines Hardware Baseline Under High Throughput

Moreover, Luke published a report examining Kaspa node performance under sustained high-throughput conditions, using a controlled devnet environment configured to mirror mainnet at 10 BPS and ~3,000 transactions per second. The study evaluates node behavior across initial sync, steady-state operation, pruning cycles, and downstream serving scenarios.

“Across the measured runs, the failing hosts showed severe storage-path distress: high write latency, deep queue depth, and elevated iowait well before memory exhaustion,” the report states. 

The findings identify storage performance, not CPU or memory, as the primary bottleneck under stress. Nodes with weaker storage paths experienced latency buildup and eventual failure, including out-of-memory terminations, even when provisioned with relatively high CPU and RAM. In contrast, a cloud instance with 8 vCPU, 16 GB RAM, and local SSD storage maintained stable operation across all tested phases, including serving multiple downstream peers.

The report establishes this configuration as the lowest tested “passing” profile under heavy load, while noting that smaller setups (e.g., 4 vCPU / 12 GB RAM) failed to sustain long-term operation. It also indicates that serving additional peers primarily increases read and CPU load rather than write pressure.

The study is positioned as a bounded operating envelope rather than a universal requirement, providing an empirical reference point for node operators evaluating hardware requirements under peak conditions.

Genesis Proof CLI Revives Verification Path for Pruned Nodes

Moreover, Luke released v1.0.0 of a Genesis Proof CLI, adapting the original notebook by Shai Wyborski and Michael Sutton into a Rust application compatible with both Kaspad and rusty-kaspa.

The tool verifies the chain from the current state tip back to genesis, including header continuity, UTXO commitments, and original coinbase conditions. It also introduces additional validation of the checkpoint snapshot by deriving the total supply from a verified UTXO dump whose MuHash matches Kaspa’s checkpoint commitment, extending the guarantees of the original notebook. Dunshea shared:

“Pruning does not mean ‘just trust us.’ It means the verification model is different, and people should still be able to check that for themselves.”

The release provides a practical verification path for pruned nodes, where historical data is not retained locally but integrity is maintained through cryptographic commitments. The repository is open and includes prebuilt binaries across major platforms.

Transaction Generator Tool Enables High-TPS Testing on Kaspa

Lastly, Luke released an updated fork of LiberatedPotato's transaction generator, adding devnet compatibility for stress testing and performance evaluation within the rusty-kaspa environment. The tool connects via gRPC and allows users to generate sustained transaction throughput at configurable rates, supporting testing across mainnet, testnet, and devnet setups.

The generator prepares large pools of spendable UTXOs by splitting existing balances into smaller outputs, then issues continuous 1-input/1-output transactions at a target TPS, maintaining a high-throughput pipeline through asynchronous submission and periodic UTXO refresh. It includes safeguards such as network validation checks and configurable pacing to ensure stable operation during testing.

Designed for developers and node operators, the tool provides a controlled way to simulate load conditions, benchmark node performance, and evaluate network behavior under stress. The release complements ongoing infrastructure research efforts by enabling reproducible transaction-level testing across different environments.

Seb Expands Tooling Across Research and Node Deployment

Seb, creator of KasMap, introduced two tools this week targeting both protocol research and node accessibility: an ultralight node-testing framework (KUN) and a one-click full-node installer (MyKAI).

The Kaspa Ultralight Node (KUN) is an early-stage, open-source project designed to test real-world assumptions behind KIP-6’s proposed Proof of Chain Membership (PoChM). Rather than relying on theoretical estimates, the tool measures live network conditions such as header sizes and selected-chain growth, with early data suggesting meaningful impacts on projected proof sizes. The current release (v0.1.1) enables reproducible testing and independent verification, and is positioned as a research framework rather than a production-ready client.

Alongside this, the MyKAI tool introduces a one-click installer for running a full Kaspa node, aimed at lowering the barrier for non-technical users. Currently available for Windows (with Mac and Linux support planned), the installer automates setup and syncing, making it easier to contribute to network decentralization through increased node distribution.

Together, the releases span both protocol research and infrastructure accessibility, with KUN exploring future ultralight verification models and MyKAI simplifying participation in the network today.

Kaskad Frames Design Differences Following rsETH Exploit

Kaskad published a technical breakdown after an estimated ~100–293 million USD in value was drained from Aave V3/V4 through the rsETH/KelpDAO incident. The exploit originated from a bridge vulnerability that allowed unbacked rsETH to be minted and used as collateral, ultimately leaving the lending protocol with significant bad debt. The team characterized the event as a failure in upstream trust assumptions rather than a flaw in Aave itself.

In response, Kaskad outlined key design differences in its staking model, emphasizing that stKSKD is used for governance rather than leverage. The system requires both staked tokens and sustained capital participation (TVL) over time to accrue voting power, with additional weighting based on uptime and holding duration, limiting the effectiveness of short-term or opportunistic staking.

The protocol also highlighted its isolated minting mechanism, in which stKSKD is issued 1:1 against locked KSKD, with no reliance on external bridges or variable share calculations. This design removes dependencies that can introduce inconsistencies between minted assets and underlying collateral.

The post positions these choices within a broader critique of DeFi composability risks, particularly where layered dependencies can propagate failures across protocols. In contrast, Kaskad emphasizes simpler, verifiable primitives and participation-based governance as a foundation for more resilient system design.

AI Agents Framed as Emerging Interface Layer for DeFi

A recent XXIM Podcast episode featuring Louis from ZealousSwap focused on the growing role of AI agents as a potential replacement for traditional DeFi interfaces. The discussion framed current DeFi UX as a major barrier to adoption, with AI agents positioned as an abstraction layer that can execute complex on-chain actions from simple user intent. Louis stated:

“AI agents are becoming the killer UX layer for DeFi… how it's sort of replacing or bypassing traditional UIs.”

The conversation outlined a three-phase model for agent adoption: current systems in which agents suggest actions but require user approval; an intermediate phase enabled by permission frameworks (such as account abstraction); and a longer-term model in which agents autonomously manage portfolios and execute strategies across protocols and chains.

Practical examples highlighted how agents could simplify multi-step workflows, such as bridging assets across layers or optimizing swaps, while also mitigating risks like MEV and liquidation through automated execution strategies. The episode also noted early integrations of agent-compatible “skills” within protocols, allowing faster onboarding and more deterministic behavior.

The discussion positioned Kaspa as a favorable execution environment due to its speed and reliability, particularly for agent-driven activity where latency and execution certainty directly impact outcomes. However, key infrastructure gaps remain, including robust permission systems and improvements to agent memory and reliability, before fully autonomous DeFi interaction becomes viable.

Repo Market Stress Signals Underlying Liquidity Strain

In another XXIM Podcast segment, host Ankit drew attention to rising stress in traditional financial infrastructure, noting that repo fails surged to approximately $415 billion in a single week—more than double comparable levels from the prior year. Repo failures refer to situations in which one party to a repurchase agreement fails to deliver cash or collateral on time. Ankit shared:

“Repo fail jumped to $415 billion for that week… a spike like this signals serious trouble brewing in the banking system.”

The episode framed the repo market as a core liquidity layer—“the plumbing” of global finance—where institutions exchange cash for short-term collateral, typically U.S. Treasuries. Disruptions in this system, particularly failures to return collateral, can indicate deeper structural issues such as collateral hoarding and stress in interbank lending chains.

Ankit contextualized the current spike by comparing it to prior episodes of financial strain, including 2008, 2019, and the COVID-era liquidity crisis, where similar dislocations prompted central bank intervention. The discussion emphasized that such signals often emerge beneath the surface, even as equity markets continue to perform strongly.

The segment positions repo market instability as a leading indicator of systemic risk, highlighting the importance of monitoring underlying liquidity conditions rather than relying solely on headline market performance.

AI Agents Framed as Fit for Kaspa’s Settlement Layer

KaKa shared a thesis positioning Kaspa as a natural settlement layer for AI-driven systems. The post argues that while AI agents generate and execute tasks off-chain, Kaspa provides high-speed, low-cost infrastructure for recording ownership and settling value.

The framing highlights machine-to-machine activity, where Kaspa’s BlockDAG architecture could support high-frequency, low-value transactions and enforce authorization through wallets and programmable rules. KaKa shared:

“AI and Kaspa are like two sides of the same coin: one side enables machines to create value, while the other enables machines to confirm, exchange, and preserve value at a higher speed.”

Gate.io Adds Kasplex L2 Support for KAS Deposits and Withdrawals

Gate.io announced support for Kasplex deposits and withdrawals, enabling direct access to the Kasplex L2 ecosystem without the need for external bridging.

The integration allows users to deposit and withdraw KAS directly between Gate and the Kasplex L2, without relying on external bridging tools, reflecting early alignment between centralized exchanges and emerging Layer 2 infrastructure on Kaspa.

Krok: Kaspa-Focused Q&A Agent in Early Testing

A new Kaspa-focused Q&A agent, “Krok,” was shared this week by contributor coinathlete as an early-stage tool for answering technical questions about the network. The agent is currently trained on Kaspa-specific sources, including kaspa.news content, R&D summaries, code documentation, and live network data where available.

In its current form, Krok is limited to core protocol knowledge and does not yet cover third-party or ecosystem projects, though broader support is planned. The tool is positioned as an interactive interface for querying topics such as GHOSTDAG, Rusty-Kaspa, mining, wallets, and covenant-related development, with ongoing user testing.

Kastle Wallet Introduces Opt-In Analytics

Kastle Wallet released Mobile v1.19.0 and Extension v2.51.0, adding an opt-in analytics feature to improve product usability while preserving user control over data collection.

The update tracks high-level usage flows, including wallet creation, transactions, swaps, and bridging activity, without collecting sensitive information such as wallet addresses, balances, private keys, or IP data. The feature is disabled by default and can be toggled at any time through the app’s Data & Privacy settings.

The release introduces a structured feedback layer for wallet behavior, allowing developers to observe aggregate usage patterns while avoiding direct linkage to on-chain identities.

Kaspa Surpasses 2 Billion Total Transactions

As of April 25, 2026, Kaspa’s cumulative transaction count has surpassed 2 billion, according to data from the Kaspa Explorer. The milestone reflects aggregate activity across the network’s BlockDAG architecture, where transactions are processed in parallel rather than in a single linear chain.

The figure represents total usage since network launch and continues to increase alongside sustained block production at approximately 10 blocks per second. As a cumulative metric, total transaction count serves as a broad indicator of network utilization, though it does not distinguish between transaction types or underlying economic activity.

London Kaspa Meetup Returns for Part 2 at Wolfy’s Bar

A second London meetup, “Industry Adoption: Kaspa’s Unstoppable Scalability – Part 2,” is scheduled for May 7 at 6:00 PM at Wolfy’s Bar, following an earlier event at the same venue. The meetup is organized with Blockchain Banter and sponsored by the Kaspa Ecosystem Foundation and Kastle Wallet.

As with prior events, attendees can receive up to 40% off food and drinks when paying with KAS via Kastle Wallet, and on-site payment demonstrations will continue. Registration is available via Luma.