At TACEO, we build privacy infrastructure for public networks. That means we have a commercial interest in this comparison, but more importantly, it means we have to break down these trade-offs for institutional risk officers every week.
Part one: the two questions
You already know how this works
In traditional finance you know exactly who holds your data.
Your custodian sees your holdings, your correspondent bank your payments, the central securities depository the securities, your FX venue your orders. Each is a licensed entity with a contract, a regulator and a legal address you can send a claim to, so confidentiality is not a technical property of the system but a contract term backed by supervision. You also know what it costs: every party keeps its own books, the books disagree, and settlement takes days because the process is a chain of separate ledgers being brought into line.
Blockchains offer a different trade. Instead of every party keeping a private copy that has to be reconciled later, everyone shares one copy that is correct by construction. Reconciliation mostly goes away. Settlement can be atomic: the asset and the payment move together or neither moves.
The catch is in how you get everyone to agree on one copy. The default method is to let everyone see it. On a public chain your transfer is visible to your competitors, your clients, your counterparties and anyone with a web browser. That is not a compliance detail to be handled later. It is your order flow, your counterparty list, your position sizes and your salary bill, published.
So the industry spent the last few years building systems that try to keep the shared copy without the exposure. Three approaches are now in production, and institutions are being asked to pick one:
- Need-to-know ledgers, where each party sees only its own slice. Canton is the mature example.
- Permissioned validiums, where one operator runs a private chain and proves to a public chain that it followed the rules. zkSync Prividium is the clearest example; Tempo Zones take the same shape, though Tempo’s announcement documents no proof system.
- Public chains with a privacy layer, where shared state is encrypted and computation runs over data no participant sees in the clear.
Presented side by side, these can look like three variants of one design. They are not. This is the part that has no equivalent in the traditional setup: in the old world, every guarantee you had was a contract term. In the new world, some guarantees are enforced by mathematics and cannot be broken even by the party running the system. Others are still contract terms, wearing new vocabulary.
Telling the difference between those is what this piece aims to make easier.
Controls or promises
Your risk and audit teams already have the right vocabulary for this, so let us borrow it.
- A control prevents something from happening.
- A promise means somebody has undertaken not to do it, and you would find out afterwards if they did.
Every guarantee any of these systems makes is enforced in one of three ways:
- Cryptography. The violation is infeasible given the cryptographic assumptions. Attempts simply fail. Nobody has to be watching.
- Collateral. The violation is possible but expensive, because someone has staked capital that gets destroyed. This is economics, and it holds as long as what someone stands to gain is worth less than what they stand to lose. It can price a broken promise; it cannot unsee a disclosure.
- Contract and conduct. The violation is possible. Your remedy is legal, regulatory or reputational, and it arrives after the fact.
Only the first is a control. The other two are promises with different amounts of money behind them.
For integrity, an after-the-fact remedy is often good enough. If a balance is wrong you can restate it, unwind the trade, and sue for the loss. Painful, but recoverable.
For confidentiality, an after-the-fact remedy is worth almost nothing. Once your treasury position or your client list has been seen, no court order makes it unseen. You can win the case and still have lost the information forever.
So “we would detect it and they would be liable” is a reasonable backstop for one of these properties and a bad one for the other. Any system that protects your integrity with cryptography and your confidentiality with a policy document has made a choice on your behalf, and it is worth knowing that it did.
There is one more property of promises that deserves attention, because it is easy to miss when the contract is signed. Promises are conditional on the counterparty staying the counterparty you signed with. The firm you trusted can be acquired, and possibly by someone you compete with. It can be breached. It can receive a subpoena. It can become insolvent, or move jurisdiction, or replace the management team that gave you the assurance in the first place. Each of those events can void a promise without any notice to you. None of them affects a control.
None of this is an argument that every guarantee has to be cryptographic. It is an argument that you should know which of yours are, because the distinction is rarely made explicit in product documentation.
Who can see your book
The second question is simpler, and it constrains more of the design than the first.
For any asset on any ledger, something has to be able to tell whether the same unit was spent twice. That takes a complete view of the constraint, every commitment and every spend, though not necessarily a readable one. The three systems are three answers to who gets that view.
- Nobody sees it completely (need-to-know ledgers). Each party holds only its own slice, so the check falls to counterparties entitled to see one. This is Canton.
- One operator sees it (permissioned validiums). It holds the state in the clear and, in Prividium’s case, proves it processed everything correctly.
- Everyone holds it, nobody can read it (public chains with a privacy layer). State is replicated but encrypted or committed, and computation runs over data no participant sees. The newest of the three.
Who holds the complete view also decides what you can compute across parties. In a need-to-know ledger you cannot, because the data is not there. In a validium you can, because the operator sees everything, which re-creates the trusted third party you were trying to remove. Multiparty computation and homomorphic encryption compute over inputs that nobody holds in the clear.
Whichever you pick, do one thing: write down the name of the party who can see your book, and put them on your counterparty risk register. In two of the three cases there is a name to write.
Next, let’s take a look at those three models as we see them in the industry.
Part two: the three models
‘Need-to-know’ ledgers: Canton
What you can do. Settlement, delivery versus payment (the asset and the cash move together or neither moves) and workflows that run across several firms at once, between counterparties you have already onboarded. Because non-parties never receive the data at all, the GDPR position is the strongest of the three: you can honour a deletion request, which a public chain cannot. And because no node stores everything, the system scales horizontally in a way a globally replicated chain does not.
What you cannot do. Build logic over state you are not entitled to see. That rules out a shared order book, pooled liquidity, or any open composition with parties you have not enrolled in advance. It also rules out aggregate questions: nobody can compute the total outstanding exposure in a given asset. If your risk team wants a view across your own activity, they must be granted it position by position.
Who sees your book. The asset issuer, on every single transfer.
A required signatory sees the contract and all its events, and issuers are required signatories on their own assets, so a stablecoin’s issuer sees every payment you make in it. L2BEAT’s USDCx case study shows it in production: every transfer carries Circle’s signature alongside the sender’s and the recipient’s, and the mediator sees the informee tree unblinded, so it learns who transacts with whom. If that issuer is acquired by a competitor, the visibility transfers with it, and nothing in the protocol revokes it.
What you are trusting. Consensus and availability rest on stakeholder nodes rather than validity proofs anchored to an open layer. L2BEAT’s comparison walks the failure modes: a compromised mediator’s verdict is committed and logged rather than rejected, and the roughly forty invited validators carry no protocol-enforced penalty, though Super Validators do lock slashable Amulets. The constraint is institutional, which makes it a promise.
What changes over time. Canton is a network of networks, and activity can split across many synchronizers. As a deep dive on the Flashbots forum puts it, institutions may fragment into semi-interoperable domains, and each split thins the market you joined the network to reach.
How you get out. You do not. The assets exist inside Canton’s infrastructure. There is no unilateral exit.
Permissioned validiums: Tempo Zones and zkSync Prividium
What you can do. More or less everything the existing Ethereum toolchain already does, immediately: composition inside the zone, standard smart contracts, familiar developer hiring. Prividium anchors settlement to Ethereum, so your balances cannot be forged. Zones settle to Tempo mainnet, so the same guarantee rests on Tempo’s security rather than Ethereum’s.
What you cannot do. Keep your activity from the operator, or compose privately outside the zone. Liquidity stays on mainnet rather than fragmenting across zones, so Tempo has you withdraw to mainnet to swap and deposit the result back (see FAQ), and anything reaching beyond one zone relies on bridges, which have cost the industry billions in exploits. Deposits and withdrawals are visible there too.
Who sees your book. The operator, in the clear. Prividium runs a private instance of the chain, sequencer and prover included, inside the organisation’s own infrastructure, with all transaction data and state held offchain in its database. Not a summary, not metadata: initiator, amounts, contract calls, traces. The layer restricting who can query what is an access control system configured by the party it constrains, which makes it a promise.
What you are trusting. In Prividium the integrity guarantee is a control: an invalid state transition fails proof verification, so your balances hold even if the operator turns malicious, gets hacked, or goes bankrupt. Tempo’s Zones announcement describes an operator that builds blocks and confirms transactions, and does not describe a proof system, so check what enforces integrity in the zone you are offered. Everything else is the operator, including confidentiality (its infrastructure, staff, access management and legal exposure), censorship resistance and liveness. Tempo states plainly that a zone operator can suspend a user’s ability to transfer or withdraw under its own compliance rules. Prividium includes a force-inclusion path that lets you push a transaction through the public chain, though L2BEAT notes the operator can disable it with a single toggle (depositsAllowed).
What changes over time. Each zone is composable internally and bridged externally, so the more zones there are, the more of your activity crosses a bridge to reach the rest.
How you get out. On paper, through the settlement chain: Ethereum for Prividium, Tempo mainnet for Zones. In practice, exiting requires a Merkle proof of your balance, which L2BEAT notes is controlled by the operator. That is the data availability problem: withheld data freezes funds while the proofs still verify. An operator who has stopped cooperating is exactly the operator whose cooperation you now need.
Public chains with a privacy layer
The public chain stays the settlement venue, and a privacy layer sits on top of it, computing over inputs that no single node can decrypt. Zama’s confidential payments protocol does this with fully homomorphic encryption and a threshold decryption committee, our own network with multiparty computation.
What you can do. The thing neither of the other models allows: letting several institutions compute over data that none of them reveals to the others. Netting across banks without a central netting agent. Matching without a venue that sees the book. Checking a counterparty limit without disclosing the exposure behind it. You also get public liquidity without a public book, and you can prove things instead of asserting them: selective disclosure to an auditor or supervisor on demand, without a standing window for anyone else.
What you cannot do. Assume nothing leaks: deposits and withdrawals are visible at the edges, and timing and amount patterns can reveal transaction sizes and counterparty relationships even when the contents are sealed.
Who sees your book. Nobody, up to a threshold. No single node holds a readable copy, and reading your book takes collusion above the committee’s threshold, which puts the committee’s composition on the same register as any other counterparty: operators sharing a jurisdiction or a cloud provider are one point of failure, not several. Disclosure has to be designed in deliberately rather than falling out of the architecture.
Compulsion still works, and it should. A committee can be ordered to decrypt; the difference is that the order has to reach enough nodes, in enough jurisdictions, and that the decryption can be made verifiable and the requests counted onchain. An operator holding plaintext complies invisibly. Here, every disclosure is a countable event.
What you are trusting. The correctness of the cryptography and, more often the weak point, its implementation. The threshold assumption of whatever computes over the shared state: an honest-majority committee fails differently from a dishonest-majority protocol, and you should know which you have. If the committee is unavailable, so is your data. And in a multichain design, the bridge contracts.
What changes over time. This is the most technically demanding of the three, and the newest in production. The cryptography has decades of research behind it, but deployments are recent, the tooling is younger still, and proving and secure computation cost latency and hardware that a validium does not. Those improve quickly. The trust assumptions above do not, so those are what to evaluate.
How you get out. The assets sit on a public chain that nobody controls, so exit does not depend on anyone’s permission. It does depend on liveness: a committee that cannot rewire or censor your funds can still stop, which is why these designs need an escape hatch, and why who can open it is worth asking before you rely on one.
Part three: the framework applied
The three models, their controls and promises
First, what enforces each guarantee, which is the part that decides how the choice ages.
That is enforcement. The next table shows what it means for the workloads institutions actually run:
Both tables are a snapshot of 2026. All three of these systems are being actively developed and some of these cells will move.
Part four: our outlook
Where we think this goes
This section is opinion, separated from the analysis above.
Two of these approaches have more adoption behind them, and for some institutions either is the right choice today.
Canton made confidentiality against the infrastructure a control, and left integrity as a promise between known institutions. Prividium made integrity a control anchored in Ethereum, Zones anchor to Tempo instead, and both left confidentiality as an operating policy. Each solved one half. Each asked you to trust the other half to a named party who is trustworthy right now.
Our view is that the half currently held by promise is the half institutions can least afford to lose. Integrity failures are recoverable. Confidentiality failures are permanent, and the events that cause them (acquisitions, breaches, legal process, staff changes) happen on a much shorter timescale than an infrastructure decision. You are being asked to make an infrastructure decision measured in decades on the basis of a promise that a single corporate event can end.
That gap closes with cryptography, and the numbers are concrete: Nethermind reports a shielded transfer proving in about 1.5 seconds on a client and verifying for roughly 301K gas, well under a dollar on L1. Selective disclosure works today, which answers the objection that private means unregulated. Asset-level controls inside a privacy domain, freezing and clawback among them, are in their own words non-trivial and need careful architectural design. They put the requirement this way:
Anonymity without control is not an institutional solution. Regulated entities need compliance mechanisms such as selective disclosure, access control, and asset-level governance.
Nethermind, Institutional privacy on public blockchains
We agree, and all three of those mechanisms can be built cryptographically. What institutions need is confidentiality with control, and that is what the third model aims at.
We are not going to tell you which system wins. We will make a narrower claim: of the trade-offs on the table, the one that ages worst is trusting somebody to keep your book confidential because they promised to.
Sources
- Canton Network, Privacy Model Explained
- ethereum.org, Validium
- Flashbots Collective, Deep dive on permissioned blockchains: the Canton Network
- L2BEAT, Canton vs Prividium: What Institutional Blockchains Actually Guarantee
- Nethermind, Institutional privacy on public blockchains: technical foundations, challenges, and the path to adoption
- TACEO, The TACEO Network is Live
- Tempo, Introducing Tempo Zones
- The Block, Tempo unveils Zones
- Zama, Introducing the fhEVM Coprocessor
- ZKsync, Prividium architecture
