robik (∎, ∆) zk/acc

Are you in the $ZK or the $CC camp?

Canton founders claim ZK proofs are too risky for institutional finance. They have been making this argument to buyers and regulators, publicly and behind closed doors. It deserves a public answer. Let's see if the argument holds — and if Canton's infrastructure passes its own test. The argument Their case, stated fairly: ZKPs are complex. Bugs are inevitable in any sufficiently complex system. If a flaw exists in a proof system, it could go undetected because the underlying data is private. If it goes undetected, it spreads throughout the system. This creates systemic risk. Therefore, ZKPs cannot be used for critical financial infrastructure. This is a real concern. Let's take it seriously and follow the logic. The flaw in the logic Strip away the ZKP-specific language, here's the story: Technology X can have implementation flaws. Technology X serves a mission-critical function. If it fails, the consequences are catastrophic. Therefore, Technology X can never be used. Read it again. There is a hidden assumption doing all the work: that Technology X is your only line of defense. If this logic held, we would not have aviation. Fly-by-wire, engine controllers, autopilot — every one of these systems has bugs, is mission-critical, and can fail catastrophically. Nuclear reactor control systems, robotic surgery, radiation therapy dosing, implantable cardiac devices, and many other systems all run on software that can fail catastrophically. But they are somehow still in use. How? Redundancy and containment The foundation for these mission-critical systems is the explicit assumption in their architectures that every component will eventually fail. They all rely on two things: redundancy and containment. Redundancy = multiple independent systems, each capable of catching a failure in the others. Containment = when failure occurs, limit the blast radius so it cannot become systemic. This is the only question that matters for any mission-critical system: does your architecture have more than one line of defense? Canton's architecture Let's apply this test to Canton. Canton's privacy and integrity model relies on a single mechanism: trusted operators segregating data between participants. There is no cryptographic verification layer and no independent check. If a few keys of the operators in a validation domain are compromised, manipulated state propagates silently inside opaque chains of UTXOs with nothing watching. This is a real systemic risk, accelerated by the rise of AI-assisted cyberattacks. By Canton's own logic — a single point of failure with catastrophic consequences — this is the architecture that should concern regulators. Prividium's architecture Now look at how Prividium is built. Redundancy. Prividium has three independent lines of defense. First, institutional partners operate Prividium nodes within their own security environments, the same infrastructure banks already trust and regulate. Second, zero-knowledge proofs provide cryptographic integrity verification as an independent layer on top, verifying operational security rather than replacing it. Third, as ZK proof systems standardize, multiple independent provers can verify the same computation. A flaw in one implementation gets caught by another. Containment. Each Prividium instance is an individual chain operated by an individual institution. When institutions interact across chains, Prividium's interop layer implements inter-chain accounting mechanisms that are independently enforced by the participating institutions, asset issuers, or on-chain. Even an attacker who compromises a single institution's internal IT infrastructure and simultaneously finds a ZKP bug could only affect that one Prividium instance. The damage cannot propagate to the broader network. The net balance: Canton has a single mechanism, no fallback, silent failure propagation across the network. Prividium has layered defenses, independent verification, blast radius contained by design. Importance of open standards Multiple lines of defense only matter if each line is itself strong. What makes a technology strong? The depth of adversarial testing it has survived. Shaul points to a compiler bug example in his post, and it actually illustrates this well. ZKsync embraced full EVM equivalence over a year ago. This was shaped precisely by the understanding that the more you deviate from an open standard, the larger your attack surface becomes. And Ethereum is not battle-tested in some polite, academic sense. For over a decade, its smart contract infrastructure has been completely open to scrutiny by the most sophisticated adversarial actors in the world, with hundreds of billions of dollars at stake. Vulnerabilities and exploits fed directly back into the ecosystem: new audit standards, formal verification tools, compiler safeguards, and hardened design patterns. The EVM that exists today is the product of a decade of continuous adversarial stress testing at a scale no other smart contract platform has experienced. Canton went the opposite direction. DAML is a proprietary smart contract language with a closed ecosystem and a fraction of the developer and security community. Every growing pain that Ethereum went through over the last ten years still lies ahead for DAML, except DAML will face them with orders of magnitude fewer eyes watching. Every maturity concern Canton raises about ZKPs applies to their own technology stack with far less mitigation available. The safest technology is the one that has survived the longest under the harshest conditions. For smart contract infrastructure, that is Ethereum. It's not close. So to answer the question directly: everyone agrees bugs exist. The question is whether your architecture has redundancy to catch them and containment to limit the damage when they slip through. Cryptographic verification provides both. Trust in operators provides neither.

Yuval is trying to manufacture a gotcha, so let me set the record straight: If you deploy a smart contract on Ethereum, you have FULL CONTROL over how that contract will behave. Same if you deploy your own L2 or a Prividium instance: you determine the rules of that environment completely. This is exactly why banks and institutions are comfortable building on public chains. But any real smart contract limits the ability of transacting parties to exert control over the assets inside it. That's the entire point. You set the rules upfront, enforced by code in real time — not by contractual promises that take years and millions of dollars to litigate. This is what makes blockchains a genuine upgrade over legacy financial infrastructure. Would an issuer ever want to limit their own control? Of course! Issuers do it every day. Anti-dilution protections, debt covenants, dividend waterfalls — these are all promises issuers make to investors that say "I won't do X." Today those promises are enforced by lawyers. Smart contracts can enforce them by math. So the real question every institution should ask their blockchain provider: can your platform actually enforce this logic, or does the issuer always retain root access to the asset? Canton requires issuers to retain full administrative control, which fundamentally undermines the network's ability to protect transacting parties. On Ethereum, enforcement is guaranteed by math and open-source code. Canton calls that a feature, but every investor on the other side of the trade should call it a risk.

1/ How L1 and L2s can build the strongest possible Ethereum tldr: we should continue to lean into the unique capabilities of each layer, and make sure all users have a clear path to securely and seamlessly benefit from the core properties of Ethereum