Major breakthrough for the Kaspa Privacy Initiative! 💚🚀 Yesterday, we hit a serious bottleneck: generating our full zero-knowledge execution proof on CPU was taking far too long. So we rented an NVIDIA L40S GPU. And it worked! ✅ Full cryptographic proof in just 4 minutes and 16 seconds ✅ Independently verified on CPU ✅ Invalid operations correctly rejected ✅ Estimated GPU rental cost: just $0.12 For the first time, we've demonstrated that our complete test-model execution can be cryptographically proven in minutes, at a surprisingly low cost. And that opens up some exciting possibilities. 👇

For people wondering what a scalable private KAS protocol on Kaspa could actually look like before vProgs, here is one possible architecture. This is not a final design. We still want to test, challenge and shape the architecture together with the Kaspa community. But the pieces are starting to form a pretty coherent picture. Imagine you shield 100 KAS. Your wallet creates a private note representing those 100 KAS. Publicly, only a cryptographic commitment is added to the shielded state. Nobody looking at that commitment should be able to tell who owns it or how much KAS it represents. Later you want to spend 20 KAS. Your wallet creates a proof that you own a valid unspent note and that the spend follows the protocol rules. At the same time, the old note gets a nullifier so it can never be spent twice, and new private outputs are created, for example 20 KAS to the recipient and 80 KAS back to yourself. From there, several roles appear: Wallet / prover Holds the secrets and creates the private spend proof. Proving can happen locally, with delegated proving potentially becoming an option for constrained devices. Relayer Can submit the operation without requiring the user’s normal Kaspa wallet address to be the visible sender on L1. Batcher Collects many valid private operations and turns them into one provable state transition, instead of forcing one shared covenant state to process every spend one by one. Indexer / data provider Helps wallets reconstruct Merkle paths and other public data needed for future proofs. It does not need to be trusted because wallets can verify the data against state roots accepted by Kaspa. Kaspa + covenant Native KAS remains secured by Kaspa. The covenant holds the funds and only accepts state transitions or exits that satisfy the cryptographic rules. The private state could ultimately be represented by compact cryptographic roots, for example a commitment root representing the set of private notes and a nullifier-state root representing notes that have already been spent. So the rough separation becomes: wallets authorize → provers prove → relayers submit → batchers scale → indexers serve data → miners get paid → Kaspa decides what state is valid The interesting part is that none of the intermediate actors should need custody of your KAS or need to be trusted to tell the truth. A malicious relayer, batcher or indexer should not be able to steal funds, create KAS or make an invalid state valid. At worst, depending on the final design, they should only be able to delay or censor, which is why permissionless participation and a trustless exit path matter so much. There are still important pieces to prove in practice: trustless exit, data availability, censorship resistance, batching rules, fee privacy, mobile proving and the exact covenant construction. vProgs may later make parts of this much more native and elegant. But this gives a pretty good picture of how a scalable shielded KAS protocol could potentially work with the primitives Kaspa already has today: native KAS, covenants and ZK verification. github.com/olafweller/kaspa-…