This tic-tac-toe demo is far more important than the game itself. It is a working example of what vProgs can turn Kaspa into: a sequencing and settlement layer for stateful applications without forcing every piece of application logic to execute directly on L1. Two players can lock KAS into a pot, play a multi-round match, and have the result determined by a verifiable program. The game logic executes through a RISC Zero guest, while Kaspa orders the application activity. The resulting state transitions are proven, aggregated, and ultimately checked by an L1 settlement covenant before funds can exit to the winner or be returned after a draw. That architecture is the real story. Tic-tac-toe can be replaced with an exchange, prediction market, multiplayer game, auction, payment network, AI-agent economy, or other application with shared state. Kaspa provides ordering, data availability, settlement and the security anchor, while computation happens outside the consensus-critical path and proofs establish that the rules were followed. This is how Kaspa can scale programmability without turning every node into a global computer. vProgs effectively let applications bring their own execution environment while inheriting verifiable settlement from Kaspa. Tic-tac-toe is just the smallest possible demonstration of a much larger application model.

Tic-tac-toe is live on Kaspa testnet: the first vprog, a verifiable program with real execution and real settlement, running since yesterday. You can play it here: vprogs-tt.izio.fr/ (Requires private key and some testnet funds) We still need to review and merge a stack of PRs, however this is already a working POC. UI/UX was never a priority; the frontend can be enhanced or built separately I'm gonna work on mdBook covering the parts of the system I consider meaningful and a workshop on vprogs and building apps on top For Devs: this is the invitation. Play the game, read the code, build your own vprog. Game code: github.com/biryukovmaxim/vpr… vprogs framework: github.com/kaspanet/vprogs/t…

SilverScript Studio is now live on mainnet. Write Kaspa covenants by hand, with a wizard, or by describing them to an AI that speaks only SilverScript. Deposit and withdraw with your own wallet: Kasware, Kasla, Kastle (Kastle to deposit; signing support is coming). Multi-signer covenants get a link the other parties sign from. silverscriptstudio.com

Kinda wow? $kas markets.businessinsider.com/…

While prototyping KCC-20 I got asked how should token symbols, descriptions, images, and other kind of metadata be defined. On EVM systems, there is a single SC which represents a token, and holds both its balance state and global state. On the UTXO model there is no global state, the token is split and held across holders, each one holds his specific token (UTXO/covenant). This means that adding state fields for metadata would duplicate them across each UTXO, which is wasteful. Things such as representation, name, symbol or image are also not part of the SC logic, and should not be part of it. A naive approach is to declare such metadata in the payload field of a tx, which is an "empty space" that can be used to write whatever information. The issue is that Kaspa is prunable. Eventually, the block containing this tx would no longer be available for verification, so at some point the data would need to be trusted by off chain entity. After drafting a few solutions, we came up with KCC-23, a convention for binding the metadata to the covenant ID itself. Read more on Kas-Smiths: kas-smiths.org/t/kcc-23-conv… Or read the KCC draft: github.com/kaspanet/kccs/pul…

Kaspa v2.1.0 is out [Link in the reply] All node, mining, and infrastructure operators across mainnet and testnets are strongly encouraged to upgrade. This release introduces P2P Protocol Version 11, extracts a standalone ZK SDK, and reflects an ongoing focus on proactive defense-in-depth across the node architecture. Key Highlights: • P2P Protocol Version 11 & Chunked IBD: Large Initial Block Download (IBD) payloads (including Pruning Point Proofs, headers, and trusted data) are now streamed in 20 MiB chunks. This eliminates message- framing bottlenecks and timeouts during node sync, backed by overall safety limits and transfer timeouts, while maintaining full backwards compatibility with Protocol 10 peers. • Standalone ZK SDK: Zero-Knowledge proof and script-generation tooling has been extracted into a dedicated crate (kaspa-txscript-zk-sdk). It adds support for RISC Zero Groth16 and STARK verifier generation with dynamic or static image IDs, bounds control proofs against oversized inputs, and resolves cross-platform build issues. • General Hardening: Comprehensive defense-in-depth upgrades across the node, including stricter P2P message and block limits to guard against DoS vectors, a workspace-wide arithmetic safety audit to eliminate overflow risks, enhanced stratum bridge stability, and tighter consensus validation. These structural safeguards significantly strengthen node resilience and provide higher confidence in overall network security.

There is a high chance clarity Act won't pass today but will be passed in the future. Whether it passes or not, Kaspa's growth still remains unstoppable. $KAS