TL;DR

• Protocol Progress (TN12 Covenants): Kaspa Testnet 12 integrated KIP-17 covenants, expanding base-layer programmability while preserving bounded logic and PoW decentralization.

• ZK Direction (Yonatan): Yonatan Sompolinsky highlighted Cairo education as the most immediate priority for builders, citing Sierra bytecode’s provable safety and metering.

• Kaspa vs. Ethereum Framing: Industry discussion has resurfaced around the blockchain trilemma, with voices from the Kaspa community pushing back on modular scaling narratives.

• External Visibility: BSC News highlighted Kaspa’s 2025 progress to its ~1.3M followers, extending Kaspa’s reach beyond its core audience.

• Igra Mainnet Prep: Igra Labs revised its Galleon mainnet timeline, shared a 100% consensus network health update, and detailed ATAN's infrastructure to ensure historical data availability.

Kaspa Testnet 12 (TN12) Launches Covenant Testing via KIP-17

Kaspa Testnet 12 (TN12) has integrated covenants introduced by KIP-17, with the feature now being evaluated in a testnet environment.

Describing the update, the post notes:

“Kaspa Testnet 12 has successfully integrated covenants introduced in KIP-17, and while it’s not a flashy update, it’s an important one.”

Covenants allow transaction outputs (UTXOs) to include rules governing how they may be spent in the future. As explained in the post:

“Instead of funds being freely movable with a signature, the protocol itself can enforce conditions like where funds must go next, when they can move, or what kind of transaction must follow.”

The post emphasizes that this change is not intended to introduce general-purpose smart contracts, stating:“This doesn’t turn Kaspa into a full smart-contract chain, and that’s the point.”

Instead, covenants extend the UTXO model in a constrained way. According to the same commentary:

“It makes the UTXO model more expressive without adding uncontrolled complexity. Logic stays bounded, predictable, and enforced at the protocol level, while preserving PoW security and decentralization.”

The post frames covenants as foundational infrastructure rather than an end-user feature, adding: “This is the kind of progress that doesn’t create hype today, but quietly expands what’s possible tomorrow.”

As with other protocol-level changes, TN12 serves as a controlled environment to evaluate covenant behavior, safety boundaries, and design constraints before any consideration beyond testnet.

Yonatan on ZK Priorities for Builders 

Kaspa co-founder Yonatan Sompolinsky weighed in on a builder-focused discussion around zero-knowledge development priorities, responding to a prompt from Kaspa Marketing on which areas matter most to developers right now.

Yonatan pointed to Cairo education as the most immediate need, emphasizing that Cairo’s underlying architecture offers properties required for safe, scalable ZK execution at the virtual machine level. As he explained, “Cairo bc its Sierra bytecode format uniquely provides provable metering and safety (in contrast to eg SP1)”, highlighting why those guarantees matter for production-grade systems.

He further framed ZK development as more than just proving correctness, stressing the importance of execution models that are explicit, parallel-friendly, and verifiably constrained. In that context, Yonatan noted that pairing Cairo’s formal rigor with an account-based execution model, similar in spirit to Solana’s explicit read/write design, could enable a fully realized ZK-native VM and language stack.

According to Yonatan, these views reflect ongoing design discussions with Kaspa core contributors Michael Sutton and Hus Qy, reinforcing that ZK research within Kaspa is being approached as a long-term architectural effort rather than a standalone feature.

Vitalik Buterin and Kaspa Community Debate the Blockchain Trilemma

A recent post by Vitalik Buterin sparked renewed discussion around scalability and the blockchain trilemma after he argued that Ethereum’s combination of PeerDAS and ZK-EVMs represents a fundamental shift in the network’s capabilities.

For non-technical readers, the “blockchain trilemma” refers to the widely cited challenge of achieving scalability, decentralization, and security simultaneously without significantly compromising any of the three. In the post, Buterin wrote that Ethereum is moving toward a system that is decentralized, consensus-driven, and high bandwidth, stating:

“The trilemma has been solved — not on paper, but with live running code, of which one half (data availability sampling) is on mainnet today, and the other half (ZK-EVMs) is production-quality on performance today — safety is what remains.”

He described the transition as the result of a decade-long research effort, outlining a roadmap that extends through the late 2020s as ZK-EVMs become more deeply integrated into Ethereum’s validation process.

The post prompted responses across the broader crypto community, including from Kaspa community member Katrine, known as Kaspa Girl, who challenged the framing of trilemma resolution. In her reply, she wrote:

“Ethereum did not solve the trilemma — it postponed it. What Vitalik describes is conditional scalability, not native trilemma resolution.”

Katrine argued that Ethereum’s approach relies on outsourcing execution through rollups and ZK systems rather than scaling execution directly at the base layer, adding:

“Ethereum is becoming a consensus layer and data-availability layer, with execution outsourced to rollups and ZK systems. That is a modular stack, not a single decentralized system.”

