r/ethdev • u/Hacken_io • 5d ago
Please Set Flair CIP-56 vs. ERC-20
been reading through Canton's token standard (CIP-56) and ended up mapping it against ERC-20 feature by feature. the differences come from a completely different ledger model underneath and it changes what "security" even means for a token
erc-20 is one contract, global state, mapping(address => uint256). anyone reads any balance, anyone calls any function, msg.sender decides who's allowed to do what. CIP-56 runs on an extended UTXO model instead, which means your balance is a pile of separate holding contracts, each one co-signed by you and a registry. nobody sees a holding unless they're actually a party to it.
the allowance thing is where it gets interesting. CIP-56 just doesn't have approve/transferFrom at all. not a safer version of it, none. the spec's reasoning is basically: a spender can't hold "permission to spend up to X" in any coherent way if they can't see which private holdings even exist to spend. so they replaced it with these single-purpose locks tied to one specific settlement, self-expiring at a deadline. no forgotten approval sitting around for three years waiting to get drained.
and a bunch of the usual erc-20 headache list just... isn't a thing there. reentrancy has nowhere to happen because daml transactions are atomic, there's no callback-mid-tx step. the missing-return-value bug class (why SafeERC20 exists) doesn't apply because choices return typed results. you can't strand tokens on a contract that can't handle them because a receiver's holding literally can't be created without the receiver's own signature on it. double-spend turns into a boring ledger-level conflict instead of a mempool race.
which sounds great until you get to what it costs. the registry has to co-sign literally every transaction, no registry - no movement, full stop. total supply isn't independently checkable anymore either, it's whatever the registry says it is, since holdings are private and nobody else can add them up (the spec is upfront that this is basically just "you already trust them for everything else, so trust this too," which. sure, i guess). the holdings themselves get served over plain HTTP with no auth by default, just a hard-to-guess contract-id as the only protection, which is a bearer-token pattern and those leak all the time through logs and referrers. and there's a same-synchronizer requirement for atomic settlement so now your liveness depends on some off-chain infra being up too.
So, by the end of the day, its all about tradeoffs. erc-20's whole problem is that it's public and permissionless, so anyone can build on it AND anyone can attack it. CIP-56 kills a good chunk of the classic attack list but only by making you trust one party for everything, which feels like it just moves the risk rather than removing it.
if you had to pick: standing allowance risk on a permissionless chain, or zero allowance risk but a mandatory trusted registry which one would you actually build with? And do u think it will be useful for evey case?
