ERC-3643 vs ERC-1400 vs CMTAT: Security Token Standards

A bank called me last year with a simple-sounding question. They'd picked a tokenization vendor, the vendor had picked a token standard, and now their compliance team wanted to know if that was the right call. It wasn't a code question. It was a five-year question wearing a code question costume.

So here's the honest comparison of the three standards that actually come up: ERC-3643, ERC-1400, and CMTAT. I'm one of the named authors of ERC-3643, so read me as biased and informed, not neutral. I'll be fair to the other two, because pretending they've got no place is how you lose the argument with a good engineer.

Getting there was its own multi-year fight; I broke down how you actually get an Ethereum standard accepted in the first episode.

The decision nobody warns you about

A security-token standard isn't a library you swap out next sprint. It decides who can hold the asset, how a regulator forces a freeze, and what your auditors have to reason about for the life of the instrument. Get it wrong and you're migrating a live cap table, which is roughly as fun as it sounds.

What are ERC-3643, ERC-1400, and CMTAT?

All three let you issue a security token on an EVM chain. They disagree on the one thing that matters for a regulated asset: how the token decides whether a transfer's allowed.

The real fork: where does compliance live?

Forget the feature checklists for a second. All three standards ask the same question on every transfer. They just answer it in different places.

That single choice drives everything else: what data has to exist on-chain, what a regulator has to trust, how hard a freeze is, and how much your token contract has to know about the outside world. The standards differ on the location of the answer, not the difficulty of the question.

ERC-3643: identity is the whole thesis

ERC-3643 makes a bet: the token itself should refuse an ineligible transfer. Not a wrapper, not an off-chain gate you can forget to call. The transfer function asks an identity registry whether the receiver holds the claims this token requires, and reverts if they don't. Compliance isn't bolted on; it's the transfer path.

The claims live in an on-chain identity contract (in the T-REX design, OnchainID), signed by trusted issuers. Your passport never touches the chain. The chain only sees that some issuer you trust has attested "this address is allowed to hold this class of asset." That's the elegant part, and it's why the model earned its adoption.

The cost is honest and worth stating plainly. You're now running an identity system. Someone has to issue claims, rotate them, revoke them, and be online when an investor onboards. For a permissioned instrument that a regulator watches, that machinery is the point. For a token you wanted to be simple, it's overhead you'll resent.

If you want the actual interface and its Final status, the ERC-3643 (T-REX) reference lays it out.

ERC-1400: partitions, and when they win

ERC-1400 isn't a worse ERC-3643. It's a different idea. It says a security is rarely one flat balance. It's tranches: locked and unlocked, Reg D and Reg S, vested and unvested. So it splits a holder balance into named partitions, each with its own transfer rules, and adds a controller role that can force a transfer or redemption when the law says it must.

That maps beautifully onto instruments with real lifecycle: lockups that expire, share classes that convert, corporate actions that move balances between buckets. If your compliance story is mostly "these tokens are restricted until date X and then they're not," partitions express that natively in a way ERC-3643 has to model around.

What ERC-1400 doesn't give you is identity. It assumes something upstream already decided who's allowed on the register. Pair it with a whitelist or an identity layer and you're close to ERC-3643 with extra tranche machinery. If you don't need the tranches, that machinery is complexity you're paying for and not using.

CMTAT: the lean, pragmatic option

CMTAT is the option engineers underrate because it looks boring, and boring is often correct. It's a Swiss framework (from the Capital Markets and Technology Association) built on a lean ERC-20 core with modules: pause the whole token, freeze an address, snapshot balances for a dividend or a vote, and a validation hook that every transfer must pass.

The philosophy is opposite to ERC-3643. Instead of building identity into the token, CMTAT gives you a clean seam and says "put your compliance logic here." That validation module can be a simple allowlist, or it can call out to something as strict as an identity registry. You choose the strictness; the standard just guarantees the hook is always called.

That's its strength and its warning. CMTAT is honest that it's a frame, not a full compliance system. The ERC-20 core means your token works with existing wallets and tooling on day one. But an empty validation module is a security token with no compliance, so the real work moves into code you own and must get right.

ERC-7943 (uRWA): an interface, not a fourth answer

There's a fourth name in this conversation now, and it isn't a fourth answer. ERC-7943, the Universal RWA interface (uRWA), went Final on 5 May 2026. Before you add it to the bake-off, read its category field. It says Interface.

It doesn't tell you where compliance lives. It extends ERC-20, ERC-721 and ERC-1155 with a shared vocabulary for the things every regulated token ends up doing anyway: freeze a balance, force a transfer when the law demands it, ask whether an address is allowed to send or receive.

Its motivation is blunt about why. Earlier attempts at a universal RWA standard, it says, imposed unnecessary complexity and gas overhead for simpler use cases that don't need mandatory on-chain whitelisting or a specific on-chain identity solution. It names nobody. Given that mandatory on-chain identity is precisely the ERC-3643 thesis, I'll take the hint.

The naming is deliberate too. The spec says it preferred canTransfer over isTransferAllowed for consistency with established RWA standards including ERC-3643. That is the useful part: an integrator learns one vocabulary instead of three.

So it doesn't change the choice this article is about. It changes what you expose once you've made it.

interface IERC7943Fungible {
    function forcedTransfer(address from, address to, uint256 amount) external returns (bool result);
    function setFrozenTokens(address account, uint256 amount) external returns (bool result);
    function canSend(address account) external view returns (bool allowed);
    function canReceive(address account) external view returns (bool allowed);
    function getFrozenTokens(address account) external view returns (uint256 amount);
    function canTransfer(address from, address to, uint256 amount) external view returns (bool allowed);
}

So which one should you pick?

Strip away the tribalism and the decision isn't that hard. Match the standard to the shape of your compliance problem, not to whichever one your vendor already ships.

The same "where does the rule live" question shows up in agent payments and who's liable when one goes wrong, later in this series.

Three ways this goes wrong in production

FAQ