TL;DR:

• DagKnight v0 devnet testing underway: Parent-selection wiring is in a working state and under review, with blue work maintained via parallel GHOSTDAG execution; next focus includes tie-breaking and incremental UMC.

• Covenants and zk proving updates: Sutton highlights a lightweight, atomic covenant design; GPU workstations under experimentation, citing principles of compute locality and storage minimization.

• RTD clarified beyond scalability: In response to an X discussion, Dr. Yonatan Sompolinsky defines Real-Time Decentralization as real-time majority sampling, linking it to censorship resistance, oracle finality, and future higher block rates enabled by DagKnight.

• Covenants discussed in practical terms: Kastle’s Leo walks through real-world family, business, and inheritance use cases on XXIM and demos how spending limits, recipient controls, and time locks could work at the wallet level.

• U.S. public miners expand despite margin pressure: KEF review finds 7.4 GW of North American capacity, growing AI/HPC diversification, divergent HODL strategies, and continued evaluation of Kaspa mining by MARA as part of multi-chain optimization.

• Public company tests “Asymmetric-DAT” strategy: Boxabl licensed its trademark for a Solana meme token, capturing royalty upside while avoiding direct balance sheet exposure, issuance, and custody risk.

gDagKnight v0 Devnet Advances to Active Testing

This week, coderofstuff (x.com/@coderofstuff_ ) shared a technical update on Kaspa’s Dagknight (DK) development. Dagknight is Kaspa’s planned consensus upgrade designed to replace certain fixed structural constraints in parent selection with a more adaptive model.

The implementation of Dagknight is a two-fold process involving both the core protocol architecture and its system-wide connectivity. The development team has structured this rollout into “v0 devnet, v1 testnet and v2 mainnet candidate,” with recent testing focused heavily on finalizing those critical network connections.

He continued to share additional details on how Dagknight (DK) integrates with existing consensus mechanics, explaining that its shift from fixed parent-selection constraints to a more dynamic model affects several sensitive subsystems beyond block referencing. Parent-selection constraints are predefined limits on how blocks reference one another.

It is still unclear how the updates would affect the difficulty adjustment algorithm (DAA), coinbase, initial block download (IBD), and pruning. The DAA continuously recalculates mining difficulty to maintain the network’s target block rate; the coinbase defines block rewards and fee distribution to miners; IBD governs how new nodes synchronize and reconstruct the network’s canonical history; and pruning determines which historical block data can be safely discarded without compromising security.

Dagknight changes how blocks select their parent references, but it does not attempt to maximize “blue work,” the metric Kaspa uses to measure the network’s accumulated security weight, analogous to Bitcoin’s longest-chain rule. To preserve this property and maintain consistent topology, developers are running an independent implementation of GHOSTDAG specifically to calculate blue work.

Looking ahead, the development focus shifts toward protocol-specific components, with a particular emphasis on refining tie-breaking mechanisms and incremental UMC. Tie-breaking mechanisms are the protocol’s internal rules for resolving conflicts between equally valid blocks. Incremental UMC (Unordered Merged Consensus) refers to refining how blocks are gradually merged and ordered within the DAG as the network grows.

The wiring around DK is currently operational but remains under review. Testing is ongoing within a small internal devnet before progression to broader testnet stages.

On Covenants and GPU Testing

Kaspa core developer Michael Sutton shared insights into covenant architecture and ongoing R&D experiments using GPU workstations for zero-knowledge proofs.

A covenant is a programmable spending condition that restricts how a UTXO can be used in future transactions according to predefined rules. Regarding covenants, Sutton stated that they “can serve as first-class state machines” with the following two properties:

1. Lightweight by design: Only compact commitments to rules or state are stored on-chain, while transactions supply the necessary proofs when changes occur. This shifts costs toward one-time execution rather than permanent contract storage.

2. Atomic participation: Multiple parties can establish and enter the covenant within a single transaction, allowing coordinated agreement without requiring separate sequential steps.

Both properties may prove particularly relevant in an agent-driven environment. On Kaspa, autonomous agents can define custom rules and mutual agreements directly via covenants at the transaction level, without deploying separate smart contracts. In this sense, covenants provide a lightweight and efficient coordination mechanism for agent-to-agent interactions.

Separately, Kaspa R&D is utilizing GPU hardware for zero-knowledge proving experiments. Sutton clarified that the effort does not involve reinventing zk GPU proving itself, but noted that proof-of-work communities may have a structural advantage in this area given existing familiarity with GPU infrastructure. Sutton posted:

“Insisting on correct principles such as compute locality and storage minimization pays off also in completely new and unexpected realms.”