She contrasted this with Kaspa’s design, emphasizing parallel block production and base-layer scaling without off-chain execution:

“Kaspa does something fundamentally different: parallel blocks instead of single-chain bottlenecks. No rollups, no provers, no off-chain execution.”

The exchange highlights an ongoing philosophical and architectural divide within the industry, as different networks pursue distinct paths toward scalability, decentralization, and security.

CityXcape Chimes in on the Kaspa v Ethereum Debate

In a recent video, James Allen of CityXcape addressed the comparison between Kaspa and Ethereum, suggesting that the framing often misses what Kaspa is actually designed to do. Rather than positioning Kaspa as a destination for migrating applications, Allen argued that it supports a different class of use cases.

Using an analogy from computing history, Allen explained:

“The mobile phone did not steal applications from the desktop. It enabled a whole new type of applications.”

He applied the same reasoning to Kaspa, citing applications such as CityXcape that generate frequent real-world events. In his view, these patterns are better suited to infrastructure optimized for continuous, low-latency activity, rather than networks designed primarily for fewer, higher-value transactions.

Nacho’s Ashton Joins Igra Labs

Nacho’s co-founder, Ashton, has joined Igra Labs, where he will focus on business development, strategy, and ecosystem building as the project approaches its mainnet launch. The move brings a long-time Kaspa community contributor into a formal role supporting Igra’s next phase.

Announcing the news, Ashton wrote:

“I’m thrilled to announce that I’ve joined @Igra_Labs to focus on Business Development, Strategy, and Ecosystem Building.

As Igra approaches its mainnet launch in the coming weeks, I’m here to help build the ecosystem, support builders and developers, and ensure transparent communication with our community and investors.”

He added that his role will emphasize regular updates, open communication, and connecting builders, developers, and partners with Igra’s growing ecosystem.

Ashton is well known within the Kaspa community for initiating and supporting several grassroots efforts, including the Nacho Kat KRC20, the Kaspa Association of Transparency (KAT), and the Kaspa Experience. His work has consistently focused on community coordination, transparency, and ecosystem participation.

At Igra Labs, Ashton will serve as a public-facing point of contact for developers, partners, investors, and community members, with an emphasis on clear communication as the network moves toward mainnet.

XXIM Podcast: Delta-Neutral Market Making and Kaspa Liquidity (Part 2)

In a new episode of the XXIM Podcast, host Ankit continues the market-making series with a focused breakdown of delta-neutral risk management strategies used by crypto market makers, with specific reference to Kaspa.

Building on a prior XXIM discussion with Junny Ho of the Kaspa Ecosystem Foundation, the episode explains why market makers aim to remain directionally neutral and how that neutrality is achieved in practice—particularly for volatile assets such as KAS.

Early in the video, the host emphasizes that market making is not price speculation:

“Market maker is not in this game to yolo or to speculate on the direction of the underlying asset, which means their job is to stay directionally neutral.”

The episode defines delta neutrality as a risk-management approach where changes in the underlying asset’s price do not materially affect the value of a market maker’s overall position. As explained in the video:

“Delta neutral simply means you don't care if the price of an asset goes up or down. It simply means the value of the position does not change when the underlying goes up or down.”

The most commonly discussed method is hedging exposure with perpetual futures. Using a simplified example, the video explains that a market maker holding a positive delta from accumulated spot or filled buy orders can short an equivalent amount using perpetual contracts to offset directional risk:

“So a positive delta of 1 million and a negative delta of 1 million evens out to be zero or delta neutral. That’s delta neutral in action. No directional gambling, just smart risk management.”

The episode then turns to options-based strategies, highlighting that not all market makers hold extensive inventories of the underlying asset. In some cases, market makers can provide significant liquidity while having little or no KAS by using cash-settled crypto options, such as those offered by CoinCall.

Discussing this approach, the host explains: “A market maker could be making markets in tens of millions of dollars yet hold no Kaspa.”

Two options-based hedging paths are outlined: buying call options to gain positive delta exposure, or selling put options to achieve similar delta while collecting premiums upfront. According to the video, both approaches can be used individually or in combination to manage costs and risk while maintaining neutrality.

The episode concludes by reinforcing the core distinction between trading and market making:

“A delta neutral trader or market maker does not want to profit from predicting where the price will go up or down. Instead, they want to earn money from bid spread, providing liquidity.”

BSCN Highlights Kaspa to 1.3M Followers

The BSCN X account, BSC News, which has approximately 1.3 million followers, shared a post focused on Kaspa, highlighting the network’s 2025 developments and 2026 outlook.

In the post, BSCN wrote: “It can't be denied – 2025 has been an incredible year for Kaspa. Can next year be even bigger?”

The post links to a year-in-review article examining Kaspa’s technical and on-chain progress throughout 2025. In its conclusion, the article emphasizes execution and sustained network performance, stating:

