For most new regulated token issuances, ERC-3643 is the better starting point: it is a Final ERC with an on-chain identity model, modular compliance and a broad ecosystem. ERC-1400 remains attractive where one token must contain multiple partitions — share classes, tranches or lock-up buckets — or where an existing platform already uses it. Both aim to make tokens behave like securities; they just put the complexity in different places.
Key takeaways
- ERC-3643: identity-first. Every holder is a verified ONCHAINID; compliance modules check every transfer.
- ERC-1400: partition-first. Balances split into tranches; transfers validated via
canTransferand off-chain certificates. - Status matters: ERC-3643 is Final; ERC-1400 never completed the ERC process.
- Both support issuer controls (forced transfers/controller operations, freezes or equivalents).
Comparison table
| Criterion | ERC-3643 | ERC-1400 |
|---|---|---|
| Standard status | Final ERC | Proposal (not finalised) |
| Base interface | ERC-20 compatible | ERC-20-like with partitions |
| Identity | ONCHAINID + Identity Registry | Not standardised (whitelists, certificates) |
| Eligibility rules | Claim topics + trusted issuers | canTransfer logic / signed data |
| Compliance rules | Modular compliance contracts | Custom per implementation |
| Partitions / tranches | Separate tokens (shared registry) | Native (ERC-1410) |
| Documents | Off-chain, add ERC-1643 if needed | ERC-1643 included |
| Issuer interventions | Freeze, partial freeze, forced transfer, recovery | Controller transfer/redeem (ERC-1644) |
| Ecosystem | Broad and growing; industry association | Smaller, platform-specific |
| Audit complexity | Moderate (known framework) | Higher (partition logic) |
Architecture philosophies
ERC-3643: identity in the token layer
The token knows who holds it through the Identity Registry. Rules are expressed as required claims and compliance modules, reusable across many tokens. KYC refreshes and investor moves update one identity and apply everywhere.
ERC-1400: rules attached to transfers
Validation often relies on off-chain services signing each transfer (transferWithData), with reason codes explaining failures. Partitions let one token express classes and lock-ups without separate contracts.
Which to choose
Choose ERC-3643 when: - You are launching a new issuance and want ecosystem support. - You expect cross-border investors and evolving eligibility rules. - You plan multiple instruments sharing one investor registry.
Choose ERC-1400 when: - Partitions are fundamental (complex vesting, many share classes in one instrument). - Your transfer agent or venue already runs ERC-1400. - You prefer off-chain signed approvals for each transfer.
Consider alternatives: ERC-1155 with compliance hooks, ERC-7518 for partitioned ERC-1155 securities, or ERC-7943 as a minimal interoperable layer.
Migration between them
Moving from ERC-1400 to ERC-3643 typically involves: snapshotting balances by partition; onboarding each holder’s identity and claims; deploying one ERC-3643 token per class (or using partial freezes for locks); minting equivalents; and freezing or burning the old tokens — with legal notices to investors.
Same requirement, two implementations
| Requirement | ERC-3643 approach | ERC-1400 approach |
|---|---|---|
| Only KYC’d investors may hold | Receiver must be verified in Identity Registry with required claims | canTransfer checks whitelist or signed certificate in data |
| 12-month lock-up for founders | Partial freeze of founder balances, released by agent | Tokens held in LOCKED partition, moved to FREE on schedule |
| Max 150 holders | Max-holders compliance module | Custom holder counting in transfer validation |
| Court order to move tokens | forcedTransfer by agent |
controllerTransfer by controller |
| Lost wallet | recoveryAddress to new verified wallet |
controllerTransfer to new wallet |
| Publish prospectus | Off-chain + optional ERC-1643 | ERC-1643 built in |
| Two share classes | Two tokens sharing a registry | Two partitions in one token |
Both can satisfy the same legal requirements; the difference is how much is standardised versus custom.
Ecosystem questions to ask partners
- Which standards does your custodian support for safekeeping and reporting?
- Which standards does your transfer agent reconcile against?
- Which standards does your intended trading venue accept?
- Which standards do your auditors have experience reviewing?
In our experience, answers to these questions decide most standard selections.
Frequently asked questions
Not obsolete, but less common for new issuances because it was never finalised and ERC-3643 has broader support.
Yes, by deploying a token per class that shares the same identity registry and compliance setup.
It depends on configuration. ERC-3643 compliance modules add per-transfer cost; ERC-1400 partition logic adds its own. Keep rules minimal in both.
Yes, if implemented correctly: personal data stays off-chain; only claims or approvals are on-chain.
Yes. A platform can support legacy ERC-1400 instruments while issuing new ones under ERC-3643, sharing KYC and portals.
Most new tokenized fund units use permissioned ERC-20 designs such as ERC-3643, often combined with ERC-7540 vault interfaces.
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
