Over the past year something fairly decisive happened in institutional finance: the largest banks and asset managers in the world stopped treating distributed ledger technology as a future bet and started deploying it in production. BlackRock crossed $2.5 billion in its tokenized treasury fund and its COO went on record calling the technology the biggest financial breakthrough since double-entry bookkeeping. JPMorgan launched a $100 million tokenized money market fund and processes billions daily through Kinexys. Deutsche Bank is running tokenized fund management live on a zero-knowledge chain. Broadridge handles over $1.5 trillion a month in repo volume on DLT with UBS, Société Générale, and JPMorgan. Four of the largest US banks began working on a joint stablecoin once the GENIUS Act gave them a regulatory framework. Stablecoins as a category surpassed $316 billion in market cap and moved $27.6 trillion in volume last year, which is more than Visa and Mastercard combined. Nasdaq filed with the SEC for on-chain settlement. MiCA is fully in effect across Europe.
The common thread across all of this activity is that every single one of these institutions needs the same thing, and none of them can get it from public infrastructure alone. They need a ledger they control, running on their own infrastructure, where transaction data and counterparty identities remain confidential, where access is governed by the same compliance and permissioning structures they already use internally, and where regulators and auditors can still verify that the system did what it claims to have done. That last part is the hard part. The moment you take a ledger private, you lose the ability for outsiders to independently verify it, which means you’ve essentially built a well-structured database and called it something grander. The entire value proposition of a distributed ledger where someone other than the operator can confirm its integrity disappears.
Zero-knowledge proofs change this equation in a fundamental way, because they allow a private ledger to generate mathematical evidence that every state transition was computed correctly according to the stated rules, without revealing any of the underlying data. The proof is small, it can be recorded on a public network where anyone can verify it, and it tells the verifier everything they need to know about correctness without telling them anything about the actual transactions. This is the technology that makes it possible to have genuine privacy and genuine verifiability at the same time, and it’s the core of what we’ve built with Cocoon.
Cocoon
Cocoon is a complete stack for running permissioned distributed ledgers on institutional infrastructure. When we say complete, we mean that it covers the full vertical from the user-facing access layer down to the cryptographic settlement layer; it’s not a framework you assemble from parts, it’s an integrated system that an institution can deploy, operate, and govern as a single product.
From an operational perspective, Cocoon is designed to fit into existing enterprise environments rather than requiring institutions to adopt an unfamiliar technology stack. Users authenticate through the institution’s existing identity providers so that access is governed by the same identity infrastructure the institution already manages. The system can be configured so that end users interact through familiar web or mobile interfaces and never need to manage cryptographic keys, wallets, or any cryptocurrency-native concepts.
Where Cocoon diverges from a standard private ledger deployment is in three areas that we believe are decisive for institutional adoption: how access is controlled, how data is disclosed to external parties, and how correctness is proved to the outside world.
Access is controlled through a gateway layer that sits in front of the ledger and intercepts every inbound request. This layer doesn’t just authenticate the user and check whether they’re allowed to perform a given operation; it can inspect the actual parameters of the transaction and enforce constraints on them.
Data disclosure is handled through dedicated selective disclosure endpoints that serve specific data points along with zero-knowledge proofs attesting to their correctness, so that auditors and regulators can verify what they’re told without needing access to the full ledger. This replaces the trust-based model with a proof-based model where the recipient has independent mathematical evidence.
And correctness is proved by generating a zero-knowledge proof for every batch of transactions, which is then permanently recorded on a public settlement layer where anyone can verify it. When a batch of transactions is processed, Cocoon’s proving engine generates a succinct cryptographic proof that the ledger executed every transaction correctly and that the resulting state transition is valid. This proof is permanently recorded and can be independently verified by anyone at any time. It reveals nothing about the transactions themselves but it provides an irrefutable mathematical guarantee that the private ledger’s computation was performed correctly according to the published rules.
The institution operates everything. The ledger’s consensus, execution, storage, permissioning, proof generation, and public settlement are all components that the institution controls, updates, and governs according to its own policies. If the institution wants to run multiple Cocoon ledgers — for example, one for its asset management division and another for its treasury operations — they can do so independently or connect them through cross-ledger messaging where each side verifies the other’s proofs. If multiple institutions want to collaborate, each runs its own ledger and they interoperate through the same proof-verification mechanism, meaning no single party needs to trust any other party’s infrastructure.
Zilkworm: The Proving Engine
At the core of Cocoon’s architecture sits Zilkworm, Erigon’s high-performance zero-knowledge proving engine written in C++. Zilkworm is not a wrapper around an existing prover or an off-the-shelf integration; it’s a purpose-built system that our team has been developing alongside Erigon’s core client, and it is the component that makes Cocoon’s guarantees possible. When we say that a private ledger can prove it followed its rules, Zilkworm is the thing that actually produces those proofs.
Zilkworm uses a RISC-V backend, which is an important architectural choice. RISC-V is an open instruction set architecture that gives Zilkworm direct access to low-level hardware optimization in a way that higher-level frameworks cannot match. The result is that Zilkworm generates proofs significantly more efficiently than competing provers. This efficiency matters because proof generation cost is one of the primary operational expenses for any ZK-based system, and Zilkworm’s performance advantage translates directly into lower per-transaction costs for institutions running Cocoon in production.
The C++ implementation is itself a meaningful differentiator. The zero-knowledge proving space is heavily dominated by Rust-based implementations, and while Rust is an excellent language, having a high-performance C++ alternative provides the kind of client diversity that the broader ecosystem values for resilience.
But the most significant aspect of Zilkworm for Cocoon’s enterprise value proposition is not raw speed; it’s the ability to embed custom business logic directly in the proving pipeline. Zilkworm’s architecture decouples business rules from the zero-knowledge mathematics, which means an institution can define compliance rules, fund mandates, regulatory thresholds, and operational constraints in familiar terms, and Zilkworm will enforce them at the proof level. A rule violation doesn’t get caught by application code and reverted; Zilkworm literally cannot produce a valid proof for a state transition that violates the embedded rules. This is the capability that enables what we call protocol-level compliance, and we’ll explore it in depth in Part 2 of this series.
Zilkworm also has the ability to adapt its proving pipeline to different protocol requirements, which means that if an institution needs to enforce jurisdiction-specific regulations these can be embedded at the proof level and swapped or updated without rebuilding the entire system. For institutions operating across multiple regulatory jurisdictions, this flexibility is essential.
Who We Are
Erigon has been building core blockchain infrastructure for years, in partnership with some of the most important organisations in the space. Zilkworm grew out of Silkworm, our earlier C++ execution client, and represents years of accumulated expertise in high-performance blockchain computation. Cocoon is where all of that expertise, i.e., the client engineering, the data model, the proving engine comes together into a product for institutional finance.
We believe the gap between what institutions need and what existing public and private ledger technology offers is real but entirely bridgeable with zero-knowledge proofs. A private ledger that can prove it followed the rules is a fundamentally different product than one that asks you to trust it, and that’s what we’ve built.
What’s Next
In Part 2 of this series, we’ll go deep into what makes Cocoon architecturally different from other permissioned ZK ledgers: argument-level permissioning, proof-backed selective disclosure, protocol-level rule enforcement via Zilkworm, and the sovereignty model that avoids ecosystem lock-in. These are the features that we believe separate a workshop demo from a production-ready system for regulated finance.
In Part 3, we’ll walk through the specific use cases where Cocoon’s architecture fits the market’s strongest demand signals from tokenized money market funds and intraday repo to cross-border payments, shared KYC, private credit, and more.
If you’re an institution evaluating private ledger infrastructure or exploring tokenized asset issuance, we’d very much like to hear from you.