The blockchain landscape has split more sharply than most architects acknowledge. The EVM ecosystem—Ethereum and its compatible chains—runs on a shared global state machine that anyone can read, write to, and build on without permission. Canton, built atop Digital Asset’s Daml smart contract language, was designed around privacy, legal enforceability, and the operating constraints of regulated financial institutions. These two systems answer different questions. Comparing them as if they were racing toward the same finish line misses the point.
Getting the comparison right means tracing each system back to the assumptions its architects made: what they decided the ledger was for, who they imagined would use it, and which failure modes kept them up at night.
The philosophy gap
EVM: the transparent world computer
Ethereum’s original thesis was a globally shared, permissionless, censorship-resistant computer where anyone could deploy code and anyone could inspect the results. The EVM treats the blockchain as a single replicated state machine. Every full node maintains a complete copy of the global state trie. Every transaction that mutates that state must be executed by every validator. Transparency isn’t incidental—it’s load-bearing. The security model depends on everyone being able to verify everything.
This philosophy produced a remarkably active software ecosystem. Uniswap, Aave, MakerDAO, and thousands of other protocols exist because deploying to Ethereum requires no permission, no legal agreement, and no institutional relationship. The EVM’s Turing-completeness and open composability made DeFi possible. It also made privacy structurally impossible at the base layer.
Canton: the confidential sub-transaction network
Canton starts from a different premise: for most institutional financial workflows—securities settlement, syndicated lending, FX netting, derivative clearing—selective disclosure is a regulatory and commercial requirement, not a preference. A bond issuer cannot expose its complete order book to every network participant. A bank cannot share the details of a bilateral derivative with counterparties who have no relationship to that trade.
Digital Asset’s response was to abandon the shared global state model. In Canton, there is no global ledger that all participants maintain. Each piece of data—each “contract” in Daml parlance—is known only to the parties explicitly named in it. The ledger is not a database everyone reads; it is a collection of private sub-ledgers whose consistency is guaranteed by cryptographic proofs and a synchronization protocol between domain operators and participants. The network does not achieve consensus on a single world-state. It achieves consensus on the sub-set of state that each participant is entitled to see, and those sub-ledgers are kept consistent by a protocol that guarantees global coherence without global visibility.
That architectural choice has consequences for execution, privacy, scalability, and trust throughout the stack.
Execution models
The EVM execution environment within each block. When a transaction is submitted, it specifies a target contract address, a function selector, encoded arguments, and a gas limit. The EVM—an isolated stack machine with 256-bit word sizes—executes the bytecode at that address, potentially making inter-contract calls (CALL, DELEGATECALL, STATICCALL), reading from and writing to a key-value storage trie associated with the contract’s address. All state reads and writes are visible to any observer with access to an archive node.
Gas is the metering mechanism. Every EVM opcode has a fixed gas cost; the sum must not exceed the block gas limit. This prevents infinite loops and creates a fee market, but it also means that complex smart contracts must be carefully optimized to avoid exceeding per-transaction gas bounds. The EVM has no native support for off-chain computation or private inputs—any data written to a contract is public.
Solidity and Vyper compile to EVM bytecode. The ABI encoding scheme is standardized, enabling composability across contracts: Uniswap can call Chainlink, which can call Aave, and the entire multi-protocol transaction either atomically succeeds or atomically reverts. This atomicity across the global state is one of the EVM’s most powerful features. It is also what makes truly private computation so difficult—atomic cross-contract calls only work if both contracts share the same execution context, which requires visibility.
Layer 2 systems—Optimistic Rollups like Arbitrum and Optimism, ZK-Rollups like zkSync and StarkNet—modify this model by batching EVM transactions off-chain and posting compressed results (with fraud proofs or validity proofs) to Ethereum mainnet. But the execution semantics within an L2 remain EVM-compatible: the global state model, the bytecode interpreter, and the transparency assumptions all carry over. L2s improve throughput and reduce fees; they do not change who can see what.
The Canton/Daml execution environment
Canton’s execution model is built around the concept of a contract—not in the Ethereum sense of “code living at an address,” but in the legal-contract sense: a data structure representing an agreement between named parties, along with a set of permissible actions (choices) that those parties can exercise. Daml contracts have explicit signatories (parties whose authority created the contract), observers (parties who can see the contract), and controllers (parties who can exercise specific choices).
When a Daml choice is exercised, the transaction is represented as a transaction tree: a hierarchical structure of create, exercise, and archive actions. This tree is decomposed before being submitted to the network. Each node in the tree is disclosed only to the participants who need to see it—the parties to the contracts involved in that node. The Canton protocol routes these fragments to the appropriate domain nodes, which validate the sub-transactions they are responsible for without seeing the sub-transactions that belong to other parties.
The result is sub-transaction privacy: in a multi-step workflow involving Party A, Party B, and Party C, Party A does not automatically learn the details of the step that occurs only between Party B and Party C, even if that step is part of the same atomic transaction. This is architecturally unavailable in the EVM without a separate off-chain computation layer and cryptographic proofs (as ZK co-processors like Risc Zero attempt to provide).
Canton validators—called domain nodes or sequencers—process these transactions through a BFT-based ordering layer. The sequencer timestamps and orders messages, but it does not see the content of private contract data. Participant nodes validate the transactions they are party to, apply them to their local contract state, and maintain only the slice of the global ledger that belongs to them.
One operational distinction worth noting: Canton transactions reference specific contract instances by their unique contract ID, not by a globally shared storage slot. This means Canton’s execution model resembles a UTXO model more than an account model—contracts are created, referenced by subsequent transactions, and eventually archived. There is no mutable global key-value store that all participants read from and write to. This has significant implications for concurrency, addressed in the scalability section.
Privacy guarantees
EVM chains: pseudo-anonymity at best
On Ethereum mainnet, all transaction data—sender address, target address, input data, event logs, state diffs—is permanently public and indexed by the global state. The pseudo-anonymity of addresses is meaningful only before an address is linked to a real-world identity, and the on-chain transaction graph is often enough to deanonymize sophisticated actors. Chain analytics firms like Chainalysis and Elliptic trace address clusters and transaction patterns as a commercial service.
Privacy-preserving techniques in the EVM ecosystem include:
Tornado Cash / mixers — pool deposits from multiple senders and allow withdrawals from new addresses, breaking on-chain linkability. OFAC sanctioned Tornado Cash in 2022 and arrested its developer in 2023, which should give pause to anyone treating “censorship resistant” as an unconditional property. The approach also provides no privacy for the content of transactions, only the sender’s identity.
Commit-reveal schemes — parties commit to a hash of their data on-chain, then reveal later. Useful for auctions and voting, but still exposes final values and does not suit ongoing confidential relationships.
FHE / TEEs — emerging approaches from protocols like Fhenix (FHE) and Oasis Network (TEEs) that allow computation on encrypted data. Promising but currently impractical for complex financial logic at scale due to computational overhead (FHE) or hardware trust assumptions (TEEs).
ZK co-processors — Aztec Network is building a private smart contract layer using ZK proofs, where the EVM bytecode is compiled to a circuit and the proof attests to correct execution without revealing inputs. Technically sound but still nascent, with significant developer experience friction and proving time overhead.
None of these approaches is native to the EVM itself. They are layers applied on top of a transparent system.
Canton: privacy by construction
Canton’s privacy model is built into the transaction model rather than layered over it. The key mechanisms:
Party-level privacy — a contract’s data is stored only on the participant nodes of the parties explicitly named in the contract. The domain node (sequencer) sees encrypted metadata necessary for ordering but not the contract payload itself.
Sub-transaction privacy — as described above, different legs of a multi-leg transaction can be disclosed to different subsets of parties. A CCP (central counterparty) might see only the net obligations between parties, not the gross bilateral trades that produced them.
Divulgence — Canton supports a mechanism by which a party can be shown a contract’s data (for verification purposes) without being made a signatory or observer. This allows auditors or compliance nodes to be granted read access to specific contracts without becoming participants in the workflow itself.
Cryptographic verification — participants validate transactions cryptographically, checking that exercises on contracts are authorized by the correct parties and that the transaction tree is internally consistent, without needing to see contracts held by other parties. This uses Merkle proofs and commitment schemes embedded in the Canton protocol.
Concretely: a Canton deployment at a bank consortium can have participant A and participant B transact with each other, with participant C serving as a domain operator, without participant C learning the economic terms of A and B’s trade. On any EVM chain, this requires additional cryptographic machinery that does not yet exist at production scale for complex financial contracts.
The tradeoff: Canton’s privacy model makes global verifiability hard. A third party who is not a named participant in a contract cannot verify its contents—which is exactly the point, but it means Canton cannot support the permissionless “anyone can verify” security model that Ethereum depends on.
Trust assumptions
EVM trust model: cryptoeconomic security
Ethereum mainnet’s security derives from Proof of Stake consensus among a permissionless validator set. As of mid-2025, roughly 1 million validators have staked ETH to participate. A 51% attack requires controlling ~33% of stake for finality attacks or ~51% for safety violations—economically prohibitive at current ETH valuations, though the theoretical risk exists. The trust assumption is cryptoeconomic: rational actors will not attack the network because slashing destroys their stake.
EVM smart contracts are trustless in a specific sense: once deployed, they execute deterministically according to their bytecode, with no ability for the deployer to unilaterally modify behavior (unless the contract contains upgrade mechanisms). This “code is law” property works well in permissionless contexts but creates problems in enterprise settings where regulatory requirements may necessitate reversibility.
EVM-compatible L1s and L2s vary significantly in their trust assumptions. BNB Chain has 21 active validators—effectively a federated system controlled by Binance-aligned entities. Polygon PoS has roughly 100 validators. Arbitrum’s sequencer is currently a single operator (Offchain Labs) with a planned transition to a decentralized sequencer set. These are not Ethereum’s security model; they are pragmatic compromises that institutional buyers should understand clearly.
Canton trust model: legal and cryptographic hybrid
Canton’s trust model is explicitly hybrid. It relies on:
Cryptographic correctness — transaction validity is enforced by the Daml runtime and Canton protocol. Participants cryptographically verify that exercises on contracts are authorized by the correct parties, that contract invariants hold, and that the transaction tree is internally consistent. This is deterministic, not probabilistic.
Domain operator trust — the domain node (sequencer) is trusted for liveness and ordering but not for data confidentiality or correctness. A malicious domain operator can deny service but cannot forge transactions or read private contract data it is not party to. This is a narrower trust assumption than Ethereum’s full validator trust model for individual transactions, but it does rely on the domain operator being available and non-censoring.
Legal enforceability — Daml was explicitly designed so that a smart contract can be a direct expression of a legal agreement. The signatories on a Daml contract have the same semantics as signatories on a legal document. Digital Asset has structured the system so that disputes can be adjudicated in traditional legal frameworks, with the ledger serving as an auditable record. This maps to how institutional counterparties actually think about agreements.
Synchronized sub-ledger consistency — the Canton protocol guarantees that if two participants hold contracts on different domains, a transaction that spans both domains is executed atomically or not at all. This is guaranteed by a cryptographic commitment scheme, not by a single global validator set. The trust assumption here is that each domain’s operator is honest about the commits it acknowledges—a weaker assumption than “every validator is honest,” but one that participants must evaluate carefully.
Canton is better suited to environments where participants are identified legal entities that can be held accountable, where regulators require auditability but not public transparency, and where the realistic attack scenario is a rogue insider rather than an anonymous economic attacker.
Scalability
EVM scalability: the scaling stack
Ethereum mainnet currently processes roughly 15–30 transactions per second, bounded by block gas limits and 12-second block times. This is deliberately conservative—Ethereum prioritizes decentralization and security over throughput. The roadmap—Proto-Danksharding (EIP-4844), Danksharding, and eventually full sharding—is designed to increase data availability bandwidth by orders of magnitude, enabling L2 rollups to post far more transaction data at lower cost.
The rollup ecosystem is Ethereum’s primary scaling answer. Arbitrum One handles roughly 10–40 TPS at network load, with theoretical capacity much higher. ZK-Rollups like zkSync Era process similar volumes with faster finality guarantees. For most DeFi applications this is workable. For institutional transaction volumes—DTCC processes roughly 120 million transactions per day, Visa handles ~24,000 TPS at peak—it is not sufficient without multiple parallel rollups and off-chain aggregation.
EVM chains scale horizontally only at the cost of fragmentation: a transaction on Arbitrum and a transaction on Base are not atomic with each other. Cross-chain atomic transactions require bridges, which are a persistent source of security risk—hundreds of millions of dollars have been lost to bridge exploits.
The EVM’s sequential execution model creates a bottleneck within a domain: transactions touching the same state must be serialized. Parallel EVM initiatives (Monad, Sei) are attempting to execute non-conflicting transactions simultaneously using optimistic concurrency control, but this requires sophisticated conflict detection and remains in early production stages.
Canton scalability: horizontal parallelism by design
Canton’s scalability works differently. Because the ledger is partitioned by contract—each contract exists on one or more domain nodes, and transactions reference specific contract IDs—transactions on different contracts can be processed in parallel without conflict detection overhead. There is no global state trie creating write contention.
Adding a new domain node effectively adds a new parallel track for transactions on those contracts. The network scales horizontally: throughput is proportional to the number of domain nodes, and these domains operate in parallel without coordinating on every transaction. Cross-domain transactions require a synchronization round (similar to a two-phase commit), which adds latency but maintains atomicity guarantees.
Digital Asset has published benchmarks showing Canton participant nodes handling thousands of transactions per second per domain. Total network throughput across all domains can scale to enterprise volumes without the global sequencing bottleneck that constrains EVM chains.
The tradeoff: Canton’s scalability is bounded by the permissioned participant set. Adding throughput requires adding identified, credentialed domain nodes—not simply spinning up anonymous validators. For institutional deployments this is acceptable; for permissionless public networks it is not.
One nuance: Canton’s horizontal scaling comes with a composability cost. In the EVM, any contract can call any other contract atomically because they share a global state. In Canton, cross-domain atomic transactions are supported but require coordination between domain operators. Two contracts on the same domain can transact with minimal overhead; two contracts on different domains require the synchronization protocol, which adds round-trip latency. This is manageable in institutional workflows where transaction graphs are pre-defined, but it imposes a design discipline that EVM developers do not face.
Decentralization
This is perhaps where the two systems’ philosophies are most nakedly at odds.
EVM: permissionless decentralization as a core value
Ethereum’s validator set is permissionless—anyone with 32 ETH can become a validator. The client diversity across Prysm, Lighthouse, Teku, Nimbus, and Lodestar reduces the risk of a single software bug taking down the network. Contracts can be deployed by any address, called by any address, and their state can be read by any node.
This permissionlessness is what makes Ethereum genuinely censorship-resistant. Post-Merge, Ethereum has shown resilience against validator-level censorship through MEV-Boost and OFAC compliance debates—the network continues to include non-OFAC-compliant transactions, albeit with some validator-level filtering. No single entity can prevent a transaction from eventually being included.
EVM L2s sacrifice degrees of decentralization for performance. Arbitrum’s sequencer is centralized today. Base is operated by Coinbase. zkSync’s prover infrastructure is controlled by Matter Labs. These are pragmatic choices that meaningfully change the trust model—participants in these systems are trusting specific companies, not a decentralized validator set.
Canton: deliberate permissioning
Canton makes no pretense of permissionless participation. Domain operators are known, credentialed entities; participants are identified counterparties who have completed onboarding and legal agreements. This is the design intent, not a concession to operational convenience.
The Global Synchronizer (built on Besu-based BFT consensus in the Canton Coin network) provides a decentralized ordering layer for the Canton Network as a whole, with a defined validator set. But “decentralized” here means “decentralized among identified financial institutions and infrastructure providers,” not “open to anonymous stakers.” The governance model involves vetted super-validators that are accountable entities under legal frameworks.
For engineers evaluating Canton for enterprise use, this permissioned model offers meaningful operational guarantees: validators are subject to SLAs, can be held legally accountable for misbehavior, and operate under regulatory supervision. The cryptoeconomic slashing mechanism of Ethereum—designed to align anonymous validators’ incentives—is less relevant when the validator set consists of Goldman Sachs, Citi, and Deutsche Bank. Legal accountability replaces cryptoeconomic incentives as the enforcement mechanism.
The consequence: Canton cannot offer censorship resistance to participants who lack standing in the legal jurisdictions governing the network. A transaction can be blocked by a domain operator acting under regulatory authority. For financial markets, this is a feature—regulators should be able to freeze assets in court-ordered scenarios. For applications requiring censorship resistance, it is disqualifying.
Enterprise suitability
What enterprises actually need
Regulated financial institutions face requirements the EVM was not designed to satisfy:
KYC/AML compliance — counterparty identity must be verified before transacting. The EVM’s pseudonymous address model does not natively support this; it must be layered on through identity registries (ENS, ERC-725) or off-chain attestation (Verifiable Credentials).
Regulatory auditability — regulators may need to see transaction details that counterparties do not. Canton’s divulgence mechanism handles this natively. On EVM chains, everything is already public—but this creates data privacy problems under GDPR and similar frameworks for private data.
Settlement finality — Ethereum provides probabilistic finality (effectively final after ~64 blocks, roughly 13 minutes), though Casper FFG now provides one-slot finality under certain conditions. Most institutional applications require deterministic finality for settlement accounting. Canton’s domain sequencer provides deterministic finality within a domain upon ordering.
Reversibility and legal override — Daml’s design allows authorized parties (regulators, courts) to archive contracts and create replacement contracts reflecting a corrected state. This is incompatible with EVM’s “code is law” philosophy but essential for environments where courts can order asset freezes or trade corrections.
Operational recovery — if a Canton participant’s node goes offline, only that participant’s ability to transact is affected. Other participants continue operating. If an EVM L2 sequencer goes offline, the entire L2 halts—as Arbitrum’s sequencer outage in 2023 demonstrated.
Canton addresses all of these requirements by design. EVM chains address some through workarounds, and fail structurally on others.
Where the EVM enterprise story works
The EVM ecosystem is not irrelevant for enterprise. For public settlement layers—tokenized assets that need to be traded on open markets, cross-institution liquidity pools, or public reference prices—Ethereum’s transparency is the point. An institutional tokenized money market fund issued on Ethereum can be inspected by any market participant, facilitating price discovery and enabling composability with DeFi protocols. BlackRock’s BUIDL fund, tokenized on Ethereum, illustrates this: transparency builds market confidence.
Enterprise Ethereum Alliance members and frameworks like Quorum (a permissioned Ethereum fork) attempt to bridge the gap by adding privacy layers (Tessera private transactions, Orion) to EVM chains, but these solutions are technically complex, reduce composability, and still expose transaction graph metadata.
DeFi suitability
EVM DeFi: the benchmark
DeFi, as it exists, is an EVM phenomenon. The combination of permissionless access, global state atomicity, composability, and token standards (ERC-20, ERC-721, ERC-4626) has produced a self-reinforcing ecosystem with over $100 billion in TVL at its peak. Automated market makers, lending protocols, yield aggregators, perpetual futures, and structured products have been built and iterated at a pace no permissioned system can match.
The EVM’s suitability for DeFi rests on properties Canton cannot replicate:
Permissionless composability — any protocol can integrate with any other without coordination. Flash loans exist because anyone can atomically borrow, use, and repay within a single transaction.
Open liquidity — AMM pools aggregate liquidity from anonymous market makers globally. Price discovery is continuous and transparent.
Censorship resistance — protocols like Uniswap cannot be shut down by a single legal entity, which is what makes them useful as neutral infrastructure.
Canton can support some DeFi-like functionality—Digital Asset has demonstrated atomic swap workflows, repo markets, and CLO waterfall calculations in Daml—but these require identified counterparties, cannot benefit from anonymous liquidity provision, and sacrifice the composability that makes DeFi powerful.
Canton’s financial market infrastructure angle
Where Canton excels is in the post-trade workflow that DeFi has so far ignored: settlement, custody, collateral management, margin calls, corporate actions, and fund administration. These are multi-party, multi-step workflows where privacy, legal identity, and regulatory oversight are prerequisites, not obstacles. DTCC’s Project Whitney (exploring Daml for post-trade) and ASX’s CHESS replacement both targeted this space.
A word on ASX: the project was ultimately shelved—not because Daml was technically inadequate, but because organizational change management at an entrenched infrastructure provider proved more difficult than the technology. Canton has advanced significantly since then, but the lesson about institutional adoption friction is worth keeping in mind.
Comparative summary
| Dimension | Ethereum Mainnet | EVM L2s (Arbitrum, zkSync) | Canton Network |
|---|---|---|---|
| Execution model | Global shared state, sequential | Global shared state, sequential (within L2) | Sub-ledger, contract-scoped parallelism |
| Privacy | Fully transparent | Fully transparent (within L2) | Sub-transaction privacy by construction |
| Smart contract language | Solidity/Vyper → EVM bytecode | Solidity/Vyper → EVM bytecode | Daml → Canton protocol |
| Finality | ~12 min (probabilistic → near-deterministic) | Minutes (optimistic) / seconds (ZK) | Deterministic, per-domain |
| Throughput | ~15–30 TPS | ~1,000–10,000 TPS (theoretical) | Thousands TPS per domain, horizontally scalable |
| Decentralization | Permissionless, ~1M validators | Semi-permissioned (sequencer centralization) | Permissioned, identified participants |
| Censorship resistance | High | Medium | Low (by design) |
| KYC/AML integration | External, fragile | External, fragile | Native, identity-first |
| Regulatory compliance | Requires workarounds | Requires workarounds | Core design goal |
| Composability | Global, permissionless | Within L2; bridges for cross-L2 | Within domain (atomic); cross-domain (synchronized) |
| Legal enforceability | Code is law | Code is law | Daml = legal agreement |
| Developer ecosystem | Massive, mature | Large, growing | Smaller, institutional-focused |
| Reversibility | Immutable by default | Immutable by default | Authorized reversal supported |
| Ideal use case | DeFi, public tokenization, open markets | DeFi with lower fees, gaming, consumer apps | Post-trade settlement, bilateral markets, regulated FMI |
| Trust model | Cryptoeconomic (anonymous validators) | Operator + cryptoeconomic hybrid | Legal accountability + cryptographic verification |
Where Canton wins
1. Bilateral and multi-lateral financial contracts requiring confidentiality
A credit default swap between two banks should not be visible to other market participants. In Canton, the economic terms are known only to the counterparties and any designated observer (e.g., a reporting repository). On any EVM chain, this is impossible without a ZK layer that does not yet exist at production scale for complex financial contracts.
2. Regulatory compliance in jurisdictions with strict data privacy requirements
GDPR Article 17 (right to erasure) is irreconcilable with Ethereum’s immutable public ledger. A Canton deployment can design data flows such that personally identifiable information never touches a shared ledger—it lives on the participant’s local node. The shared ledger holds only hashed references and cryptographic commitments.
3. Post-trade workflows requiring deterministic finality and legal override
Trade corrections, failed settlement remediation, corporate action processing, and regulatory seizure orders all require the ability to modify or reverse a record under defined legal authority. Daml supports this through the authorized archival and recreation of contracts. Smart contracts on EVM chains have no equivalent mechanism without privileged admin keys—which reintroduce centralization and are operationally fraught.
4. Institutional collateral management
Collateral moves between custodians, prime brokers, and CCPs throughout a trading day. These moves involve multiple legal entities, are subject to regulatory oversight, and require atomic execution (collateral should not be in transit with no owner for any period). Canton’s atomic cross-domain transaction capability, combined with its identity model, maps cleanly to this workflow. EVM bridges—the closest analogue—have lost hundreds of millions of dollars to security exploits and cannot provide the legal identity guarantees required.
5. Enterprises requiring auditability without transparency
A fund administrator may need to prove to regulators that all NAV calculations were performed correctly, without exposing investor allocations to competitors. Canton’s divulgence mechanism allows a designated auditor node to inspect specific contract lineages without being a party to the ongoing relationship. On Ethereum, the auditor either sees everything (public chain) or nothing (encrypted private data).
Where EVM chains win
1. Open, permissionless markets
Any application that benefits from anonymous, global liquidity provision—decentralized exchanges, lending pools, yield aggregators—requires permissionless participation. Canton’s identity requirements make this impossible. If the goal is a market where anyone with an internet connection can provide or consume liquidity, EVM chains are the only realistic option today.
2. Token issuance for public secondary markets
A tokenized equity that needs to trade on a public DEX, be held in MetaMask, and be listed on Coinbase must live on a public EVM chain. Canton’s permissioned model does not connect natively to these distribution channels. Institutional issuers who want both primary market compliance (using Canton for issuance and settlement) and secondary market access (using Ethereum for trading) must bridge between the two systems—adding complexity and risk.
3. Developer velocity and ecosystem maturity
Ethereum’s Solidity developer pool numbers in the hundreds of thousands. The tooling—Hardhat, Foundry, Tenderly, OpenZeppelin—is deep and battle-tested. Daml has a steeper learning curve, a smaller developer community, and fewer open-source libraries. For teams that need to ship quickly, iterate based on user feedback, and hire from a large talent pool, the EVM is the pragmatic choice. This is an underrated consideration: the productivity difference between having thousands of answered Stack Overflow questions versus having to read source code is real.
4. Composability-dependent applications
Flash loans, liquidation bots, MEV strategies, and complex multi-protocol yield strategies all depend on global state atomicity across arbitrary contracts. A flash loan that borrows from Aave, arbitrages Uniswap, and repays within a single transaction is only possible because all three protocols share the same EVM state. Canton’s domain-partitioned model does not support this kind of arbitrary cross-contract composition without pre-coordination.
5. Consumer applications and NFT markets
Consumer-facing applications—NFT marketplaces, gaming, loyalty programs, social protocols—prioritize ease of onboarding, wallet compatibility, and network effects over privacy and regulatory compliance. The EVM’s MetaMask ecosystem, ENS, and ERC-721 standards dominate here, and there is no meaningful case for deploying these applications on Canton.
The convergence question
The interesting question for the next five years is whether these ecosystems converge or remain separate. There are signals in both directions.
Privacy on EVM is advancing faster than it was three years ago. Aztec’s Noir language, Risc Zero’s ZK co-processor, and EIP-7702 collectively push toward a model where private smart contracts are possible on EVM-compatible infrastructure. If ZK proofs become fast enough and the developer experience becomes tractable, the EVM’s privacy gap could narrow substantially. At that point, the EVM ecosystem’s network effects—tooling, liquidity, developer talent—become formidable competition for Canton in institutional use cases.
Conversely, Canton is expanding its public connectivity. The Canton Network’s Global Synchronizer uses an open validator set for its ordering layer. Digital Asset has announced interoperability frameworks with public chains. The vision of Canton as “private institution-grade smart contracts that can settle to public chains” is technically coherent—similar to how traditional finance uses private internal systems (SWIFT, private ledgers) that ultimately settle through public infrastructure (Fedwire, CHIPS).
The most likely near-term outcome is complementarity rather than convergence: institutions use Canton for private multi-party workflows and settlement netting, while using Ethereum (or an L2) as a public reference and distribution layer for tokenized assets. The settlement leg is private; the issuance and secondary market leg is public. This mirrors how regulated markets already work—bilateral OTC derivatives settle privately; exchange-traded derivatives use public price feeds.
Conclusion
Canton and EVM-compatible blockchains are not rivals in the same market. They are solutions to different problems that happen to use overlapping vocabulary. Calling both of them “blockchains” is a bit like calling both PostgreSQL and Apache Kafka “data stores”: accurate but not very useful.
The EVM ecosystem’s strengths—permissionless access, global composability, deep liquidity, ecosystem maturity—flow directly from its transparency and shared global state. You cannot have Uniswap without every participant being able to see every trade. The EVM is the right answer for open, permissionless financial applications, and it will likely remain so even as its privacy tooling matures.
Canton’s strengths—sub-transaction privacy, legal enforceability, regulatory compliance, deterministic finality—also flow from its architectural choices: identified participants, partitioned sub-ledgers, and a trust model built on legal accountability rather than cryptoeconomic incentives. These properties cannot be added to EVM as bolt-ons; they require the decisions Canton made from the start.
For engineers and architects making platform decisions: if your application involves anonymous users, open liquidity, or permissionless composability, build on EVM. If your application involves identified financial institutions, requires confidential multi-party workflows, and must satisfy regulatory obligations that preclude public data exposure, Canton is worth serious architectural consideration. The question is not which platform is better—it is which platform’s assumptions match your application’s requirements. Getting that analysis right before committing is worth considerably more than any feature comparison, including this one.
