A fungible token is never just its interface. It inherits the properties of the ledger beneath it, and that ledger determines how state is stored, who can read it, and what "authorization" means. Two chains can expose almost the same token API while disagreeing completely about ownership, privacy, and trust.
This research compares two such standards. ERC-20 is built on Ethereum's global, public, permissionless state. CIP-56 is built on Canton's private, multi-party, registry-mediated UTXO holdings. The two are similar at the API level and opposite underneath.
The analysis examines the CIP-56 model and its OpenZeppelin reference implementation, traces how value moves and settles, and explains why a family of ERC-20 attack classes has no equivalent to exploit on a private UTXO ledger: allowance abuse, reentrancy, missing return values, and unchecked transfers. It then examines the cost of removing that attack surface, which is not free. In exchange, the model introduces registry integrity risk, off-ledger infrastructure, and application-level invariants the ledger no longer enforces automatically.
The central finding is a trade rather than a win. ERC-20's risk derives from what it makes public and permissionless. CIP-56's risk derives from what it makes private and registry-controlled. The auditor's task is not to declare a winner but to account for the cost of each model, line by line.
What's inside
- Two substrates, two token models. How global-state accounts versus an extended UTXO ledger reshape balances, visibility, authorization, delegated spending, and decimals, presented as a side-by-side comparison.
- A refresher on ERC-20 and OpenZeppelin. The six-function interface, together with the decisions in the current 5.x line that shape how tokens are extended today: the single _update hook, reverts instead of false, and self-declared decimals.
- The CIP-56 model in depth. The UTXO model explained through a physical-cash analogy, the three actors (registries, wallets, apps), the six on-ledger Daml interfaces, and the three workflows: portfolio view, peer-to-peer transfer, and delivery-vs-payment allocation. The section also marks the boundary of the standard, which governs how value moves and settles rather than how it is created.
- A walk through the reference implementation. OpenZeppelin's canton-token-template, template by template: the factory's invariant checks, the three-way transfer dispatch, and the point most relevant to Solidity reviewers, where a double-spend becomes a ledger-level conflict rather than an exploit.
- The allowance question. Why CIP-56 has no standing allowances, and how scoped, pre-funded, self-expiring allocations replace the role previously served by approve and transferFrom.
- Attack class by attack class. Reentrancy, non-standard return values, fee-on-transfer and rebasing, overflow and decimals confusion, front-running and MEV, and lost tokens, each with the structural reason it changes shape or is eliminated.
- The new trust CIP-56 introduces. The other side of the analysis: the registry as a trusted party, a total supply no third party can independently recompute, unauthenticated off-ledger endpoints where a contract-id functions as a bearer capability, same-synchronizer liveness, upgradeability, and the findings that required hardening even in the reference implementation.
A note on versioning
The analysis is framed around CIP-0056 (V1 of the Canton Network Token Standard, Final since March 2025), which remains the current deployed standard. CIP-0112 (V2) was approved more recently (June 2026) as a backward-compatible evolution, but the security analysis here targets the standard in production today.
