bitcoin dev's were discussing covenants back in 2013. bip-119 later proposed one approach to covenants, restricting spending to a predefined transaction template. it was never activated on btc tho. kaspa’s covenants go further (covenants++ if you like). scripts can enforce spending rules, carry application state forward and let that state split into branches that progress independently. multiple contracts can also update together in one transaction, with all changes accepted or none of them. dev's write that logic in silverscript, which compiles it into scripts kaspa enforces on L1.

Max inviting devs to try a testnet vProg app in their browsers and then be curious on how it works, maybe even write their own prog? i assume it will also help to identify bottlenecks, so let's congest there.

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…

i used to think real-time execution was the one thing that couldn’t be faked on bitcoin L1. i stand corrected.

🚨 Community Update Trading on ZealousSwap is now reopened on Igra L2. The Kasplex KRC 20 indexer has been paused and the KAT Bridge routes from KRC 20 L1 to Igra and Kasplex L2 are closed, preventing additional unbacked KRC 20 supply from entering Igra. We know ZEAL supply on the L2s was inflated as a result of the incident. While this issue did not originate from ZealousSwap, we are taking responsibility for dealing with its consequences as fairly as possible. All trades that happened during and after the incident remain valid. This includes users who bought ZEAL at heavily discounted prices. We will not invalidate legitimate trades or penalize anyone for trading the market that existed at the time. With the affected route now closed, we are comfortable reopening trading on Igra L2. Kasplex L2 trading will remain paused for now while we continue working on the recovery plan.

⚠️ Status update: what to do if you received unexpected iKAS on 21 September. Short version: if you received iKAS from any address on this list, please send it to the Igra DAO Governance contract: 0xB3300fcC2F3EF3DeCdF8B1f710c21666f33Cbf18 explorer.igralabs.com/accoun… Long version: The attacker behind the KRC-20 incident sent amounts of 5,000 to 10,000 iKAS to around 35 wallets that seemingly have nothing to do with the attack. This was done to make uninvolved users look connected to it. You are not under suspicion. Anyone can send to any address and you could not have refused it. Your own funds are unaffected, and exits covered by your own balance and deposits will settle normally. Funds originating from the attacker cannot be bridged out. The exit settlement operators settle against amounts traceable to your own deposits, so anything traced to the attacker's wallets will not be paid out. These are stolen funds. Returning them is voluntary, takes one transaction, and costs you nothing you could otherwise use. If you already moved or spent it, email team@igralabs.com and we'll help sort it out.

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.

We just want to take a moment to say thank you. The amount of support, patience, and kind messages we’ve received over the last couple of days has honestly meant a lot to us. We’ve read your messages, and we’re extremely grateful to have this community behind us during such unfortunate circumstances. As we’ve already explained in our reports, ZealousSwap itself was not exploited. The issue originated from the KRC 20 indexer, but unfortunately the consequences reached our liquidity pools and affected many of you. We also want to make something clear for anyone who may not know this: the ZealousSwap protocol itself was one of the biggest liquidity providers in both the ZEAL and NACHO pools, so the protocol suffered significant losses alongside everyone else. But when it comes to the recovery plan, recovering the protocol’s own liquidity is not our priority. Our focus is on the community. We are working tirelessly on a recovery plan that is as fair as possible to everyone affected, including those who bought after the incident. There are a lot of moving pieces and we want to make sure we get this right rather than rush into a solution that creates another group of people who are treated unfairly. If recovering users means the protocol never recovers its own lost liquidity, we are prepared for that. Removing the protocol from the recovery equation also makes what we are trying to achieve significantly more realistic. We’re sorry that our community has had to go through this, even though the vulnerability itself was outside of ZealousSwap. Right now, what matters to us is what we do next. Thank you again for sticking with us. ❤️ We’ll share the recovery plan as soon as we’re confident it is the fairest path forward.