Canton started a battle

Foreword

What happens when a company shifts from defense to offense, changes its stance, and refines its rhetoric?

We know this because Microsoft has claimed for years that it has no hostility towards Linux. Yet, it has begun appearing at government procurement meetings, giving security briefings, and explaining why open-source software poses a threat to national infrastructure. Google also claimed to publishers that it had been simply compiling information for a decade. Yet, it began funding research that found paywalls to the news to be harmful to democracy. The former "we built something different" has become "what they built is dangerous." If you are good enough and have the right connections, you don't even need to win on the technical level. You just need to make sure that the people who ultimately decide the direction of technology are those who trust you more than your competitors.

Canton is doing this now. And the cryptocurrency industry has been largely excluded from the discussion.

In January of this year, I pointed out that Canton chose efficiency over freedom, and institutions chose Canton as well. The argument at the time was that Canton and Ethereum targeted different audiences and solved different problems. This argument was correct at the time. However, since then, Canton's direction has changed. Canton's founders have been explaining to buyers and regulators in public and closed-door meetings that zero-knowledge proofs (ZKP) pose an unacceptable risk to mission-critical financial systems. I believe this is a regulatory stance advocacy campaign running concurrently with a fundraising event that attracted major investors such as Goldman Sachs, Citadel, DRW, Circle, Paxos, and Polychain. JPM Coin launched on Canton in January. Visa joined as a super validator in March. On March 27, LayerZero became the first interoperability protocol to run directly on Canton, enabling institutions to route tokenized assets across more than 165 public blockchains. The fully diluted value of the $CC token is $5 billion.

These aren't the main points. What I want to talk about is how Canton is now trying to dictate the range of technologies banks can use. So far, only Canton has been discussing this.

Arguments against ZK

Canton's arguments are roughly as follows: Zero-knowledge proof vulnerabilities can be difficult to detect because the underlying data is private. If such vulnerabilities spread silently, without audit trails or accountability mechanisms, they can be fatal flaws.

They point to a real-world example.

On April 16, 2025, Solana patched a zero-day vulnerability in its "Confidential Transfers" feature based on zero-knowledge proofs (ZKP). This vulnerability could have allowed attackers to mint an unlimited number of tokens. It is currently unclear whether this vulnerability has been exploited. The person who made this argument is Shaul Kfir, co-founder and COO of Canton, who is also a co-author of libsnark, a C++ library for creating zk-SNARK proofs. Is he dismissing a technology he doesn't understand? Unlikely. His argument is that when zero-knowledge proofs fail, no one will notice. Data remains private, errors are hidden, and by the time someone notices the problem, the damage has already spread. For regulators, their responsibility is to prove that banks aren't laundering money, so a system that "trusts math" is unsatisfactory. They need to see the records. In Canton's model, the only entities that can see these records in real time are the super-validators—the same institutions that would become the single point of failure if their keys were compromised. This argument doesn't need to be flawless to be effective. It just needs to sound plausible to appeal to those already skeptical of cryptocurrencies. For those who have built their careers on paper records and audit logs, the evidence becomes worthless in the event of a serious vulnerability in cryptocurrency. You don't need to win the technical debate, but you still need to make the other side feel that the alternative is too risky. Where does the problem lie? ZKsync co-founder Alex Gluchowski publicly responded to this view last week. He stated that Canton's logic is too extreme. If a technology has vulnerabilities that could have catastrophic consequences, then we should never use it. Following this logic, we should have grounded all commercial flights and stopped building any aircraft back in the 1970s. Fly-by-wire systems have vulnerabilities, engine controllers have vulnerabilities, and autopilot software has experienced malfunctions that have resulted in injuries and fatalities. But we haven't stopped flying. The aircraft we build are equipped with multiple independent systems so that when one system fails, another can detect and fix it in time, preventing crashes. Does Canton answer what happens after an operator's keys are leaked? Currently, there is no backup system or second layer of security to check for leaks. Trusted operators are the only line of defense. If this defense fails, damage can spread silently throughout the network, unchecked. By Canton's own standards, this architecture is what should truly concern regulatory agencies. The solution to technological flaws is never to find an absolutely reliable technology, but to build systems that can anticipate failures and ultimately survive. The safety of a nuclear reactor does not stem from its software never crashing, but from the fact that if one component fails, five other components must fail simultaneously for a disaster to occur. The same applies to pacemakers and commercial aircraft. Their engineering principles lie in redundancy and isolation. Multiple independent system layers are built to ensure that if one layer fails, another can compensate in time. Simultaneously, the system design should ensure that, in the event of a failure, the damage can be contained within the system and not spread to all connected components.

Grukhowski also conducted the same tests on Canton's own architecture. Canton's privacy and integrity model relies on a single mechanism: a trusted operator isolates data among participants. This model lacks a cryptographic verification layer or independent inspection mechanism. If the operator's key is leaked, the tampered state will silently propagate through the opaque UTXO chain without any monitoring. According to Canton's own logic (a single point of failure with unimaginable consequences), this is the architecture that regulators should be concerned about.

ZK vulnerabilities and Solana zero-day vulnerabilities are real problems. But measures to address fault-prone components should not replace them with another single point of failure disguised as an institution.

ZK vulnerabilities and Solana zero-day vulnerabilities are real problems. But measures to address fault-prone components should not replace them with another single point of failure disguised as an institution.