TL;DR:

• Yonatan wows at TOKENIZE: LDN, where he describes real-time decentralization.

• Binance does not mention Yonatan or Michael at Binance Blockchain’s Week, Blockchain 100 awards ceremony. This fuels the Kaspaian Bye-nance movement.

• Kapsa is mentioned in the French media.

• New projects are being built on Kaspa.

Yonaton’s Keynote at TOKENIZE: LDN

At TOKENIZE: LDN, Kaspa co-founder Yonatan Sompolinsky delivered a forward-looking talk on what he calls “real-time decentralization”—a concept at the heart of Kaspa’s innovation and the next step in blockchain architecture.

Yonatan began by defining the principle that distinguishes crypto systems from traditional finance: the ability to trust math rather than intermediaries. Using cryptography and zero-knowledge proofs, users can verify the truth without relying on a central authority. But he noted that the real challenge isn’t internal trust; it’s how crypto systems connect to the outside world. “The only way to use crypto as money,” he said, “is to link it to external systems while remaining trustless.”

He illustrated this using an example from market behavior. Suppose an index decides whether to include a company like MicroStrategy. If approved, Bitcoin might surge; if rejected, it could drop. These external events influence crypto valuations, but the systems themselves remain isolated. To bridge that gap, Yonatan proposed a model where strategies are devised and delegated to an internet money layer, which is a smart, cohesive structure enabling real-time adjustments without human intervention.

Under this vision, smart centralized exchanges, brokers, and third-party networks become participants in a continuously flowing digital economy. Time, he explained, can be thought of as a flow from left to right. By connecting the internet money layer to the broader monetary layer, users can embed instructions directly into protocol behavior. This is where Proof-of-Work (PoW), and more specifically Kaspa’s PoW-based DAG, plays a critical role.

Unlike Proof-of-Stake (PoS) systems, which rely on predetermined validators, Kaspa’s PoW DAG dynamically samples the network’s honest majority hundreds of times per second. “You can’t fake a real-time consensus,” Yonatan said. At 100 blocks per second, if 10,000 miners compete, roughly 100 of them succeed in securing transactions almost instantly. This capacity to measure consensus continuously enables what he termed real-time finalization—a form of finality that’s granular, adaptive, and deeply decentralized.

Expanding on this idea, Yonatan suggested that Kaspa miners could one day serve as an auxiliary oracle network, helping connect blockchain data to external networks or even automated market makers with near-zero latency. In theory, liquidity operations on other chains, such as Solana, could benefit from such instant, miner-driven verification. As more on-chain logic and assets integrate with this structure, the demand for real-time systems would naturally grow.

When asked whether Kaspa might be tackling too many R&D goals at once, Yonatan clarified that all of these efforts converge on a single principle: the value proposition of real-time decentralization. This isn’t about adding features for novelty’s sake—it’s about ensuring that users can transact within a system that’s not only secure and open but incapable of front-running, censorship, or manipulation.

TOKENIZE LDN

Tokenize: LDN, the UK’s premier conference on real-world asset (RWA) tokenization, took place December 2–3, 2025, at ExCeL London, co-located with FinTech Connect. The event drew over 5,000 industry leaders and featured 100+ exhibitors and 140+ speakers covering tokenized treasuries, real estate, funds, credit, regulation, and institutional blockchain infrastructure. Over two days of panels, demos, and networking, Tokenize: LDN showcased how TradFi and Web3 are converging to bring real-world assets on-chain and unlock the next wave of institutional adoption.

In addition to Dr. Yonatan Sompolinsky’s keynote talk discussed earlier, the Kaspa Ecosystem (KEF) had a booth that quickly became one of the most energetic spots on the floor. Community members noted how busy the booth stayed throughout the event, with nonstop conversations about Kaspa’s roadmap, ecosystem growth, and real-world use cases.

