TL;DR:

Silverscript launches on Testnet-12: Kaspa’s first high-level covenant language goes live experimentally, enabling L1 DeFi, vaults, and native asset management while compiling directly to Kaspa Script.
Covenant stack converges: Michael Sutton outlines how Silverscript (tooling layer) and KIP-20 Covenant IDs (consensus layer) align to make stateful L1 contracts practical “without recursive lineage proofs.”
vProgs node architecture matures: Hans Moog submits three PRs introducing checkpoint metadata, rollback–pruning coordination, and bridge alignment, strengthening execution traceability and reliability ahead of the node framework.
600M transactions milestone: Kaspa surpasses 600M transactions since launch, reflecting sustained high on-chain throughput.
Ecosystem outreach expands: KEF moderates at Consensus Hong Kong as mainstream coverage (BSC News) spotlights the May 5, 2026, covenant-centric hardfork roadmap.
The application layer is accelerating: KaChat iOS beta, K Social mainnet release, BlockSec Arena’s Kasplex deployment, and 293 hackers in Kaspathon signal growing builder momentum beyond payments.

Silverscript launches as Kaspa’s first high-level smart contract language (Experimental)

Kaspa core developer, Ori Newman (@OriNewman), announced Silverscript, describing it as “Kaspa’s first high-level smart contract language and compiler,” designed to enable “DeFi, vaults, and native asset management directly on Kaspa’s L1.” The language draws inspiration from “CashScript,” a higher-level smart contract language originally developed for Bitcoin Cash (BCH), but adds constructs such as “loops, arrays, and function calls” to expand expressiveness within Kaspa’s UTXO model.

Newman explained that Silverscript specializes in managing “contracts with local state (UTXO model),” positioning it as “a complement and infrastructure layer for vProgs (shared state).” Rather than introducing a separate virtual machine, Silverscript compiles down to native Kaspa Script, meaning contracts execute directly on the Kaspa Layer 1.

The release is powered by “new script engine features recently enabled on Testnet-12.” Newman noted that the syntax is experimental and may evolve, encouraging developers to test the language and provide feedback. The current SDK is implemented in Rust, with potential WASM support planned in the future. The GitHub repository labels the project experimental, and the compiled output is currently valid only on Kaspa Testnet-12. Newman also indicated that more advanced examples, including token handling, are forthcoming.

Early community reactions to X reflected enthusiasm:

@wtty_jhn wrote, “L1 programmability done the Kaspa way. Excited to see what devs build with this. Wonderful work.”
@earthianin highlighted “Native asset management directly on #Kaspa L1 — without useless layer 2s, bridges, and zk-rollups,” calling it “a new era for #Kaspa.”
@bytebarian commented that “the syntax looks so elegant. Looks like a mix of C, Rust, and JavaScript.”

Notably, Michael Sutton clarified that Silverscript was the development he had been hinting at days earlier. On January 29, he wrote, “Nice summary. Tbh, the most exciting recent development is actually still in stealth mode. Soon^TM.” Silverscript appears to have been the development he was referencing.

Michael Sutton Outlines Convergence of Silverscript and KIP-20

Following the announcement of Silverscript, Michael Sutton outlined how the language fits into Kaspa’s broader covenant roadmap. He wrote that “Kaspa’s covenant stack is converging on a shared goal: make real L1 apps approachable, and make secure design the default rather than an expert-only art.”

Covenants are programmable constraints attached to UTXOs (unspent transaction outputs) that restrict how coins may be spent in future transactions. Covenants++ is the planned Layer 1 protocol upgrade that expands Kaspa’s native covenant functionality. Within that framework, KIP-20 introduces Covenant IDs, consensus-tracked identifiers that establish stable lineage for stateful contracts across transaction transitions.

Sutton described two layers of the covenant stack landing in tandem. At the top is Silverscript, recently introduced as Kaspa’s first high-level covenant language and compiler, designed to make covenant authoring feel like “writing apps,” not “fighting script,” and targeting local-state applications within the UTXO model. At the foundation of that stack is KIP-20 (Covenant IDs), a consensus-layer primitive that makes stateful covenants practical at scale “without recursive lineage proofs,” meaning contracts no longer need to carry parent or grandparent transaction data to establish identity across transitions.

