The standards argument usually runs about three weeks. ERC-3643 or ERC-1400, a comparison spreadsheet, somebody forwarding a vendor blog post at eleven at night. Then the build starts and the token contract turns out to be the easy part.
Both standards answer one question: who is allowed to hold this thing. They answer it in opposite directions and the answer does matter. It's also one decision out of six, and the other five are where these projects stall. Identity plumbing. NAV. Corporate actions. Somewhere for holders to sell when they want out. The back-office nobody put in the estimate.
You get both halves below: the comparison, and the map of everything the comparison doesn't cover.
ERC-3643 vs ERC-1400: the quick answer
ERC-3643, also called T-REX, puts identity and compliance on the chain. Whether a wallet may hold the token is decided by registry contracts anyone can read. It reached Final EIP status on 15 December 2023, the first compliance-oriented token standard to get there.
ERC-1400 leaves compliance logic off-chain and standardises how the chain asks whether a transfer is permitted. It's an umbrella over ERC-1594, ERC-1410, ERC-1643 and ERC-1644, and it never finished the EIP process.
Choose ERC-3643 if you need self-contained, auditable compliance across several jurisdictions. Choose ERC-1400 if a transfer agent or compliance engine already owns the rulebook, or if you truly need partitioned balances. Both are defensible. Neither one gets you a working platform.
Why this got urgent in 2026
Tokenized RWAs stopped being a pitch-deck category somewhere in the last eighteen months. On-chain value tracked by rwa.xyz went from around $6B at the start of 2025 to over $31B by May 2026, sitting near $33.5B in July. Tokenized US Treasuries account for between $12.9B and $16.2B of that on their own, and BlackRock's BUIDL fund passed $2.5B.
That changed who's in the room when the standards question comes up. It used to be a founder picking a template. Now it's a fund administrator, a transfer agent and a compliance officer who all have to put their name against the same contract. The standard's association reports more than $32B tokenized with ERC-3643 across 180+ jurisdictions, and DTCC joined that association in March 2025. The institutional pull is real and it points one way.
Which is why the rest of this keeps insisting the token isn't the system.
ERC-3643 in plain terms
T-REX is a token plus a handful of registry contracts, and keeping them apart is the whole idea. The rulebook lives outside the token, so you can change it, reuse it across issuances, and let an auditor inspect it without touching the asset.
What sits in those registries:
Who is verified, held in shared storage so one investor base carries across every token the same issuer launches.
Which KYC and accreditation providers you trust, and what each holder has to prove: country, accreditation status, AML clearance.
The offering rules themselves. Holder caps, jurisdiction limits, maximum ownership percentages, lock-ups.
The investor's own identity contract, ONCHAINID, carrying signed claims from those providers.
Eligibility gets settled before value moves, and the issuer keeps the powers a regulated instrument needs: forced transfer for court orders and error correction, freezing part of a balance, a global pause, and recovery for the investor who lost a seed phrase and still legally owns the asset. In the contracts those are forcedTransfer, freezePartialTokens, pause and recoveryAddress.
That last one tells you something about who wrote the standard. Lost-key recovery is a first-class function here, which is what happens when the authors have already sat across from an investor who can prove ownership and can't sign a transaction.
The trade-off is predictable enough to plan around. Every transfer checks identity and rules, so it costs more than a plain ERC-20, and onboarding an investor means creating an identity for them first. Most issuers deploy to an L2 and stop thinking about either. What you get back is auditability: a regulator, an auditor or a counterparty can verify your ruleset by reading the chain instead of trusting your backend.
ERC-1400 in plain terms
ERC-1400 is really four standards bundled together, and each piece has a job.
ERC-1594 is the core. Issuance, redemption, and transfer validation that comes back with a reason.
ERC-1410 adds partitions, sometimes called tranches. One holder can own "Reg D, locked until Q3" and "freely tradable" units of the same token.
ERC-1643 is a document registry. Prospectus, subscription agreement, each hashed so you can prove which version an investor accepted.
ERC-1644 covers controller operations: forced transfers for court orders, inheritance, fixing mistakes.
The thing it does better than ERC-3643 is failure messages. A blocked transfer comes back with a reason code instead of a flat rejection, and that's real product surface. Your front end can tell an investor why the subscription didn't go through instead of showing them a failed transaction and a support address.
One caveat vendor comparisons tend to skip: ERC-1400 was never finalised as an EIP. You won't find it on eips.ethereum.org, because the specification lives in a community repository. So "we use ERC-1400" describes a family of similar but incompatible implementations rather than a fixed standard, and that becomes a real problem the first day a custodian, an exchange or a fund administrator has to integrate with you.
Side by side
| Dimension | ERC-3643 (T-REX) | ERC-1400 (suite) |
|---|---|---|
| EIP status | Final, 15 Dec 2023 | Never finalised; spec maintained outside the EIP repository |
| Where compliance lives | On-chain, in readable modules | Mostly off-chain; the chain queries your rulebook |
| Identity model | ONCHAINID claims + trusted issuers registry | Unspecified — issuer's choice |
| Balance model | Single balance + partial freezing | Partitions / tranches (ERC-1410) |
| Blocked-transfer feedback | Yes / no | Status code + reason code |
| Documents | Out of scope | On-chain registry (ERC-1643) |
| Forced transfer & recovery | Built in | Controller operations (ERC-1644) |
| Cost profile | Higher per transfer — identity and rule checks every time | Lighter on-chain; cost shifts to your infrastructure |
| Reusing investors across tokens | Native, via shared identity storage | Implementation-specific |
| Ecosystem gravity | Association, DTCC, audited reference implementation | Fragmented across vendors |
| Best fit | Multi-jurisdiction offerings needing verifiable on-chain compliance | Existing transfer-agent workflows, complex tranche structures |
One difference these tables never capture: ERC-3643 makes your rules public and ERC-1400 keeps them private. If you want counterparties verifying eligibility without signing a legal agreement first, publishing the rules is an asset. If the eligibility criteria are themselves commercially sensitive, publishing them is a decision you can't take back. Nobody in engineering should be making that call alone.
ERC-7943, the option that didn't exist last year
ERC-7943, the Universal Real-World Asset interface or uRWA, reached Final on 27 May 2026, backed by a coalition of issuance platforms, infrastructure providers, exchanges, identity vendors and audit firms.
It's deliberately smaller than either standard above: a minimal, vendor-neutral interface for transfer validation, freezing, forced transfers and enforcement actions, with no opinion about your identity provider or your jurisdiction. Treat it as a common denominator. If you're building an integrator, a marketplace or a custody product, supporting uRWA means handling assets from many issuers without writing an adapter for each. If you're the issuer, it sits alongside your compliance stack rather than replacing it. It describes what the enforcement actions look like and says nothing about who may hold the token.
Choosing, in one pass
Regulated offering, several jurisdictions, the same investors across multiple issuances: ERC-3643. The shared identity registry pays for itself by the second token.
A transfer agent or fund administrator already owns compliance: ERC-1400, and commit hard to one implementation and one vendor's semantics.
Real tranche structures, with different lock-ups or rights on one instrument: ERC-1410 partitions, or ERC-3643 with a separate token per class. Model both. Separate tokens is usually simpler than teams expect.
Infrastructure that has to consume assets from many issuers: support ERC-7943 as your integration surface.
Compliance rules that are a trade secret: don't publish them on-chain, whichever standard you land on.
However it lands, it's one architectural call inside a much bigger build. It's the part we scope first on RWA tokenization projects, and the part clients are always surprised takes the least time.
The six components that eat the timeline
A tokenized asset is a financial product with a legal wrapper, an operating calendar and a customer base. The token is where it settles, not where it lives. Every production RWA system we've worked on has these six pieces in it, and the ones that shipped late were late because pieces three through six got discovered after the token was already deployed.
1. Token and compliance layer
The standard, the compliance rules, the agent roles, the upgrade path. The decisions that hurt later if you skip them: who can pause, who can force a transfer, and whether the rules can be updated without replacing the token.
This is also where privileged roles quietly multiply. Access-control failures, not exotic math bugs, are what actually drains protocols. Get the role matrix reviewed before anyone writes the rules, which is where security architecture work belongs. Design time, not the fortnight before launch.
2. Identity, KYC/AML and onboarding
Whitelisting, accreditation checks, allowlists and blocklists, claim issuance and expiry. Two things teams consistently underestimate.
Claims expire. An accreditation good for twelve months implies a re-verification pipeline and a written policy for the holder whose claim lapses while they still own tokens. "Freeze" and "force a sale" are very different legal answers, and you want that settled before it comes up.
Onboarding is a funnel, not a function call. Creating an identity, collecting documents, waiting on a provider, then minting. That's days of user-visible state your product has to represent, with a support inbox attached to it.
3. Asset registry, valuation and NAV
The link between the token and the thing behind it: asset records, valuation sources, NAV computation, publication cadence, and whatever carries the off-chain number on-chain.
This is the component most likely to get waved through as "we'll publish NAV weekly" and most likely to become an incident. Ask early who signs the NAV, what happens when it's late, and what happens when it's wrong and an investor already redeemed against it. A staleness tolerance and a circuit breaker belong in the specification. They're miserable to add as a hotfix.
4. Issuance and lifecycle operations
Subscriptions, minting against confirmed payment, redemptions, and the corporate-action calendar: dividends or coupons, yield accrual, cap-table changes, reporting dates.
Paying a shifting holder base is harder than it sounds. Snapshot mechanics, holders who transferred mid-period, unclaimed distributions, and rounding that has to reconcile to the cent against an off-chain ledger. This is ordinary financial-operations software that happens to settle on a blockchain, and it deserves the same engineering discipline as the token.
5. Secondary market
Where a holder can actually sell. A permissioned venue whose pools respect the compliance layer, OTC support with bilateral settlement, an ATS or licensed venue integration, or an honest line in the documents saying the asset is illiquid until redemption.
Compliance and market mechanics collide here, usually late. If only verified addresses can hold the token, the pool has to be verified too, and then liquidity providers are holding a claim on restricted assets. There are answers to that. They need designing alongside the market mechanics rather than bolted on after issuance.
6. Admin, reporting, back-office
Issuer dashboard, investor portal, role management, audit trail, and whatever reports the offering's legal structure obliges someone to produce. Every privileged on-chain action needs an off-chain record of who authorised it and why. Every investor statement has to reconcile against chain state. It's unglamorous, it gets scoped last, and it's the single most common reason a finished platform can't go live.
What goes wrong after launch
Compliance rules change. Jurisdiction lists, holder caps and lock-ups all move. If the rules are immutable and the token isn't, you're running a migration instead of editing a config.
The identity provider changes. Keys rotate, vendors get replaced, and existing claims have to survive it.
The first forced transfer. A court order, a death, a compromised wallet. Teams that never rehearsed it find out that the multisig policy, the legal sign-off and the on-chain action have never once been exercised together.
A NAV dispute. An investor redeems against a value that later gets corrected. With no reconciliation plan, that's a very bad week.
Nobody owns reconciliation. Chain state and the official register drift apart, and the drift surfaces during an audit instead of in a nightly job.
FAQ
Is ERC-3643 better than ERC-1400?
For most new regulated offerings, yes. It's a Final EIP, the compliance is on-chain and auditable, and the reference implementation has been through many audits. ERC-1400 still wins when compliance already sits off-chain with a transfer agent, or when partitioned balances are a hard requirement.
Who should be making this decision? Compliance and legal, with engineering pricing the options. The question that settles it isn't technical: does the rulebook already live with a transfer agent, and does it need to stay private?
Can we migrate from ERC-1400 to ERC-3643 later? Technically yes, by burning and reissuing against a new contract. Practically it's a full corporate action: investor communication, legal sign-off, cap-table reconciliation, and integration work for every counterparty. Treat this as a five-year decision rather than a sprint decision.
Does ERC-7943 replace ERC-3643? No. ERC-7943 standardises the interface for enforcement actions so integrators can support many issuers the same way. ERC-3643 is the compliance and identity system behind those actions. They compose.
Why isn't ERC-1400 on eips.ethereum.org? It never completed the EIP process. The spec is maintained in a community repository, which is why implementations differ between vendors. Worth weighing when you plan custodian and exchange integrations.
How much does on-chain compliance cost per transfer? Enough to matter for high-frequency trading, not enough to matter for a fund with quarterly subscriptions. The cost scales with how many compliance rules you switch on. Most issuers move to an L2 and stop thinking about it.
Do we need all six components at launch? No, but you need a decision on all six. Deciding secondary trading is out of scope for v1 is fine. Discovering in month seven that your compliance layer rules out the venue you had in mind is not.
Building an RWA platform?
We architect and ship the whole stack: token and compliance layer, identity and onboarding, NAV and asset registry, issuance and lifecycle operations, secondary market infrastructure, and the back-office that makes the thing operable. If you're choosing between ERC-3643, ERC-1400 and ERC-7943 this week, that conversation takes about twenty minutes and the answer is usually clearer than the internet makes it look.
→ RWA tokenization development at RedDuck
Related reading: Audit readiness vs a security audit: where the line actually is, on what to have in place before a compliance-heavy codebase goes out to an auditor.
