Token Standards Explained (ERC-20 vs. ERC-1400 / 3643)

Why security tokens need specialized standards, in approachable terms.

Every serious conversation about tokenization eventually lands on a set of technical labels: ERC-20, ERC-1400, ERC-3643. They sound like part numbers because, in effect, they are. Each is a written specification that tells developers how a particular kind of token should behave on the Ethereum blockchain — what functions it must expose, what data it must track, and what rules it must enforce.

The reason these standards matter is not academic. The choice of token standard determines whether a token can be listed on regulated venues, whether it can enforce KYC and jurisdictional rules, whether corporate actions like dividends and voting are possible, and whether the token complies with the securities laws that apply to it. Pick the wrong standard and you've built a beautiful piece of software that is legally unlistable and operationally unmanageable.

This article explains — in approachable terms, no engineering background required — what these standards are, what they do, and why security tokens need specialized ones instead of the ERC-20 template that powers most of the crypto economy.

What a "Token Standard" Actually Is

Before comparing them, worth being clear about the concept itself.

A token standard is a document — technically an ERC ("Ethereum Request for Comments") — describing a common interface for smart contracts to follow. If a token contract implements the interface correctly, then any wallet, exchange, custodian, or piece of software written to that standard can read balances, initiate transfers, and interact with the token without needing bespoke code for each project.

Standards are what make the token ecosystem interoperable. If every project invented its own transfer function, wallets would need custom integrations for each one, exchanges could not list new tokens without weeks of engineering, and portfolio trackers would be unable to show unified balances. Standards are the reason a single wallet can hold thousands of different assets.

Standards are also layered. A more specialized standard usually extends a simpler one. As we'll see, ERC-1400 and ERC-3643 both build on top of ERC-20 — they don't replace it.

ERC-20: The Universal Coin

ERC-20 is the standard that made Ethereum a global asset platform. Published in 2015, it describes the simplest possible token: something you can hold, transfer, and approve someone else to spend on your behalf. Almost every cryptocurrency, stablecoin (USDT, USDC), governance token, and utility token you've ever heard of implements it.

What ERC-20 does

At its core, ERC-20 defines six functions:

• totalSupply() — how many tokens exist in total.
• balanceOf(address) — how many tokens a given wallet holds.
• transfer(to, amount) — move tokens from your wallet to another.
• approve(spender, amount) — authorize someone else to spend tokens on your behalf.
• allowance(owner, spender) — check how much a spender is currently authorized to move.
• transferFrom(from, to, amount) — the authorized party actually moves the tokens.

That's it. Six functions, plus two events, and you have a token that any Ethereum wallet, DEX, or custodian on earth can interact with.

Why ERC-20 works so well for cryptocurrencies

