TL;DR:

Kaspa.org redesign introduces an expanded roadmap framing: The new site centers Kaspa on “real-time decentralization” while outlining future work on Toccata, DAGKnight, 100 BPS scaling, and partition-resilient payments.
Yonatan Sompolinsky discusses Kaspa’s long-term direction: A Kaspa Daily Q&A covered “Base of Liquidity,” “coordination markets,” “netsplit resistance,” and the proposed “universal scheduler.”
Toccata integration and KIP-21 validation work continue: Core developers discussed merge-alignment PRs, TN12 updates, and lightweight validation models for sequencing commitments.
Zealous Labs publishes “Zealous Flow” whitepaper: The proposed Continuous Clearing Market (CCM) model introduces uniform per-block pricing and MEV-resistant settlement mechanics.
Oracle research debate examines liquidity and manipulation resistance: Yonatan Sompolinsky and Eliott Mea discussed competing approaches to decentralized price oracle design and liquidity-constrained robustness.

Kaspa.org Launches Redesigned Website Centered on Real-Time Decentralization

The official Kaspa.org website launched a major redesign this week, built around “Kaspa’s north star”: “Real-time decentralization,” reframing the network’s public-facing presentation to focus on Kaspa’s proof-of-work BlockDAG architecture, research lineage, and long-term roadmap.

As described on the lore page:

“Real-time is a non-compromise. Impatience is Kaspa's primitive instinct - a tantrum against wait times, rejecting limits that the adults just accept. And we demand this not only for speed but also for the hardcore Satoshi properties: censorship resistance, permissionless settlement, and competitive mining - all achieved in real time, not eventually. This is not achievable in real time without proof of work.”

The updated homepage prominently features Kaspa’s fair-launch genesis proof, emphasizing that “Every coin in Kaspa’s history traces cryptographically back to an empty genesis. No premine. No hidden allocation. Fair launch.” Visitors can also directly verify and run the genesis proof themselves through linked tooling and GitHub resources.

The redesigned structure consolidates the ecosystem into four primary navigation paths:

LORE for protocol history, research lineage, and roadmap
HODL for wallets, exchanges, and onboarding
BUIDL for developer resources and contributor tooling
DAGVIZ for live BlockDAG visualization

The new structure is intended to simplify onboarding for users of all types, from developers and researchers to newcomers exploring the network for the first time.

A major focus of the redesign is the expanded LORE section, which traces Kaspa’s research lineage from the GHOST protocol through SPECTRE, PHANTOM, and GHOSTDAG into the consensus protocols running Kaspa today. The section also positions “real-time decentralization” (RTD) as Kaspa’s core design objective, describing it as the ability to sample the honest majority of miners in near real time while maintaining proof-of-work security guarantees.

The LORE page also outlines Kaspa’s planned roadmap, including the Toccata hard fork introducing covenant-based programmability and the Silverscript compiler, the DAGKnight consensus upgrade targeting 25–40 millisecond block times, and a proposed 2027 hard fork targeting 100 blocks per second alongside partition-resilient payment flows.

The redesign also highlights Kaspa’s transition from the original Golang implementation to the Rust-based “rusty-kaspa” architecture that enabled the Crescendo upgrade and the network’s current 10 blocks per second operation on mainnet.

Reacting to the launch, Michael Sutton wrote: “Amazing work. Words that make me proud to be a diehard Kaspian.”

Another important detail to point out is that the redesigned website is now operated by your very own KASmedia.

Kaspa.org Roadmap Introduces Future Scaling and Partition-Resilient Payments

The redesigned Kaspa.org roadmap also introduced an early look at a proposed future scaling research currently targeted for a 2027 hard fork. As described on the lore page:

“10 millisecond block time - 100 blocks per second - would likely require DAG algorithmic adjustments to how miners reference DAG tips, alongside further node performance optimizations.”

The roadmap additionally outlines research focused on improving network behavior during internet partitions.

“DAGKnight already provides safety under netsplits: transactions confirmed before a split remain final. But it does not provide progress during a split - transactions cannot actually be confirmed until the split is over.”

According to the site, the proposed work would combine on-chain payment channels with hashrate-adaptive finality windows to help local payment flows “survive broken internet conditions,” even before full global connectivity is restored.

Dr. Sompolinsky Q&A on Kaspa Daily

Kaspa founder and primary architect Yonatan Sompolinsky took part in an extended community interview on the Kaspa Daily X account, @DailyKaspa, discussing Kaspa’s adoption strategy, Layer 1 programmability roadmap, ecosystem growth, and long-term network direction.

He described Kaspa as targeting a broader category he calls “Base of Liquidity” (BoL), where an asset can function with minimal friction across both store-of-value and medium-of-exchange use cases. He described it as “an asset that resembles the money functionality people are used to today: minimal to no friction when using it as both SoV and MoE.”

