ERC-3643 vs. ERC-20 with off-chain whitelist: institutional trade-offs

An off-chain whitelist backing an ERC-20 looks cheaper at first pass. The allocator runs KYC, drops approved addresses into a signed Merkle tree, the token contract checks proof at transfer. Transfers are permissionless between whitelisted addresses; the whitelist is off-chain, auditable by the sponsor.

The problem emerges at revocation. A sanctioned address must be blocked at the next transfer. A Merkle-based design requires a new root, gas for the reassignment, and latency between revocation intent and enforcement. Courts and regulators care about this latency.

ERC-3643's Identity Registry lives on-chain. Revocations are one transaction; enforcement is the next block. The standard enforces permissioning at the contract level via canTransfer(), not at the application or sponsor level. Every transfer is gated against the current Identity Registry state.

For institutional distribution — where a sanctions hit or a jurisdiction change triggers an immediate transfer-restriction obligation under MiFID II and the EU sanctions regime — the ERC-3643 posture is the only posture that satisfies counsel.

[PLACEHOLDER — 200-word stub. Full version to be drafted by content team.]