The celebration continued at Wolfy’s Bar in London, where the Kaspa community hosted an unforgettable afterparty. Guests enjoyed great food and lively conversations. They even had the chance to pay their tab in KAS, offering a small but powerful glimpse of what mainstream crypto payments could look like. It was a perfect capstone to a weekend that showcased both Kaspa’s momentum and its growing cultural footprint. The Kaspa community came out, including the Rock the Kaspa brothers, Chris and Tom, Wolfy’s Bar himself, @LevendiPro, and Kaspa Leidy. 

Binance Snubs Yonatan and Michael Sutton 

Despite Dr. Yonatan Sompolinsky and Michael Sutton winning top honors in Binance’s 2025 Blockchain 100 awards, neither was acknowledged at the Dubai ceremony. Yonatan took first place for Independent Researcher, while Sutton secured third as Industry Advocate. The omission has sparked backlash in the Kaspa community, with members withdrawing funds, closing Binance accounts, and trending “Bye-Nance” online. The community urges Binance to make amends.

XXIM Podcast : ZK Proofs + BlockDAG = Endgame 

XXIM Podcast host Ankit released a short monologue video explaining why he sees Kaspa’s vProgs (verifiable programs) as an “endgame” architecture for crypto. In his framing, Layer 1 doesn’t need to know the details of what happens inside each vProg; it only needs confidence that the off‑chain computation was executed honestly. This separation lets Kaspa maintain its high‑speed BlockDAG while still inheriting the security guarantees of zero‑knowledge proofs.

At the heart of this design is the prover—the entity responsible for convincing Layer 1 that all off‑chain activity followed the rules. Provers perform heavy computation off‑chain and submit a roughly 300‑byte zk‑proof “receipt,” together with the previous and current root states of the vProg. The root state acts as the vProg’s own ledger or audit book, tracking whose turn it is and what the system looks like at each step.

Each time a user trades or interacts with a vProg, that off‑chain ledger updates, and Kaspa’s Layer 1 must decide whether to accept the prover’s new state. The base layer makes that decision by verifying three things: that the proof belongs to the correct vProg, that the submitted previous root matches the last accepted one, and that the proof's math checks out. Only then does Layer 1 record the transition. Without provers, there are no vProgs at all—they’re the bridge bringing off‑chain execution back onto the canonical on‑chain record.

Ankit’s clear walk‑through makes this dense topic feel intuitive. The short monologue format suits users who want a high‑level mental model before diving into technical content, and it sets a strong foundation for future XXIM episodes on Kaspa’s programmability. As Ankit summarizes, “ZK proofs plus Kaspa’s BlockDAG is about as close to a crypto endgame as it gets.”

New Project - K Town

K Town is a new Kaspa‑native virtual world designed to turn on‑chain activity into an engaging social game. In this ecosystem, players bring their NFTs to life as in‑game characters, build relationships, take jobs, and join events, creating a self‑sustaining virtual economy where transactions occur organically rather than through bots. By leveraging Kaspa’s high speed and low fees, K Town aims to drive real adoption while supporting miners through frequent, meaningful transactions. Wishing the K Town team the best of luck with their upcoming launch.

Kaspa Reddit Tip Bot 

A major new community tool has just gone live on r/Kaspa: a fully noncustodial Kaspa tip bot paired with its companion site, Kaspa‑bot.com. After months of development, the bot is now active, stable, and ready for everyday use, giving Reddit users a simple, trustless way to send and receive Kaspa tips directly on chain.

Unlike typical tipping systems, this bot never holds user funds. Every tip is a real Layer‑1 Kaspa transaction sent directly from a user’s wallet. No pooled balances. No IOUs. No custodial risk.

How it works:

• Comment with !tip to send any amount of KAS to a post or user.

• The bot replies with a secure, non‑custodial payment link hosted on Kaspa‑bot.com. 

• Approve the transaction in KasWare or any Kaspa wallet.

• A receipt and explorer link confirm the tip on‑chain.