He also pointed to “real-time decentralization” and the proposed “universal scheduler” as areas where he believes Kaspa remains ahead of broader industry narratives, while arguing that ecosystem growth now depends more on business development, product execution, and adoption efforts than on new protocol functionality.

When asked if he thinks Kaspa should try to poach crypto apps from other chains, he responded that he is happy for other builders to come to Kaspa. He mentioned that this would necessitate a large business development pitch and that the days of “build it, and they will come” are over. Sompolinsky also referenced ongoing work around what he described as “coordination markets,” a proposed category of applications focused on enabling large-scale economic coordination mechanisms on Kaspa. No detailed specification or product framework was

provided.

He also shared two areas where Kaspa is “ahead of the narrative.” He pointed to the “universal scheduler,” stating that he aims “to complete the research phase with @OriNewman very soon.” He also introduced “netsplit resistance” as a long-term resilience objective focused on maintaining usable network behavior during major internet outages or connectivity disruptions. He stated that he plans to start working on it in Q1 2027.

The discussion also focused heavily on programmability and execution architecture ahead of the Toccata hard fork. Sompolinsky reiterated his support for zk-native infrastructure over long-term dependence on EVM ecosystems, arguing that Layer 2 dominance fragments network effects and weakens emerging Layer 1 ecosystems.

Sompolinsky stated: “EVM is an outdated tech antithetical to Kaspa’s boutique brand. Vitalik declaring a move away from it should be enough to end this imagined debate.”

The Q&A additionally covered marketing structure, institutional adoption, ZK architecture, network resilience research, and the role of community sentiment in shaping Kaspa’s development direction. Part 2 is expected separately.

Kaspa Core Developers Discuss Toccata Merge Alignment and KIP-21 Validation Design

Discussion in the Kaspa Core R&D Telegram group this week focused on continued Toccata integration work, TN12 operational updates, and validation mechanics surrounding KIP-21 sequencing commitments.

Michael Sutton confirmed that the first in a planned series of pull requests to align the Toccata branch with the current master branch had been merged.

“This is the first out of 2-3 PRs for getting the toccata codebase to the point where it can be merged into master.”

Sutton noted that the update introduces fork-aware APIs for tooling such as ScriptBuilder, allowing applications to distinguish between pre- and post-Toccata script behavior while defaulting to pre-activation safety settings for current mainnet compatibility.

The discussion also included operational updates around the TN12 testnet rollout, including advisory fixes, filtering mechanisms for outdated nodes, and explanations for temporary orphan/unorphan logging behavior during synchronization periods.

Separately, developers debated verification approaches for KIP-21 sequencing commitments and Sparse Merkle Tree (SMT) lane proofs, particularly around how lightweight or external clients could validate lane updates without reconstructing the entire SMT state. Sutton posted:

“A client does not need to maintain the incremental SMT, and it also does not need all SMT leaves.”

Sutton described a localized witness model where validators can verify lane updates using selected-parent roots and lane transition proofs, rather than continuously processing all historical lane states.

Kaspa Developers Discuss Long-Term REST API and Archival Infrastructure

A broad discussion emerged in the Kaspa R&D Telegram group this week around REST API scalability, historical indexing, and enterprise-grade data infrastructure for the network.

APIs (Application Programming Interfaces) enable applications such as wallets, exchanges, explorers, and custody platforms to communicate with blockchain services and retrieve data, including balances, transaction history, and UTXOs. “REST” is simply the common web-based format many applications use to communicate with services over the internet.

The conversation centered on challenges related to historical transaction indexing, storage costs, pagination support, and infrastructure requirements for institutional integrations and high-volume applications relying on transparent historical ledger access.

Several contributors discussed potential architectural approaches that include RocksDB indexing, hot/warm/cold storage tiers, cursor-based pagination, and lightweight indexing services, such as the newly introduced “go-kaspabook” project.

Yonatan Sompolinsky stated, “What kind of solution can we build so that institutions with zero know-how can use Kaspa? requiring them to run a node themselves would kill adoption.”

The discussion reflects growing attention toward the infrastructure layer surrounding Kaspa, particularly as enterprise and custodial integration requirements expand.

Zealous Labs Publishes “Zealous Flow” Whitepaper Introducing Continuous Clearing Market Model

Zealous Labs published the whitepaper for “Zealous Flow” this week, outlining a proposed new on-chain trading mechanism called the Continuous Clearing Market (CCM) for Zealous Swap V2.

The paper describes CCM as an alternative market structure to both automated market makers (AMMs) and traditional central limit order books (CLOBs), in which all eligible orders continuously settle against a single, uniform clearing price per block rather than through individual trade matching or liquidity pool curves. According to the whitepaper, “Pricing by agreement, not by a curve and not by a touch.”