The remark connects Kaspa’s longstanding architectural emphasis on compute locality and storage minimization to emerging infrastructure domains such as zk proving.

Kaspa is Real-Time Bitcoin

In response to a post describing various crypto networks as different evolutionary branches of Bitcoin, Dr. Yonatan Sompolinsky expanded on his Real-Time Decentralization (RTD) thesis, further clarifying what he considers Kaspa’s core value proposition. The discussion builds on his Medium essay from last week, but was framed as a direct reply to the idea that Kaspa is merely “scalable Bitcoin.”

At the center of that clarification was a concise definition of RTD: “the ability to sample the honest majority in real-time.”

Sompolinsky argues that Bitcoin achieves strong security guarantees through Nakamoto consensus, but only after an extended aggregation of blocks. In contrast, RTD seeks to decentralize each consensus round itself, allowing majority sampling within seconds rather than across an hour of accumulated chain work.

He contrasted proof-of-work with certain proof-of-stake designs, writing “pos=select then write, pow=write then select.”

The distinction, he suggests, affects the ability to honestly sample majority participation in real time.

He further connected RTD to several system-level properties, including transaction confirmation speed, censorship resistance, oracle finality, and MEV resistance. For example, he noted that if a majority of miners were censoring transactions, Bitcoin users could experience extended confirmation delays, which may be tolerable for some use cases but problematic in high-stress financial environments.

On block rate, Sompolinsky introduced a probabilistic argument: at lower block-per-second (bps) levels, a minority attacker can more easily distort majority signaling. He wrote that “Under 10bps, a 37% attacker can fake the majority signal with probability 12%. With 100bps, this drops to 0.3%.”

He added that while current Kaspa implementations cannot safely exceed roughly 10 blocks per second without harming confirmation times, the planned DagKnight upgrade aims to enable higher rates, initially targeting 25–40 bps on testnet.

Sompolinsky also suggested that real-time decentralization could make the network more resilient if parts of the internet temporarily split or lose connectivity, helping the system maintain honest majority agreement even during disruptions.

The discussion frames Kaspa’s scalability not as an end in itself, but as a mechanism to increase proof-of-work density and strengthen real-time majority sampling.

KEF Reviews U.S. Public Bitcoin Mining Landscape

As part of its move to publish long-form research directly on X, the Kaspa Ecosystem Foundation released a detailed review of nine publicly listed U.S. Bitcoin mining companies with market capitalizations above $1.5 billion as of year-end 2024.

Authored by Steven, Effy, and Junny, the report analyzes 2024 annual filings to examine operational scale, energy costs, capital strategy, and diversification trends across the sector.

The research notes that U.S.-based firms continue to dominate global mining capacity, accounting for roughly 75 percent of worldwide hashrate. Publicly listed North American miners now operate approximately 7.4 gigawatts of capacity, representing a 36.5 percent year-over-year increase despite post-halving margin pressure.

The report frames this expansion as countercyclical infrastructure investment, suggesting that leading firms are increasing capacity during periods of compressed hash prices to strengthen long-term competitive positioning.

Several strategic themes are highlighted.

• Electricity cost discipline. Direct energy costs account for over 80 percent of total mining costs. The companies studied report an average electricity cost of approximately $38 per MWh, below the broader industry median.

• Capital structure and BTC treasury strategy. Firms are split between “HODL” models, which retain mined Bitcoin and raise capital to accumulate more, and “Non-HODL” strategies that liquidate daily production to fund operations and expansion. These divergent approaches materially affect balance sheet risk and valuation sensitivity to Bitcoin price.

• Diversification into AI and HPC. Multiple miners are reallocating infrastructure toward high-performance computing and AI data center hosting. Partnerships and GPU deployment strategies are increasingly positioned as parallel revenue streams rather than side experiments.

• Energy arbitrage and grid services. Companies such as RIOT and HUT8 are monetizing flexible load participation, curtailment programs, and ancillary grid services to reduce effective power costs and generate incremental revenue.

The report also notes that, among the firms surveyed, Marathon Digital continues to evaluate Kaspa mining as part of a broader multi-chain revenue optimization strategy. According to the analysis, Kaspa mining has lower unit costs than Bitcoin mining, offering operational flexibility and supplemental cash flow alongside BTC-focused operations.

While the study centers on Bitcoin miners, the inclusion of Kaspa highlights how major public mining firms are increasingly assessing alternative proof-of-work networks as part of treasury, infrastructure, and profitability strategy. In that sense, the research offers insight not only into the state of U.S. mining but also into how networks like Kaspa are being positioned within institutional-scale hash-allocation decisions.