ERC-20 is fungible (every token is interchangeable), permissionless (anyone can create one, and anyone with an address can receive one), and agnostic (the token doesn't know who is holding it or where the transaction is going). Those properties are exactly what an open, censorship-resistant currency needs.

Why ERC-20 is wrong for securities

Every one of ERC-20's virtues is a bug when the token represents a regulated security.

• Anyone can receive it. A regulated equity cannot legally be transferred to an unaccredited investor in a Reg D deal, a U.S. person in a Reg S tranche during the compliance period, or a sanctioned wallet ever. ERC-20 has no concept of any of that.
• The token knows nothing about the holder. Securities need to know — for dividends, votes, tax reporting, forced transfers on death or court order.
• Transfers are irreversible. Regulated securities need a governed way to reverse transfers made in error, recover from lost keys, or comply with court orders.
• There is no lock-up primitive. Reg D six- or twelve-month restrictions must be enforced somehow. ERC-20 offers no mechanism.
• There is no corporate action primitive. Dividends, coupons, redemptions, splits — all critical, all absent.

You can bolt some of these on top of ERC-20 with off-chain checks or wrapper contracts, but the result is fragile: any wallet, DEX, or bridge that sees a valid ERC-20 will happily move it in ways the issuer never authorized. Regulators and institutions have learned to distrust that gap.

The industry's answer was to design new standards that keep the ERC-20 interface (so existing infrastructure still works) and add the missing layers on top.

The Security Token Standards Family

Several serious standards have emerged. The two most important — and the ones you'll see cited in almost every RWA discussion — are ERC-1400 and ERC-3643 (T-REX). A third, CMTAT (from the Swiss Capital Markets and Technology Association), is common in Swiss issuances.

They differ in style — ERC-1400 is a family of related standards, ERC-3643 is a fully integrated framework — but they share the same design goals:

• Permissioned transfers — a transfer can be rejected on-chain based on rules the issuer defines.
• Identity-aware holders — the token knows who its holders are (via an identity registry), not just their wallet addresses.
• Compliance embedded in the contract — KYC, accreditation, jurisdictional rules, and lock-ups are enforced by code, not by paperwork.
• Corporate actions — dividends, redemptions, forced transfers, voting are first-class operations.
• Issuer control with accountability — the issuer can perform sensitive actions (recovery, freeze, force-transfer) under a documented, auditable governance model.
• Backward compatibility with ERC-20 — the token still exposes the ERC-20 interface, so custody, indexing, and infrastructure work out of the box.

Let's look at how each one gets there.

ERC-1400: A Modular Family

ERC-1400 (originally proposed in 2018) is best thought of as an umbrella standard made up of several related sub-standards:

• ERC-1594 — the core interface for issuing, redeeming, and transferring securities with a reason code returned when transfers fail.
• ERC-1410 — support for partitioning a token into different "tranches," so the same instrument can carry different rights or restrictions (e.g., locked-up vs. freely tradable portions of the same holding).
• ERC-1643 — attachment of legal documents (offering memorandum, articles, etc.) directly to the token, with cryptographic hashes to prove integrity.
• ERC-1644 — controller operations, giving a designated party (usually the issuer or transfer agent) the authority to force-transfer tokens under a documented legal basis.

The most important behavioral additions on top of ERC-20:

• canTransfer(...) — a function that checks whether a transfer would succeed before attempting it, returning a reason code if not (unaccredited buyer, lock-up not expired, sanctions block, etc.).
• Partitions — the ability to split a holder's balance into logical buckets each with their own rules.
• Force transfer — the controller can move tokens with legal cause, essential for recovery and court orders.
• Document binding — legal documents are anchored to the token itself, not to an off-chain database.

ERC-1400's strength is its flexibility. Because it is a family rather than a single monolithic contract, issuers can pick the pieces they need. Its weakness is exactly the same — the standard leaves many implementation details open, so two "ERC-1400 tokens" can behave quite differently under the hood. Interoperability between platforms sometimes requires additional integration work.

ERC-1400 is widely used in the U.S. and Asia, and by platforms including Polymath, Securitize, and various institutional issuers.

ERC-3643 (T-REX): A Fully Specified Framework

ERC-3643 — often referred to by its original name T-REX ("Token for Regulated EXchanges"), created by the team at Tokeny — takes the opposite approach. Rather than a modular family, it is a complete, opinionated framework with a defined architecture. Where ERC-1400 gives you Lego bricks, ERC-3643 gives you a designed building.

An ERC-3643 deployment is made up of three coordinated layers of smart contracts:

1. The Identity Registry

Every eligible holder has an on-chain identity contract (typically ERC-734/735 or ONCHAINID) that records:

• Their KYC status
• Their country of residence
• Their investor category (retail, professional, accredited)
• Any other claims relevant to the offering (institutional flag, VIP status, etc.)

The identity contract is issued by trusted claim providers (KYC vendors, regulators, or the issuer's own compliance team) and can be reused across multiple issuances. An investor who has been KYC'd once can be recognized by any ERC-3643 token that trusts the same claim provider.

2. The Compliance Rules

A separate compliance contract encodes the offering-specific rules:

• Maximum number of holders (e.g., under Reg D 3(c)(1))
• Country allowlists and blocklists
• Investor-category restrictions (accredited-only, professional-only)
• Lock-up periods
• Ownership caps (no single holder above a threshold)
• Transfer limits per period

Because the rules live in a separate contract, they can be updated as the offering evolves (e.g., a lock-up expires, a new country is added to the eligible list) without redeploying the token itself.

3. The Token Contract

The token itself is ERC-20-compatible on the outside — so it works with any wallet, custodian, or infrastructure that speaks ERC-20 — and calls the compliance and identity contracts on every transfer. If a transfer would violate a rule, it fails at the protocol level; the transaction reverts and the tokens don't move.

The result is a token that behaves like an ERC-20 for all the plumbing that already exists in the ecosystem, but enforces securities-law compliance atomically on every state change.

Why the industry has consolidated around it

• Precise specification. Unlike ERC-1400's modular flexibility, ERC-3643 is fully specified. Two ERC-3643 tokens behave the same way.
• Reusable identity. The ONCHAINID identity layer means investors don't have to re-KYC for every deal.
• Recovery and force transfer. Built-in support for lost wallets, court orders, and corporate governance.
• Institutional adoption. ERC-3643 is used by major European issuers, several tokenized funds, and increasingly by regulated MTFs. It became a formal ERC (Ethereum Request for Comments) in 2023, cementing its role as an industry-recognized standard.

Cost of admission: ERC-3643 is more complex to deploy than a raw ERC-20 or a light ERC-1400 implementation. In practice, virtually no one deploys it by hand — issuers work with a platform (Tokeny is the reference implementation, but there are others) that automates the deployment and integrates with KYC providers.

Permissioned Transfers: The Core Idea, Illustrated

Both ERC-1400 and ERC-3643 share the same core idea, and it's worth pausing on it because it's what makes security tokens fundamentally different from cryptocurrencies.

In an ERC-20 token, transfer() does two things: subtract the amount from the sender's balance and add it to the recipient's balance. There is no third step.

In an ERC-1400 or ERC-3643 token, transfer() first asks a compliance check: is this transfer allowed under the rules that govern this security? The check considers:

• Is the sender authorized to send?
• Is the recipient a KYC'd, whitelisted holder in an eligible jurisdiction and investor category?
• Is the amount within any per-holder or per-period caps?
• Is any lock-up period still in effect?
• Are there sanctions or freeze orders that apply?

Only if the compliance check passes does the transfer execute. If it fails, the transaction reverts — cleanly, on-chain, with no partial state — and the tokens don't move. This is why security tokens are said to be "compliant by design" rather than "compliant by process." The rules aren't enforced by a human clicking approve on a settlement; they are enforced by the protocol on every single interaction, forever.

For issuers, this is what makes the entire tokenization value proposition credible. For regulators, it is what makes the technology palatable — the enforcement isn't optional or after-the-fact. For investors, it means the market they buy into is a market whose rules cannot be quietly bypassed.

Other Standards You'll Encounter

The universe extends beyond ERC-1400 and ERC-3643. A few worth knowing:

• ERC-1404 — a lightweight standard for restricted tokens with a detectTransferRestriction() function returning a code. Common in early U.S. STO deployments; less feature-rich than ERC-1400 or ERC-3643 but easier to implement.
• ERC-2222 (Funds Distribution) — automates pro-rata distribution of dividends or profits to holders. Often combined with a security-token standard.
• ERC-4626 (Tokenized Vaults) — standardizes the interface for yield-bearing vault tokens. Widely used in tokenized T-bill and money-market fund products from BlackRock, Franklin Templeton, Ondo, and others.
• CMTAT (Capital Markets and Technology Association Token) — a Swiss standard designed to comply with FINMA rules and the Swiss DLT Act. Widely used in Switzerland and Liechtenstein.
• ERC-1155 (Multi-Token Standard) — used in some fractional real estate and collectibles projects where multiple related token types share a single contract.
• Non-Ethereum standards — Polygon, Avalanche, Stellar, XRP Ledger, Hedera, and others each have their own security-token frameworks, some closely modeled on ERC-1400/3643 and some quite different. The concepts translate; the specific interfaces don't.

The universe is standardizing, but hasn't fully consolidated. Serious platforms typically support multiple standards to give issuers flexibility.

How to Think About Choosing a Standard

If you are an issuer, tokenization advisor, or investor evaluating a project, the practical questions are:

• What venues does the target trading platform support? Some ATSs and MTFs only integrate certain standards. Getting this wrong strands the token.
• What jurisdictions are you selling into? Swiss and Liechtenstein deals often use CMTAT; European MTF-listed tokens increasingly use ERC-3643; U.S. Reg D-heavy deals frequently use ERC-1400 or ERC-1404.
• How complex are the compliance rules? A single-tranche Reg D 506(c) deal for U.S. accredited investors can run happily on ERC-1404. A multi-jurisdiction, multi-tranche fund with ongoing eligibility monitoring needs the full expressive power of ERC-3643 or ERC-1400.
• Is the identity layer reusable? Investors hate re-KYC. ERC-3643's ONCHAINID gives holders a portable identity across issuances on the same platform.
• How mature is the tooling? Even the best standard is useless without deployable, audited contracts, KYC integrations, and monitoring dashboards. Buying into a well-supported implementation matters more than the standard itself.

There is rarely a single right answer. But there is often a wrong one, and it usually looks like "we'll just use ERC-20 and handle compliance off-chain." That approach has failed publicly enough times that regulated markets no longer take it seriously.

The Bigger Point

The reason token standards deserve their own article is that they are the layer where the promise of tokenization actually becomes real. A well-designed security token standard makes compliance not just possible but automatic. It makes cross-platform interoperability real without requiring bilateral integrations. It gives issuers a governance model that regulators can inspect. And it gives investors an assurance that the rules they signed up for cannot silently be violated by any transaction, ever.

ERC-20 built the trillion-dollar crypto economy. ERC-1400, ERC-3643, and their peers are the standards that let the multi-trillion-dollar world of regulated capital markets move on-chain without leaving its rules behind. Different problems, different tools — and knowing which one you're holding is the difference between a project that scales and one that quietly disappears.