The companion website adds a polished UX layer, featuring:

• Detailed tip pages showing sender, receiver, amount, and address

• On‑chain receipts and explorer links

• Leaderboards for top tippers, receivers, and posts

• Personal stats via !mystats, plus simple market and network data

Getting started is easy. Read through their full guide here to learn exactly how to register, tip, and verify your transactions: 

This launch introduces a fun, decentralized, and secure way to reward creators and strengthen the Kaspa community while showcasing the speed and simplicity of Kaspa’s Layer 1.

KIP-0012: A Unified Wallet API for Kaspa

KIP‑0012 is a Kaspa Improvement Proposal that standardizes how browser extension wallets communicate with decentralized applications (dApps). Right now, developers must write separate code for each Kaspa wallet they want to support, each with its own API, naming conventions, and methods. This fragmentation creates friction and slows adoption.

KIP‑0012 proposes a unified wallet API specification. With it, developers can integrate any compliant Kaspa wallet using a single codebase, much like how WalletConnect supports hundreds of wallets across other blockchains. The specification defines standard methods for common wallet operations such as connecting, signing messages, and handling transactions.

A proof‑of‑concept implementation demonstrates the idea in action. Users visit a dApp, click “connect wallet,” and choose any KIP‑0012‑compatible extension. The wallet then prompts for permission, and once approved, the dApp can request signatures and other operations through standardized methods. The demo includes working Firefox and Chrome extensions built from the same codebase, highlighting cross‑browser compatibility.

This standardization benefits the entire Kaspa ecosystem. Wallet developers can implement a single specification instead of multiple custom APIs. DApp developers write less code while automatically supporting more wallets. Users gain seamless wallet switching. The proposal also paves the way for future SDKs and authentication providers, such as the planned Supabase integration, to work universally across Kaspa wallets.

InvestX Article on Kaspa vProgs

On December 3, 2025, French crypto news site InvestX.fr published an article about Kaspa’s upcoming vProgs. They stated:

“As the crypto market regains strength, Kaspa (KAS) appears poised for a significant move, fueled by massive accumulation from "whales" and an imminent technical revolution. With the introduction of vProgs and increasing institutional interest, all signs point to an explosive end to the year.”

They cite Kaspa’s vProgs as the technical advancement to fully solve the blockchain trilemma of speed, security, and decentralization, all while maintaining near-instant finality.

Additionally, vProgs will update token utility, potentially reducing supply available on exchanges:

“This new model introduces an economy of provers who will need to stake KAS to participate in the network and generate ZK proofs.”

They concluded: 

“If the technical roadmap is followed, Kaspa will no longer be considered merely “fast Bitcoin,” but as the universal settlement layer for tomorrow’s digital economy. The combination of supply becoming scarcer through prover staking and growing institutional demand could catalyze a major rally in the coming weeks.” 

MS at Web3 Underground

On November 16, 2025, Kaspa core developer Michael Sutton spoke at the Web3 Devs Underground meeting, later posted to YouTube. Sutton explained how Kaspa’s 10-block-per-second L1 creates a unique foundation: an ultra-fast, proof-of-work base layer that delivers high data throughput (currently ~3,000 TPS) without taking on the burden of on-chain computation or complex state. As he put it, Kaspa L1 should remain a “Satoshi-inspired amplification layer and not a computational layer”.​

Because Kaspa L1 is designed to stay thin and decentralized, the execution layer must live off-chain—but without sacrificing developer experience, composability, or liquidity. This leads naturally to based rollups, where L1 acts as the global sequencer and source of data availability, while L2s handle computation and state.

The challenge: single rollups create noisy-neighbor problems, while many rollups fragment liquidity and make synchronous calls nearly impossible. Kaspa’s design attempts to resolve this by leveraging a key advantage: every rollup shares the same canonical L1 sequence. That shared sequencing allows programs to deterministically know each other’s state at the moment of execution, enabling synchronous composability across independent apps.