He explained that while UTXOs already tie “rules own state” locally through the spending script, the challenge lies in preserving that relationship across transitions in a local-compute model. KIP-20 tightens this linkage at the consensus layer by introducing a Covenant ID tracked directly by consensus. As a result, covenant identity and lineage become native properties rather than being reconstructed through ancestor transactions, simplifying the design of vault schemes, token logic, and other structured state transitions.

The broader theme Sutton emphasized is “security-by-construction.” In this framing, approachability is not just improved syntax. It means making it easy to write covenants that correctly validate state transitions and making it difficult to accidentally deploy insecure schemes. The direction, he noted, is for the compiler to generate transition logic and wrap it in schematic code that enforces a declared covenant pattern.

Together, Silverscript at the tooling layer and KIP-20 at the consensus layer represent a coordinated effort to expand Layer 1 programmability on Kaspa while preserving its PoW security assumptions and UTXO model.

Hans Moog Advances vProgs with Checkpoint Architecture and Node Reliability Updates

Hans Moog, a core architect behind Kaspa’s evolving execution framework, has submitted a series of pull requests to the vProgs repository to strengthen node reliability and prepare components for integration into the upcoming node framework. A pull request, or PR, is a proposed code change submitted for review before being merged into a project’s main codebase. This process allows maintainers to examine, test, and discuss modifications before activation.

PR #12 introduces BatchMetadata support in the scheduler by creating the Checkpoint and BatchMetadata structures. As Moog explained, “This will be used by the upcoming node framework to connect the two components in a transparent way where each produced effect can be mapped back to its source + context on the L1. Instead of addressing executed batches purely by their index, we now address them as a combination of index + metadata — a Checkpoint which transparently maps to the subset of L2 activity contained in a ChainBlock on L1.”

Previously, the scheduler tracked execution batches sequentially, which was sufficient for ordering and internal bookkeeping but did not provide a native way to trace execution state back to a specific consensus artifact such as a block hash. Any node requiring that linkage had to maintain its own external mapping logic, introducing operational fragility, especially across crashes or rollbacks. With the new design, metadata is injected at scheduling time and persisted, reverted, and pruned in lockstep with execution state. Execution progress and base layer context now move together as a single unit, allowing deterministic reconstruction of which base layer state corresponds to which execution state.

Also this week, Moog submitted PR #13, introducing what he described as a “coordination mechanism between rollback and pruning, which are two independent processes that need to make sure that they don't interfere with each other.” Previously, the two paths operated independently. Rollback means reverting the node’s execution state to an earlier point, while pruning permanently deletes older historical data to reduce storage usage.

Although a rollback overlapping with pruning “should likely never happen,” Moog wrote that “to make the L2 node bulletproof, we need to handle all edge cases (even the ones that have an astronomically low chance of ever happening).” If a rollback target falls inside the pruning window, “the pruning should pause,” otherwise the rollback must abort if the relevant data has already been removed.

Moog further noted, “This PR closes that gap with a Dekker-style handshake between the two paths using SeqCst atomics, guaranteeing that at least one side always detects a conflict: either the pruning worker aborts its current pass, or rollback_to returns an error.” In concurrency terms, a Dekker-style handshake is a two-process synchronization pattern in which each side signals its intent, and a shared coordination mechanism ensures they cannot proceed simultaneously into conflicting states.

Moog confirmed that “All 16 existing e2e [end-to-end] tests updated and passing, including new assertions that verify metadata round-trips through commit, rollback, pruning, and crash recovery.”