KEF Examines Boxabl’s “Asymmetric-DAT” Meme Strategy

In a recent article, KEF authors Effy and Rosy analyze what they describe as a shift from the 2025 Digital Asset Treasury (DAT) narrative toward a new hybrid structure introduced by modular housing company Boxabl.

A Digital Asset Treasury strategy refers to public companies adding cryptocurrencies to their balance sheets, giving shareholders indirect exposure to digital assets without issuing tokens themselves.

According to KEF, Boxabl adopted a different approach in early 2026. Rather than holding crypto assets directly, CEO Galiano Tiramani launched a Solana-based meme token, BOXABL, under a trademark license agreement with the company.

The token initially surged 1,000% from approximately $0.0002 to over$0.002 before retracing to around $0.0003, representing an 88% decline from its peak.

Crucially, Boxabl Inc. neither issued nor held the token. Per the company’s Form 8-K filing, the firm entered into a Trademark License Agreement allowing the CEO to use the BOXABL trademark for the token’s creation. In exchange, the company receives a quarterly royalty based on net cash flows generated by the token after expenses.

KEF characterizes the arrangement as structurally asymmetric. By licensing its brand rather than issuing a token, Boxabl avoids direct balance sheet exposure, custody risk, and securities classification concerns while still capturing potential upside through royalties and viral brand amplification ahead of its planned public listing.

The report highlights two primary legal considerations. First, classification risk. KEF notes that, generally, meme coins are viewed by the SEC as consumer goods rather than securities. However, under U.S. consumer protection law, liability may arise if public disclosures create a misleading overall impression, even in the absence of intent to defraud. The key question is whether a reasonable consumer could believe the company itself issued or endorsed the token.

Second, secondary market trading risk. If company executives trade the meme coin while in possession of material nonpublic information, such conduct could potentially constitute unfair or deceptive practices under consumer protection standards, regardless of securities classification.

The authors frame the structure as more than a speculative token experiment, arguing it represents a new form of narrative engineering in a pre-IPO environment. The article states:

“Galiano’s innovative meme PR strategy, combined with the SEC’s regulatory omission in this area, to some extent reveals an emerging new intersection between crypto assets and traditional enterprises.”

The report concludes that the durability of this model will depend less on token price performance and more on regulatory interpretation, disclosure discipline, and how courts interpret implied corporate responsibility in branded token launches. For the Kaspa ecosystem, the analysis serves as a broader signal of how public companies are experimenting with crypto-exposure structures, highlighting alternative models beyond traditional treasury accumulation and underscoring the importance of a clear separation between protocol-level design and corporate narrative strategy.

Igra Labs Launches Mainnet

Igra Labs confirmed that its mainnet went live on February 25, following the earlier launch of the Galleon Test Mainnet on February 5, which ran Igra’s production code anchored to Kaspa L1. The test phase was followed by weeks of community testing prior to the Genesis and token generation event (TGE), the point at which the network’s native token is formally minted and distributed according to predefined allocations.

The team stated that the mainnet genesis block was mined at a DAA score of 366020000 and that the core contracts were deployed. According to Igra Labs, the IGRA token was minted and distributed into designated pools. Minting vaults and DAO contracts are live, with a governance UI expected to follow. Early-round allocations are currently underway.

Following the Genesis event, Igra Labs also published its Bootstrap specification and network parameters, outlining a one-time initialization mechanism intended to minimize trust assumptions.

The documentation describes a trust-minimized setup in which contract addresses are bound to bytecode via CREATE2, the configuration executes atomically with full reversion on failure, and ownership transitions to governance after a brief pre-governance setup phase.

A number of ecosystem teams are building on Igra’s execution layer, including Quex, Zelcore, Kaskad, DagScan, Kaspa.com, Zealous Swap, Fervent Finance, Kyo, Nacho the Kat, Knexous, Kasperia, Tokify, Crest Development, Kastle, Aporia, Kaspa Finance, Igraway, Spectre Market, KaspaPulse, Kasware, Kasway, SeaSwap, Slow, TBDai, Kasname, and Lightbeam.

Kastle Wallet’s Leo Outlines Covenant Use Cases

On the XXIM podcast, Leo, Head of Product at Kastle Wallet, discussed how Kaspa covenants could translate into practical wallet features, focusing less on opcode mechanics and more on user-facing constraints such as who can spend, who can receive, spending caps, and time conditions. He described covenants as:

“Some programmable constraints that people can apply on a daily basis to their transactions, a set of rules that can define how the transactions are delivered to the receivers.”