According to the whitepaper, the system is designed around “resting capital” rather than trade execution priority, with the stated goals of reducing MEV-related ordering advantages, minimizing slippage, and reducing reliance on traditional liquidity provider and market-maker structures.

The whitepaper also introduces concepts including “counter-liquidity rebates,” uniform per-block pricing, lazy O(1) order fills, and bounded-gas settlement mechanics intended for on-chain spot trading environments. The document is currently published as a public specification draft.

Sompolinsky and Eliott Mea Debate Oracle Robustness Models

A discussion this week between Yonatan Sompolinsky and oracle researcher Eliott Mae (@eliottmae) explored differing assumptions about the design of decentralized price oracles, particularly whether robust pricing systems are primarily a market structure problem or a protocol design problem.

The conversation began after community commentary distinguished between two emerging oracle categories within Kaspa-related research discussions:

binary outcome oracles focused on resolving whether events occurred
price oracles attempting to model live market conditions under adversarial conditions.

Responding to the discussion, Sompolinsky argued that robust price oracles may largely reduce to robust liquidity and market-making design, stating:

“Robust price oracles reduce to robust market making / order book designs.”

He further suggested that oracle robustness is ultimately constrained by available on-chain liquidity, arguing that “medium volume + decent design” may outperform novel architectures operating with thin liquidity.

Eliott Mea responded that some oracle models may avoid relying entirely on crowd consensus by sourcing pricing through RFQ-based systems connected to centralized exchanges, with the primary challenge shifting to detecting whether market manipulation is actionable rather than proving it conclusively.

Sompolinsky expressed skepticism that quote manipulation could be formally distinguished from ordinary market noise and latency effects strongly enough to justify slashing-based enforcement models. He posted:

“I’m highly skeptical that one can prove manipulation … due to manipulations being indistinguishable from white noise + network latency.”

Mea later stated that his proposed model avoids many slashing assumptions entirely and claimed to have developed a formal framework intended to account for latency and noise constraints, though no specification has yet been published publicly.

GateDEX Adds Kasplex Support Inside Gate App

Gate and Kasplex announced Kasplex support on GateDEX this week, expanding Kasplex integration within the exchange’s in-app decentralized trading interface.

The integration follows Gate’s recent rollout of Kasplex-based KAS deposits and withdrawals, and now allows users to move from centralized exchange trading into the Kasplex ecosystem within the same application.

According to Kasplex, users can purchase KAS on Gate, access GateDEX within the app, withdraw onto the Kasplex network, and begin interacting with Kasplex applications without switching between separate wallets or applications.

The update reflects continued alignment of infrastructure between centralized exchanges and emerging Layer 2 activity within the broader Kaspa ecosystem.

RKStratum Introduces Decentralized Solo Mining Interface

FundingKaspa introduced RKStratum this week, a decentralized solo mining platform built around the RustyKaspa ecosystem that allows miners to connect to public mining bridges while mining directly to their own wallets.

According to the project page, the platform includes live worker and hashrate monitoring, regional bridge connectivity, and integrations with Kastle Wallet, KasWare Wallet, and Kaspium. FundingKaspa also stated that the system supports wallet generation across Schnorr, ECDSA, and EVM-compatible key formats intended for both Kaspa Layer 1 and emerging Layer 2 environments.

The release reflects continued experimentation around decentralized mining infrastructure and alternative coordination models within the broader Kaspa ecosystem.

ZK Proof SDK Examples Updated in Rusty-Kaspa Repository

Developer Alexander S. shared in the Kaspa Core R&D public telegram group that all JavaScript end-to-end examples for the evolving Rusty-Kaspa ZK tooling have been updated and tested, including examples covering Groth16 proofs and succinct proof receipts.

The examples demonstrate zk-proof construction workflows using new SDK builder utilities within the Rusty-Kaspa repository. During discussion in the Kaspa R&D Telegram group, Michael Sutton requested example files demonstrating the tooling and responded positively to the implementations.

The updates reflect continued developer tooling work around Kaspa’s upcoming ZK verification and programmable covenant infrastructure ahead of the Toccata hard fork.

Community Op-Ed Reflects on Kaspa’s Fair Launch and Early Mining Era

A long-form thread published by community member “moose.kas” revisited Kaspa’s early launch period, arguing that the network’s survival through multiple mining, issuance, and infrastructure transitions gives additional weight to its fair-launch proof-of-work model.

The thread traces Kaspa’s progression from its earliest “gamenet” phase, when miners traded coins informally through Discord before exchanges or wallets existed, through major moments including the early DAG memory bug incident, the transition from early high-inflation issuance into Kaspa’s long-term chromatic geometric emission model, Ethereum’s move to proof-of-stake, and the arrival of industrial ASIC competition.