Shortly after PR #13, Moog submitted PR #14, which introduces ChainBlockMetadata and updates the L1 bridge to use Checkpoint in its public API, aligning bridge events with the scheduler’s checkpoint model. As he explained, “This PR mirrors the Checkpoint-related changes we previously introduced in the Scheduler in the L1 bridge, so both components can speak the same ‘language’ before connecting them in the node framework. It also introduces a ChainBlockMetadata type that contains relevant metadata about each ChainBlock that gets passed through to the L2 execution.”

Together, these PRs reinforce a key architectural objective within Kaspa’s evolving execution model: explicit, consensus-aligned traceability between block production and execution artifacts, combined with resilient state handling under rollback and pruning. Rather than introducing a separate Layer 2 system, this work advances a modular execution framework that operates in alignment with Kaspa’s base-layer blockDAG.

Kaspa core developer Michael Sutton publicly praised the implementation, writing, “Your code is one of the classiest I’ve seen, and I don’t take that word lightly ;)” underscoring the technical rigor behind the ongoing node framework development.

Kaspa Hits 600M Transactions

As of February 14, 2026, Kaspa has processed more than 600 million transactions since launch. The network has been live for approximately 1,552 days, implying an average of roughly 386,000 transactions per day.

For context, Bitcoin has been live for over 6,000 days and averages approximately 170,000 transactions per day. While the two networks differ significantly in architecture, block production, and fee dynamics, the comparison highlights Kaspa’s high-throughput design and sustained on-chain activity since inception.

Cumulative transaction count does not reflect application mix or economic density, but it does provide a historical measure of live network usage and operational stability.

Consensus Hong Kong 2026

The Kaspa Eco Foundation (KEF) reported that Head of Partnerships Evie (@Evie_Y2001) moderated a panel titled “Yield Sources and Risk Boundaries in DeFi & CeDefi” during Consensus Hong Kong. The discussion featured participants from TRON DAO, Spark, Bancor, and Cicada, focusing on evolving models for risk management and returns in on-chain finance.

KEF described the session as “driving the conversation on the future of on-chain asset management,” emphasizing cross-ecosystem dialogue and exposure to broader DeFi and CeDeFi audiences. The foundation also thanked @MSTRStablecoin for hosting and curating the event.

Kaspa’s presence at a major Asia-based industry conference situates the ecosystem within broader institutional and infrastructure discussions around on-chain finance. Participation in these forums reflects continued outreach beyond core protocol research, positioning Kaspa within global DeFi conversations as programmability and asset-management tooling continue to expand.

BSC News covers Kaspa’s Covenant-centric hardfork Roadmap

BSC News, which reaches over one million followers across platforms, published a feature outlining Kaspa’s upcoming covenant-centric hardfork scheduled for mainnet activation on May 5, 2026. The article characterizes the upgrade as a scoped expansion of Layer 1 programmability, introducing native assets including KRC20, extended Covenants++ functionality, and zero-knowledge verification, while preserving proof-of-work consensus and existing node requirements.

The report highlights several pre-fork milestones, including a Testnet-12 reset to support covenant and native asset testing (planned for February 2026), a Sequencer Commitment KIP to strengthen real-time decentralization, and the release of Silverscript as a higher-level covenant development language. Post-hardfork roadmap items referenced include DAGKnight, targeting adaptive consensus and throughput above 100 BPS, as well as the broader rollout of vProgs (Verifiable Programs), sovereign execution environments that run externally while settling results on Layer 1 through cryptographic proofs.

The article also discusses the introduction of the Computational DAG, or CDAG, which tracks program read and write declarations to regulate dependencies and gas commitments. This structure enables separation between computation and settlement while maintaining shared sequencing on the base layer.

On the zero-knowledge front, the piece notes Groth16 verification support, a proof system that allows computations to be verified on-chain without revealing underlying data, as well as potential trustless bridge implementations. It emphasizes that the hard fork does not modify node requirements or alter core security budget mechanics, framing the upgrade as infrastructure enablement rather than a change to consensus fundamentals.

The coverage reflects continued mainstream crypto media attention on Kaspa’s expanding programmability stack as covenant extensions, native assets, CDAG, and vProgs progress toward coordinated deployment. For readers new to Kaspa’s roadmap, the article provides a structured, high-level overview of upcoming protocol milestones and architectural direction.