“Kaspa’s 2025 updates focused on execution rather than promises. The Crescendo hardfork increased block speed, improved throughput, and enabled real-world applications on the base layer. Transaction counts increased, fees stayed low, and node participation grew. Kaspa remains a proof-of-work network that prioritizes decentralization while operating at speeds usually associated with different architectures. The data from 2025 shows that its blockDAG design can support sustained activity without relying on layer-2 systems for basic scaling.”

The coverage represents a notable instance of Kaspa-related analysis reaching a broad, mainstream crypto-media audience beyond the project’s core community.

XXIM Podcast: Ankit Interviews Igra Labs’ Mike Zak on ATAN Nodes

In a new episode of the XXIM Podcast, host Ankit interviews Mike Zak of Igra Labs for a technical discussion on ATAN (Accepted Transactions Archival Node). ATAN is an infrastructure designed to improve the availability of historical data on a pruned Kaspa network.

The conversation centers on a core trade-off in Kaspa design. Aggressive pruning helps keep consumer-grade full nodes viable as throughput increases, but it also means the network does not retain long spans of historical data by default. Mike explains that Kaspa nodes “prune very aggressively,” adding: “We keep between 30 and 42 hours of history … on the node.”

That approach supports decentralization goals but creates a challenge for systems that require a provable history, particularly Layer 2s that must sync new nodes from genesis or verify older state transitions without trusting a third party. As Mike put it, “since everything is pruned in Kaspa,” a decentralized Layer 2 that needs historical proofs cannot rely on pruned nodes alone, without an ATAN or an archival node.”

The episode distinguishes ATAN from simply running a full archival node. Mike frames whole archival storage as impractical at scale, summarizing the underlying constraint as “petabytes of data.”

ATAN’s core idea is to archive accepted transactions in a way that remains verifiable without requiring every participant to store the full historical blockDAG. Early in the episode, Mike defines it as:

“Instead of archiving the whole thing, it will archive only the accepted transactions according to the selected parent chain.”

To ground this, the discussion reviews Kaspa’s blockDAG ordering concepts, including selected parent chains, accepted transactions, and how the anticone relates to acceptance. The conversation then turns to KIP-15 and sequencing commitments. Mike explains that while Kaspa does not require a commitment to an accepted order at the base layer, higher-layer systems do. He notes:

“This commitment is required for ATANs to function because otherwise ATAN wouldn’t be able to prove the validity of their data.”

Mike also outlines a three-mode architecture for ATAN, ranging from lightweight, commitment-only nodes sufficient for historical inclusion proofs to heavier modes that store transaction IDs or complete transaction data. He describes the latter as increasingly storage-intensive over multi-year horizons.

Regarding operations, Mike says ATAN nodes would primarily be operated by parties that require historical access, such as Layer 2 attesters, block explorers, and organizations with legal or audit requirements. He notes that typical payment users do not need to run one:

“The lay person who just uses Kaspa for payments … doesn’t need to run an ATAN on his home computer.”

Later, he discusses Igra’s intent to open-source ATAN and the possibility of integrating it into the Rusty-Kaspa repository, pending agreement from core developers. He emphasizes verification over trust:

“We don’t want you to trust our verification process. We want you to go over the code and make sure that it’s correct.”

The conversation also touches on the broader relationship between Layer 1 and Layer 2 and on security budgets. Mike argues that sustainable Layer 2s must remain economically aligned with the base layer. He explains that Igra’s design ensures Kaspa miners continue receiving fees from Layer 2 activity:

“Every Igra transaction is also a Kaspa transaction. Kaspa miners are getting a fee for including those transactions.”

The interview frames ATAN as long-term infrastructure designed to reconcile Kaspa’s pruning strategy with the data availability needs of higher-layer systems, without forcing the ecosystem to meet petabyte-scale archival requirements that only a small number of operators could sustain.

A New Visualizer

A visualizer shared by FullFace.kas highlights the difference in block production between Kaspa and Bitcoin over the same time window, illustrating how Kaspa’s blockDAG architecture operates at a fundamentally different cadence than traditional single-chain networks.

Igra Labs Revises Mainnet Launch Timeline

Igra Labs confirmed a revised mainnet schedule following an official update published on December 22. The team announced that its upcoming Galleon release has been moved to mid-January, citing extended V2 hardening after additional edge cases surfaced under real network load.

Explaining the decision, the team wrote, “Better to delay than arrive with holes in the hull,” underscoring a quality-first approach as testing continues.

Alongside the timeline update, Igra Labs outlined several near-term milestones, including publishing its Attesting Protocol specification, conducting an internal review of the ATAN storage layer with Kaspa core developers, open-sourcing transaction and entry specifications, and the upcoming open-source release of Kaswallet.

As a follow-up, Igra Labs shared a network health update on January 2 showing 100% consensus across all eligible nodes, with no lagging or error states reported, indicating stable operation as testing continues.