To make this work, the team proposes a model with logic–state separation, explicit account dependencies, L1-verified witness anchors, and a two-phase ZK proving system that stitches conditional proofs into a single verified execution. This architecture keeps apps sovereign yet still interoperable—“flattening the space into a one-dimensional execution layer” where composability no longer defines the borders between rollups.​

In short, Kaspa’s high-frequency L1 sequencing enables a new category of based rollups with synchronous composability and scalable independence, without sacrificing decentralization.

Hans Moog Post

Kaspa contributor Hans Moog argues that Kaspa’s new runtime is scalable not because it squeezes more work into each block, but because it stops treating blocks as the primary unit of computation. Instead of batching state changes into strictly ordered blocks, the system views them as a continuous flow of causally related transactions, while blocks are demoted to lightweight markers that only define where reorgs are still possible. In this model, the core problem shifts from “how fast can we empty each block” to “how well can we spread all currently known tasks across the entire blockDAG”.​

That change has big consequences for performance. In traditional chains, if a block happens to contain a lot of sequential, non-parallelizable work, the whole network effectively pauses on that block until the work is finished, even if there are plenty of unrelated transactions that could have been processed in parallel. By contrast, Kaspa’s runtime can execute independent transactions immediately, including ones that belong to blocks further ahead in the DAG. This avoids idle CPU time, keeps cores busy, and sidesteps the classic “straggler” effect, where one heavy block slows down the entire pipeline.

Moog also points out that most DLTs tightly couple block production with state commitments, proofs, and other finalization steps, which forces them into a sequential execution model. Even if they allow some degree of intra-block parallelism, they still wait for a block to complete before moving on. That design bundles together concerns that should be separate: consensus on block ordering, on the one hand, and efficient workload scheduling, on the other. Kaspa intentionally separates those concerns. Its runtime reduces to a small, generic framework that can run any access-control-list-enabled virtual machine at near bare-metal speed, because it just has to model causal dependencies between state changes, not manage consensus logic at the same layer.

Technically, Moog highlights three properties of the execution flow: it is lock-free, it avoids write-ahead-log flushes and global synchronization barriers, and it relies on eventual consistency rather than strict, instant global agreement. That combination is designed to map cleanly onto how modern multi-core hardware actually works, letting the scheduler exploit parallelism without being constantly blocked by global locks or forced checkpoints. In his view, this leads to an architecture that is simpler, more scalable, and more hardware-efficient than today’s mainstream blockchain runtimes.​

To explain the impact, he compares Kaspa’s approach to what TensorFlow and CUDA Graphs did for machine learning. Frameworks like those turned abstract parallelism into concrete, hardware-aware execution plans that let GPUs reach their real potential. Moog sees Kaspa doing something similar for distributed ledgers by exposing a parallel execution model that should scale with the underlying hardware, enabling lab-grade throughput numbers, such as the 64,000 transactions per second often cited for Solana, to be achieved in practice rather than just on paper.

He also connects this work back to his long-standing ambitions from the IOTA days, saying this is the kind of architecture he always wanted to build and that it finally exists in Kaspa’s design. Above the low-level runtime, the team is still building higher-level abstractions, including a capability-based linear type system for state and resource management. The goal is to avoid manual “capability wiring” patterns seen in some other ecosystems, while preserving safety and scalability. Moog argues that directly modeling the causal structure of state changes, down to hardware-relevant details, is about as far as one can push scalability in a general-purpose ledger.

Beyond the theory, he is clearly excited about the developer experience. He notes that the API surface is intentionally small and “Rayon-like” in abstraction level, referencing Rust’s popular data-parallel library, and links to a public test file in the kas-l2 repository as an example of how straightforward the code can look in practice. He closes by thanking KEF and the Kaspa community for the opportunity to work on this, saying it feels like “coming home,” and predicts that the capabilities unlocked by this runtime will make Kaspa impossible to ignore.