New Kaspa.com article on Smart Contracts

Kaspa.com published an explainer on February 13 titled Smart Contracts, providing a structured overview of the network’s expanding contract capabilities. The article explicitly notes that it spans multiple development phases, covering features already live on mainnet, upgrades active on testnet, draft proposals, and longer-term roadmap components rather than limiting discussion to currently deployed functionality.

The piece defines smart contracts as self-executing programs that enforce predefined conditions through code and situates Kaspa’s architectural challenge within its high-throughput blockDAG design, which expands programmability while preserving proof-of-work security and performance guarantees.

Currently active on mainnet is KIP-10 transaction introspection, introduced during the Crescendo upgrade, which enables scripts to access transaction data during validation. This capability supports more advanced covenant patterns and structured state transitions that were previously difficult to implement under basic script constraints.

The roadmap section outlines several forthcoming enhancements:

KIP-17 (Full Covenants), extending introspection across transaction fields
KIP-20 (Covenant IDs), introducing consensus-tracked identifiers for stable covenant lineage
KIP-16 (ZK Precompiles), enabling on-chain zero-knowledge proof verification
KIP-18 (Simplicity Integration), supporting formally verified program execution
vProgs, described as future sovereign programs supporting externalized computation with on-chain verification

The article emphasizes continuity in design philosophy, noting that expanded expressiveness does not alter Kaspa’s core proof-of-work model or economic finality assumptions. Instead, functionality is layered incrementally, preserving UTXO security properties while broadening contract capabilities.

It concludes by describing the roadmap as modular and forward-compatible, enabling the integration of new cryptographic techniques and execution paradigms without requiring fundamental changes to the consensus protocol.

Overall, the explainer frames Kaspa’s smart contract strategy as evolutionary rather than disruptive: Bitcoin-compatible at the base layer, increasingly expressive through covenant and introspection upgrades, and architected for long-term composability without consensus overhaul.

XXIM Podcast spotlights Kaspa’s Covenants++ hardfork

Kristina from the XXIM Podcast released an explainer video titled Kaspa Covenants++ Revolution, breaking down what the upcoming Layer 1 upgrade could mean for the network. In the episode, she describes the hard fork as a turning point for Kaspa, arguing that previous milestones such as 10 blocks per second and sub-second finality were foundational steps toward broader programmability.

The video explains Covenants++ as a system that allows coins to carry enforceable spending conditions, using the analogy of a “sticky note” attached to funds that the network automatically enforces. Rather than introducing an Ethereum-style virtual machine, Kaspa extends its existing UTXO model to support more expressive transaction rules while maintaining proof-of-work security.

Kristina contrasts this approach with Bitcoin’s long-running OP_CTV debate, suggesting that Kaspa’s implementation offers broader flexibility for features such as time-delayed transfers, layered authorization rules, and structured state transitions. The framing presents Covenants++ as a significant expansion of what a proof-of-work Layer 1 can support.

The episode also touches on related roadmap items, including DAGKnight, zero-knowledge bridge concepts, and potential DeFi primitives expected to be developed following testnet experimentation. Mainnet activation is discussed as a 2026 target, with early vault and payment-channel examples anticipated on testnet beforehand.

Overall, the video positions Covenants++ as more than an incremental upgrade, presenting it as a step toward enabling programmable applications directly on a high-throughput proof-of-work network.

KaChat goes live with public iOS beta.

KaChat announced “Hello World! Public beta for iOS is now LIVE!” marking the debut of a private messaging application powered by Kaspa. The app is built on the Kasia Messaging protocol, which serves as the underlying communication layer, positioning KaChat as a crypto-native messaging client within the $KAS ecosystem.

According to the project, users can already send $KAS within the app, and messages are encrypted such that only the sender and receiver can read them. On the blockDAG, message payloads appear as encrypted data, requiring the recipient’s private key for decryption.