“Kaspa did survive a fair launch, in this day and age, with all the surrounding competition in this space.

Every single kas had an honest cost anchored to its creation, every second, every block. Fair launch means something.”

The thread argues that fair-launch proof-of-work systems face structural disadvantages early on due to the absence of preallocated capital, exchange infrastructure, or insider liquidity, forcing miners to continually adapt to new hardware generations to remain competitive.

It also contrasts Kaspa’s launch structure with networks that included premines or insider allocations, arguing that such systems can theoretically sell profitably at nearly any market price because their acquisition cost approaches zero.

“Any premine or initial dishonest allocation can dump profitably at any price as long as they exist.

Any honest trader or miner can be undercut at any price; there is no bottom but 0.”

The post further frames Kaspa’s BlockDAG architecture as an extension of that fairness model, emphasizing that the protocol accounts for parallel block work rather than discarding orphaned blocks under a longest-chain system.

While opinion-based rather than official protocol commentary, the thread reflects a recurring theme within parts of the Kaspa community: that fair launch is not only an ethical property, but also a long-term structural and economic characteristic tied to proof-of-work consensus and miner participation.

Proof of Prints Releases PoPMobile v1.1.1 Update

Proof of Prints is a Kaspa ecosystem project focused on mobile mining and proof-of-work experimentation on consumer devices, particularly Android smartphones. They released PoPMobile v1.1.1 this week, introducing diagnostics, thermal management, and mining performance updates for their mobile Kaspa mining app.

According to the release notes, the update adds live 10-second hashrate monitoring, expanded thermal sensor compatibility for additional Android devices, configurable thermal and power protections, battery saver detection, and an in-app diagnostics interface for troubleshooting unsupported chipsets.

The release also includes fixes for mining restart issues, thermal polling behavior, connection retry handling, and several UI-related crashes.

Wolfy’s Bar Hosts Second London Kaspa Meetup and Live “Blockchain Banter” Recording

Wolfy’s Bar hosted the second installment of its Kaspa-focused meetup series this week, featuring a live recording of Blockchain Banter alongside community discussions around crypto adoption, monetary systems, AI infrastructure, and Kaspa’s broader ecosystem direction.

The event was supported by Kastle Wallet and the Kaspa Ecosystem Foundation, with attendees receiving discounts on food and drinks when paying in KAS through Kastle Wallet.

Topics discussed during the livestream included fiat currencies, gold, fixed-supply digital assets, AI agents, Warp Core, vProgs, tokenization, and institutional blockchain adoption.

The livestream concluded with organizers thanking the London Kaspa community and highlighting the continued growth of in-person ecosystem events.

U.S. Senate Banking Committee Schedules CLARITY Act Vote for May 14

The U.S. Senate Banking Committee is scheduled to vote on the CLARITY Act on May 14 at 10:30 AM EST, marking a key committee step for proposed U.S. legislation on the digital asset market structure.

The bill has drawn extensive debate across the crypto and banking industries over issues including stablecoin yield treatment, regulatory jurisdiction, banking access, and the classification framework for digital assets.

Supporters of the legislation argue it could provide clearer rules for digital asset issuance, trading, and oversight in the United States, while critics have raised concerns about investor protections, anti-money laundering safeguards, and the broader regulatory scope of the proposal.

The vote comes amid broader industry expectations that U.S. crypto market structure legislation could continue to advance in 2026 as negotiations between lawmakers, banks, and digital asset firms remain ongoing.

Major Financial Institutions Continue Expanding Crypto Infrastructure Efforts

A recent Bitwise institutional adoption overview highlighted ongoing activity by major global banks, exchanges, and asset managers across crypto custody, tokenization, ETPs, and crypto-enabled payments.

The chart included firms such as BlackRock, JPMorgan Chase, Citigroup, Fidelity Investments, Goldman Sachs, Deutsche Bank, and BNY Mellon, reflecting continued institutional exploration of blockchain-based financial infrastructure beyond spot ETF exposure.

While the overview is not specific to Kaspa, the trend aligns with broader industry movement toward real-time settlement systems, tokenized assets, and programmable financial infrastructure. We believe it’s possible that DeFi, staking, and Web3 projects were merely proof-of-concept products for the future of RWAs, especially the tokenization of bonds (private and public), treasuries, and money market funds. To show what L1S and L2S can do for traditional markets. Traditional finance, in the end, will want a single chain anchored to the physical world like Bitcoin, but as efficient and as fast as Ethereum or Solana. That answer is Kaspa.

Understanding GD

Latest Articles

The One Layer to Rule Them All

Bach Meets Kaspa: Toccata Upgrades and Thrid-party Updates

Heroes in the Making: From Introducing A Mathematical Kaspian Oracle Framework to Liberated Potatoes