To make the concept more intuitive, Leo built a small internal demo application that visualizes covenant constraints in a drag-and-drop, block-style format. He compared the design to assembling code blocks or Legos, explaining that combining address controls, amount limits, and time locks should feel intuitive rather than technical. At the same time, he stressed that wallet UX will be critical, since users must clearly understand that covenant rules are irreversible once created.

Leo grouped early use cases into everyday categories. For families, he described shared household pools where specific spenders and recipients can be constrained, potentially with daily limits or time-based activation. For businesses, he pointed to structured payouts such as employee bonuses or supplier payments. In discussing recurring flows like payroll, he noted that covenants themselves do not include native scheduling logic, stating:

“There’s not a building scheduler inside Covenants… you need to have another thing, such as an agent trigger.”

For inheritance and recovery scenarios, he outlined approaches using time locks or inactivity-based triggers, with wallet-side monitoring layered on top of base-layer constraints.

Leo repeatedly referenced “cron jobs” as shorthand for this automation layer, while clarifying:

“The word cron job is quite a simplification of what, at Kastle, we aim to build with covenants.”

In this framing, covenants function as a bounded permission layer. Rather than granting broad wallet access, users could restrict activity with per-transaction caps, daily limits, fixed recipients, or time conditions, allowing software to operate within clearly defined parameters.

Leo also noted that Kastle has integrated Igra in both testnet and mainnet views, and described covenant support as involving both opcode-level implementation work and significant UX design effort to ensure covenant creation remains understandable and safe for everyday users.

Kaspa Ecosystem Application Updates

Kurncy Adds Optional Privacy Mode for Address Rotation

Kurncy announced an upcoming wallet feature designed to improve address privacy when sending KAS, claiming that “Privacy mode is incoming”

According to the team, the feature will automatically generate a new Kaspa address for remaining funds after a transaction, reducing address reuse and limiting straightforward balance linkage. Kurncy credited @KaspaSilver for the suggestion. No release timeline was provided.

KaChat iOS App Approved for App Store Distribution

The KaChat iOS application has received approval from Apple and is now listed on the App Store. According to the team, the rollout will propagate across all supported countries within approximately 24 hours, after which users should be able to locate it directly via App Store search.

The developers noted that the current TestFlight version contains additional bug fixes not yet reflected in the public release. However, no major functional differences were indicated.

KasMap Expands to 86 Countries

KasMap, a community-driven directory connecting Kaspa users by location, has expanded to 86 countries with the addition of Jamaica, Lebanon, Panama, Paraguay, Saudi Arabia, and Suriname.

The platform allows users to find local Kaspa communities, join regional groups, or start one in their country. According to the update, KasMap is now active in over 80 countries, reflecting continued global participation.

Kaskad dApp Goes Live 

Kaskad announced the first live deployment of its decentralized application, now available on the Igra Labs Galleon Testnet.:

“The long awaited Kaskad dApp is now LIVE on @Igra_labs Galleon Testnet!”

Kaskad is a lending and borrowing protocol within the Kaspa ecosystem. The testnet release allows users to claim iKAS via an integrated faucet, mint testnet assets (including USDC, IKAS, IGRA, WETH, and WBTC), supply and borrow tokens, and monitor collateral health factors within a simulated lending environment.

The team encouraged community participation during this phase, positioning the launch as an opportunity to test functionality and user flows on Galleon ahead of any future mainnet considerations.

KasShi Launches on Kaspa, Adds 4K Video Support

KasShi, a video streaming platform built on Kaspa, launched on February 2 with native $KAS microtransactions powering uploads, viewing, and tipping.

The platform allows creators to set their own viewing price when uploading content. According to the team: “You can now choose your own view price when uploading a video. And yes, you can even make it free to watch, it's up to you!”

This means videos can be either pay-per-view or free, depending on the creator’s preference. KasShi also recently introduced 4K video support, with the first 4K content now live on the platform.

Positioned as a micro-payment alternative to subscription-based streaming services, KasShi utilizes Kaspa’s low-fee infrastructure to enable direct value transfer between viewers and creators.

Stroem Reports Atomic Swap on Testnets

Stroem Finance reported completing an ETH ↔ KAS round-trip atomic swap in under three minutes on test networks (Kaspa Testnet 10 and Sepolia), emphasizing that the transaction used HTLCs without bridges or wrapped assets.

The team outlined next steps including an updated paper introducing “CCR (Competitive Claim Rescue),” UI improvements for more detailed swap tracking, full open-sourcing of the stack, and expanding node participation.

Stroem previously released its litepaper at stroem.finance, on January 18, with a final whitepaper expected to follow.

As always with DeFi and cross-chain protocols, users should do their own research and treat early deployments as experimental until independently validated.