The rollout reflects continued experimentation beyond payments and DeFi primitives, extending Kaspa’s application layer into private, peer-to-peer communication. While still early stage, the combination of a live iOS beta and grassroots funding effort highlights expanding builder activity within the ecosystem. Additional feature and architectural details are expected as the public beta evolves.

K Social releases v0.1.5 with activity rankings and notification controls

K Social Network released version 0.1.5, introducing a new “Most active users” card highlighting the top five accounts by post count over the past week. The update also adds a settings option allowing users to hide success notifications for completed transactions, while error notifications remain visible.

The release carries an explicit warning: “IMPORTANT: This release is configured by default to work on Kaspa MAINNET.” It further clarifies, “This release uses real KAS coins. Please be aware that any transactions will involve actual cryptocurrency.”

Shipping with mainnet enabled by default marks a notable shift, as interactions and transactions now occur under live network conditions rather than isolated environments. Cross-platform builds are available for Linux, Windows, and Android, with published file hashes that allow users to verify the integrity of the Android installation file.

BlockSec Arena deploys on Kasplex, signaling L2 security collaboration.

Block Sec Arena announced that it has deployed on Kasplex, described as the first protocol within the Kaspa ecosystem. The deployment marks the beginning of a collaboration focused on strengthening security around emerging Layer 2 infrastructure.

Block Sec Arena positions itself as an AI-driven Web3 security platform focused on security education and bug bounty infrastructure. In December 2025, the team announced the close of a seed round at a $30M valuation, backed by infrastructure and venture partners including HotcoinLabs, Starbase, Onebit Ventures, and Apus Capital.

Block Sec Arena stated that, together with Kasplex and the broader Kaspa ecosystem, the objective is to build “a safer, more resilient infrastructure for the next wave of high-performance blockchain applications,” highlighting the growing importance of security tooling as development expands beyond base-layer functionality.

Kaspathon Update

The final day to submit to the Kaspathon hackathon is February 16, 2026. Judging will take place from February 16–22, with winners announced shortly thereafter. A total of 293 hackers participated across 39 builds.

The prize pool totals 200,000 KAS. Fifty percent is allocated to the top five projects, which will split 100,000 KAS. An additional 25% is reserved for category awards, including Payments & Commerce, Gaming & Interactive, and Real-Time Data. The remaining 25% will recognize Best UX/UI, Best Beginner Project, and Most Creative Use of Kaspa.

Some of the projects include:

Kaspa Ride-hailing: A decentralized competitor to apps like Uber and Bolt that uses Kaspa for payments, significantly reducing platform fees for passengers and increasing profits for drivers.
KaspaClash: A high-speed, on-chain PvP fighting game where every move, bet, and power-up is executed as a real-time transaction directly on the Kaspa network.
Kaspa402: An implementation of the "HTTP 402 Payment Required" protocol designed for the machine-to-machine economy, enabling instant pay-per-request API calls.
Tickasting: A decentralized ticketing platform that moves the entire purchase process on-chain to ensure a fully transparent and fair queue for high-demand events.
Kaspino Lottery: A high-velocity gaming protocol that leverages Kaspa’s rapid block times to complete entire lottery pools and distributions in under a minute.
KasSplit: A decentralized social payment tool that allows users to easily split bills and settle debts with the speed of a traditional fintech app.
FORAY Protocol: A privacy-preserving enterprise solution that uses the Kaspa ledger as a high-speed, tamper-evident audit trail for real-time corporate data.

The scale and diversity of submissions reflect growing builder engagement across payments, gaming, infrastructure, and enterprise use cases. As the judging phase begins, the breadth of experimentation underscores an expanding application layer forming around Kaspa’s high-throughput base — with early-stage prototypes offering a glimpse into what a more programmable PoW ecosystem may look like in practice.

Kaspa Theory

Latest Articles

What Real Money Was Meant to Be: Real Time Bitcoin

Kaspians, Oh Kaspians. Hail The Silverscript!

The Kaspian Dark Knight: Hard Forking and Vitalk Copying Kaspa