Previously we introduced Cocoon, a complete stack for running permissioned distributed ledgers on institutional infrastructure, with Zilkworm as its zero-knowledge proving engine.
The market for permissioned ZK ledgers is not empty and other teams have been building in this space and the traction they’ve achieved is genuinely impressive, with dozens of major banks participating in workshops, at least one tier-1 institution already running in production, and the concept validated by serious institutional research. We think that’s a good thing, because it means the market is real. But validation of the category is not the same as solving all the hard problems, and there are architectural decisions we’ve made in Cocoon that we believe address gaps the current generation of products has left open. These aren’t minor differences in performance or user interface; they’re structural choices about how permissioning works, how data is disclosed, how rules are enforced, and how much sovereignty the operator retains. They matter enormously once you move from a workshop demo to a production deployment in a regulated environment.
Argument-Level Permissioning
The standard approach to permissioning on a private ledger is to control access at two levels: which users or roles can interact with which contracts, and which functions they’re allowed to call. This works well for basic access control, but it leaves a significant gap for regulated institutions, because in practice the question is “can this trader execute a repo with these specific terms.” The difference matters because compliance requirements are almost always about the parameters of a transaction, not just the existence of it. Regulations set limits on notional amounts, require minimum haircuts on collateral, cap tenor lengths, restrict counterparty exposure, and impose concentration limits, and all of these constraints are about the values inside the transaction, not just the fact that it was submitted.
Cocoon’s permissioning system adds a third level of control that addresses this directly: constraints on the actual arguments of the operation. The gateway layer that sits in front of the ledger inspects every inbound transaction and checks not only whether the user is authorised to call a given function, but whether the parameters they’re passing satisfy the constraints defined by the institution’s compliance team. A rule might say that traders with the role “Sr. Trader” can execute the openRepo operation, but only if the tenor parameter is 30 days or fewer, the haircut parameter is at least 2%, and the notional parameter does not exceed $50 million. A transaction that violates any of these constraints is rejected at the gateway before it reaches the ledger. The rules are configured through an administrative interface, can be updated dynamically without restarting the system, and every rule change is logged in an immutable audit trail.
This is a qualitative difference in what a permissioning system can express. Access-level permissioning answers the question “who is allowed to trade,” which is necessary but not sufficient for compliance. Argument-level permissioning answers “what are they allowed to trade, in what quantities, under what conditions, and with what constraints,” which is what compliance officers, risk managers, and regulators actually care about. To our knowledge, no other permissioned ZK ledger currently offers this capability, and we believe it is one of the most important features for any institution that intends to operate in a regulated environment.
Selective Disclosure Backed by Proof
Every institution that operates a private ledger will eventually need to share specific data with external parties such as auditors conducting annual reviews, regulators performing compliance examinations, counterparties verifying positions, or legal teams gathering evidence for dispute resolution. The question is what “sharing data” actually means in terms of the assurance the recipient gets. On most private ledgers, disclosure is handled through access control: an administrator grants the recipient permission to query certain data, the recipient sees the result, and they trust that it accurately reflects the underlying state. This is useful, but it’s fundamentally a trust-based model as the recipient has to believe the operator is being honest, because they have no independent way to verify what they’re seeing.
Cocoon replaces this with proof-backed disclosure. When data is shared through a selective disclosure endpoint, the recipient receives the requested data along with a zero-knowledge proof that the data is correctly derived from the ledger’s actual state. The recipient verifies this proof independently using publicly available tooling, and the verification is purely mathematical: it either passes or it doesn’t. The recipient doesn’t need to trust the ledger operator, doesn’t need to run any Cocoon software, and doesn’t need access to the underlying system. For example, an auditor requesting the total AUM of a tokenized fund receives the number together with a proof that the number corresponds to the sum of all share balances on the ledger as of a specific point in time, and they can verify that proof against the publicly recorded state root. The auditor now has cryptographic evidence, not an assertion.
Protocol-Level Rule Enforcement via Zilkworm
On virtually all distributed ledger architectures today, business rules are implemented in smart contracts. This makes sense because smart contracts are expressive, composable, and auditable, and the industry has built mature tooling around them. But smart contracts are application-layer code, and application-layer code has properties that matter in high-stakes environments: it can contain bugs that go undetected through audits, it can be upgraded through governance mechanisms that may not have the safeguards a regulator expects, and a sufficiently privileged administrator could potentially modify or bypass the rules. For many use cases this is an acceptable risk. For some particularly those involving regulatory compliance, fiduciary obligations, or systemically important operations it isn’t.
This is where Zilkworm’s architecture becomes decisive. Because Zilkworm’s RISC-V pipeline decouples business logic from the zero-knowledge mathematics, institutions can define compliance rules, fund mandates, regulatory thresholds, and operational constraints in terms their compliance teams understand, and Zilkworm will embed those rules directly in the proving pipeline. When a rule is enforced at the proof level, the zero-knowledge proof itself attests not only that the ledger executed every transaction correctly, but that the custom rules were satisfied by every transaction in the batch.
Fund mandates that cap sector allocation, regulatory thresholds on transaction size, concentration limits on counterparty exposure — any quantifiable rule can be embedded at this level. And because Zilkworm’s pipeline supports protocol customisation, these rules can be updated without rebuilding the prover from scratch.
No Ecosystem Lock-In
Some enterprise distributed ledger products require the operator to join a specific network, route transactions through a shared gateway, use a designated interoperability protocol, or hold and spend a utility token as part of normal operations. These requirements create dependencies that are commercially significant and operationally risky: they give an external party influence over the institution’s cost structure, they introduce a point of failure outside the institution’s control, and they may create regulatory complications depending on how the token is classified in the institution’s jurisdiction.
Cocoon has none of these dependencies. If the institution wants to connect two of its own Cocoon ledgers, they verify each other’s proofs directly. If two institutions want to interoperate, each runs its own ledger and they communicate through proof-verified messaging. If the institution wants to remain completely isolated from everything external, that works too. The architecture is deliberately agnostic about network topology because we believe an institution’s infrastructure choices should be driven by its own requirements, not by its vendor’s business model.
Conclusion
These capabilities are not independent features. They form a coherent architecture where every layer reinforces the others. The gateway enforces business constraints before transactions enter the ledger. Zilkworm proves that the ledger followed its rules at the mathematical level. Selective disclosure lets external parties verify specific facts about the ledger’s state without trusting the operator. And the entire system runs on infrastructure the institution owns and controls, with no external dependencies that could create commercial leverage, operational risk, or regulatory exposure.
We believe this combination is unique in the market today, and we believe it is what production deployment in a regulated environment actually requires. The gap between a technically working ZK chain and a system that a bank’s compliance department, legal team, and board of directors will approve for production use is significant, and it’s the gap these architectural choices are designed to close.
What’s Next
In the next article of this series, we’ll walk through the specific use cases where Cocoon’s architecture meets the market’s strongest demand signals. We’ll cover tokenized money market funds, intraday repo, and cross-border payments each with the market context and the specific way Cocoon’s capabilities apply.
If you’re an institution evaluating permissioned ledger infrastructure, we’d like to hear from you.