Choosing a token standard used to be a technical footnote, something your Solidity developer decided on day one and nobody questioned again. That changed when MiCA made compliance enforcement a design requirement, not a backend afterthought. The standard you pick now determines how you prove compliance to regulators, how your tokens interact with wallets and exchanges, and whether you can issue multi-class instruments without deploying separate contracts.
This guide breaks down ERC-1400 and ERC-3643 from a builder’s perspective – what each standard actually does at the contract level, where they overlap, and how MiCA’s requirements push the decision in a specific direction. Based on platforms we’ve shipped for institutional issuers in Europe, Canada, and New Zealand.
Why This Decision Matters More in 2026
Before MiCA, the choice between ERC-1400 and ERC-3643 was mostly a preference question. Both worked. Both could be made compliant. The compliance logic lived in your backend either way, and regulators hadn’t yet defined what “provable enforcement” meant in practice.
MiCA changed the game. Three requirements in particular affect your token standard choice:
Transfer restriction enforcement (Title II/V): Regulators expect issuers to demonstrate that restrictions are actually enforced not just promised in a whitepaper. A standard that enforces compliance on-chain provides stronger evidence than one that relies on backend checks.
Record-keeping (Article 68): Five years of transaction records with full traceability, including compliance check results for every transfer. If your compliance checks happen off-chain, you need a separate audit system to log them. If they happen on-chain, the blockchain IS your audit trail.
CASP obligations (Title V): Crypto-Asset Service Providers must maintain audit trails that regulators can independently verify. On-chain compliance is independently verifiable by design. Backend compliance requires you to open your servers to auditors.
None of this means ERC-1400 is unusable under MiCA. It means the burden of proof is different and that affects your architecture, your audit costs, and your regulatory risk profile.
ERC-1400: Security Tokens With Partitions
ERC-1400 was proposed by Polymath, Securitize, and others to address the specific needs of security token issuance. Its defining feature is partitions – the ability to divide a single token contract into subsets with different rules.
How It Works
An ERC-1400 token can hold multiple partitions within the same contract. Think of partitions as labeled buckets: Series A shares, Series B shares, vesting tranches, or restricted vs. unrestricted tokens. Each partition can have its own transfer rules, and investors can hold tokens across multiple partitions.
Transfers are validated using an off-chain key mechanism. Before a transfer executes, the system checks whether the sender has the right to transfer from the specific partition, and whether the recipient is authorized to receive. This validation typically happens in your backend: your compliance system generates a signature that the contract accepts.
The standard also includes a document management system – on-chain references to legal documents (prospectus, term sheets, investor agreements) associated with the token. This is useful for maintaining an on-chain link between the token and its legal framework.
What ERC-1400 Does Well
Multi-class instruments: If you’re tokenizing a fund with multiple share classes, or issuing convertible notes alongside equity, ERC-1400’s partition system handles this natively in a single contract. Without partitions, you’d deploy separate contracts for each class which creates reconciliation headaches and higher deployment costs.
Structured products: Vesting schedules, lockup periods, and phased releases are natural fits for partition-based logic. You can enforce that Series A tokens are locked for 12 months while Series B tokens are freely transferable.
Document traceability: The built-in document management gives you an on-chain reference point for legal documentation. For regulated issuances, this creates a verifiable link between the token and its prospectus.
Where ERC-1400 Falls Short
Compliance is backend-dependent. The off-chain key validation means your compliance checks happen before the transaction hits the chain. There’s a timing gap: an investor’s KYC status could change between the backend check and the on-chain execution. Under MiCA, this gap is a regulatory risk you need to document and mitigate.
Partial ERC-20 compatibility. The partition system adds complexity that breaks compatibility with standard ERC-20 wallets and DEX contracts. Some wallets won’t display partition balances correctly. Some exchanges can’t handle partition-aware transfers. This limits secondary market options.
Higher gas costs. Partition logic, document references, and the additional storage requirements make ERC-1400 transfers more expensive than ERC-3643 or basic ERC-20 transfers. On L1 Ethereum this matters; on L2s (Polygon, Base, Arbitrum) it’s less significant.
ERC-3643 (T-REX): Compliance Built Into the Token
ERC-3643, developed by Tokeny and officially merged into Ethereum’s master GitHub, takes a fundamentally different approach. Instead of validating transfers off-chain, it builds the compliance logic directly into the smart contract using an on-chain identity framework called ONCHAINID.
How It Works
Every ERC-3643 token has a set of compliance validators embedded in the contract. Before any transfer executes, the contract automatically checks whether both the sender and recipient have the required verified claims – KYC status, accreditation, jurisdiction eligibility, holding limits – all on-chain.
These claims are issued by trusted claim issuers (your KYC provider, a regulator, a law firm) and stored in the investor’s ONCHAINID – a separate smart contract that acts as a decentralized identity. The token contract checks the ONCHAINID, not a backend database.
The compliance check and the transfer happen in the same transaction. This is atomic: either both succeed or both fail. There’s no gap between “is this investor eligible?” and “did the transfer execute?”
What ERC-3643 Does Well
On-chain compliance enforcement. The single strongest argument for ERC-3643 under MiCA. When a regulator asks “how do you enforce transfer restrictions?”, you can point to the blockchain itself. The compliance check is immutable, timestamped, and independently verifiable. No server access needed.
Full ERC-20 compatibility. Despite the added compliance logic, ERC-3643 tokens behave like standard ERC-20 tokens for any wallet or exchange that supports ERC-20. Balances display correctly. Transfers work with standard interfaces. This makes secondary market integration significantly easier.
Gas optimization. Counterintuitively, ERC-3643 is more gas-efficient than ERC-1400 for standard transfers. The compliance checks add gas overhead, but the absence of partition logic and the optimized storage model keep overall costs lower. Batch transfer support further reduces per-transaction costs.
Cross-jurisdictional flexibility. Because compliance rules are modular (each rule is a separate validator contract), you can compose jurisdiction-specific rulesets without modifying the token itself. EU rules for European investors, SEC rules for US investors, MAS rules for Singapore — all enforced by the same token contract with different validator configurations.
Where ERC-3643 Falls Short
No native partitions. If you need multi-class instruments (Series A/B, different rights per tranche), ERC-3643 doesn’t have a built-in solution. You’d need to deploy separate token contracts for each class, or layer a partition system on top which adds complexity.
No native document management. Unlike ERC-1400, there’s no built-in mechanism to link legal documents to the token on-chain. You handle this in your backend or via IPFS references. Not a dealbreaker, but it’s an extra integration step.
Identity infrastructure overhead. ONCHAINID requires setting up claim issuers, managing claim lifecycles (expiration, revocation), and ensuring your KYC provider can issue on-chain claims. This is additional infrastructure compared to ERC-1400’s simpler off-chain key approach. The payoff is stronger compliance evidence, but the setup cost is real.
Head-to-Head Comparison
The Decision Framework: When to Use Which
This isn’t a “one is better” situation. The right standard depends on your asset model, regulatory environment, and operational priorities.
Choose ERC-1400 when:
- Your asset model requires partitions. Multi-class equity, convertible instruments, vesting tranches if different token holders have structurally different rights within the same issuance, ERC-1400’s partition system is the cleanest solution.
- You’re operating in a jurisdiction with less prescriptive compliance requirements. If your regulator accepts backend compliance documentation (common in some APAC and Middle Eastern jurisdictions), the added complexity of on-chain identity isn’t justified.
- You need on-chain document references. If maintaining a verifiable link between the token and its legal framework on-chain is important (some securities regulators require this), ERC-1400’s document management is a native feature.
Choose ERC-3643 when:
- You’re building under MiCA or similarly strict regulations. The on-chain compliance enforcement is the strongest technical evidence of transfer restriction enforcement available. MiCA’s Article 68 record-keeping requirements are natively satisfied.
- You need cross-jurisdictional compliance. The modular validator system lets you enforce different rules for different investor jurisdictions without contract modifications.
- Secondary market access matters. Full ERC-20 compatibility means your tokens can be listed on DEXs and supported by standard wallets without custom integration.
- You want lower long-term audit costs. On-chain compliance creates a self-documenting audit trail. You don’t need a separate system to log compliance checks – the blockchain does it for you.
Consider a hybrid approach when:
- You need both partitions AND on-chain compliance. Use ERC-1400 for the token structure (partitions, document management) and layer ERC-3643-style identity validation on top. This is the most complex approach but gives you the best of both worlds.
- You’re building a platform that serves multiple issuers with different needs. Some issuers need partitions, others need simple single-class tokens with strong compliance. A hybrid architecture supports both.
We’ve built all three configurations. The hybrid approach is more common than you’d expect roughly 40% of the regulated platforms we’ve shipped use some form of combined architecture.
What Changes With MiCA Phase 2 (2026)
MiCA’s second implementation phase, taking full effect in 2026, adds requirements that further tilt the decision toward on-chain compliance:
Mandatory compliance audit trails. CASPs must maintain five years of records showing that every transfer was compliance-checked. With ERC-3643, this is automatic. With ERC-1400, you need to build and maintain a separate logging system.
Supervisory access. Regulators may request real-time access to compliance data. On-chain data is accessible by default. Backend compliance data requires API access, server uptime, and data format standardization.
EMT stablecoin settlement. If your platform supports stablecoin payments (increasingly standard for institutional investors), the stablecoin must comply with MiCA’s EMT rules. ERC-3643’s compliance framework can extend to cover stablecoin settlement flows within the same identity infrastructure.
Cross-border passport. MiCA allows CASP authorization in one EU member state to be passported across the EU. This means your compliance framework must handle 27 jurisdictions. ERC-3643’s modular validator system is designed for exactly this, ERC-1400’s off-chain approach would require jurisdiction-specific backend logic.
Practical Considerations From Production Deployments
A few things we’ve learned from building with both standards that don’t show up in specification documents:
Claim issuer onboarding is the bottleneck for ERC-3643. Getting your KYC provider (Sumsub, Onfido, Veriff) to issue ONCHAINID claims requires integration work. Budget 2–4 weeks for this integration. Some KYC providers now offer ONCHAINID-compatible claim issuance natively; others require a custom adapter.
ERC-1400 partition naming matters. How you name and structure partitions has long-term implications. Changing partition structure after issuance is possible but painful.Iit requires migrating token holder positions. Get the partition design right upfront.
Both standards support upgradeable proxies. You’re not locked into the initial contract logic forever. Both ERC-1400 (via UniversalToken) and ERC-3643 (via T-REX) support proxy upgrade patterns. But: upgrades to compliance logic in production require careful governance. We use timelock mechanisms to give investors visibility before compliance rules change.
Gas costs become irrelevant on L2. If you’re deploying on Polygon, Base, or Arbitrum (which most new tokenization platforms do), the gas cost difference between ERC-1400 and ERC-3643 is negligible. Don’t let gas costs drive your standard choice on L2.
FAQ
Can I switch from ERC-1400 to ERC-3643 after launching? Technically yes, but it requires migrating all token holder positions to new contracts. This is disruptive and expensive. It’s better to choose the right standard upfront. If you’re unsure, the hybrid approach gives you the most flexibility.
Does ERC-3643 require every investor to have an on-chain identity? Yes, every wallet that holds ERC-3643 tokens must have an associated ONCHAINID with the required verified claims. This sounds burdensome, but in practice it’s handled during investor onboarding. The investor completes KYC, your system issues the claims to their ONCHAINID, and transfers work automatically from that point.
Which standard does Securitize / Tokeny / Polymath use? Tokeny developed ERC-3643 and uses it exclusively. Securitize originally backed ERC-1400 but has moved toward DS Protocol (their proprietary standard). Polymath originally championed ERC-1400 but pivoted to Polymesh (a separate chain). In practice, the choice is less about which vendor’s standard and more about which compliance model fits your regulatory environment.
Is CMTAT (Swiss standard) a viable alternative? CMTAT is developed by the Swiss Capital Markets and Technology Association and is gaining traction in Switzerland. It’s more lightweight than both ERC-1400 and ERC-3643, designed specifically for Swiss securities law. If you’re operating exclusively under Swiss regulation, it’s worth evaluating. For multi-jurisdiction platforms, ERC-3643’s modular compliance system is more flexible.
What about XRPL or Solana – do these standards apply? ERC-1400 and ERC-3643 are EVM-specific (Ethereum, Polygon, Arbitrum, Base). XRPL has its own token model with native trust lines and clawback. Solana uses SPL tokens with different compliance approaches. For multi-chain platforms, the EVM token standard handles the primary issuance while other chains are connected via bridges or parallel deployments.
Next Steps
If you’re building a tokenization platform and evaluating token standards:
→ Read: White-Label Tokenization Platform – Build, Buy, or Customize? – The full architecture guide for tokenization platforms in 2026.
→ See our case studies – How we’ve implemented both standards in production for Alior Bank, SOIL, and other institutional issuers.
→ Book an architecture call – 30 minutes to map your asset model and recommend the right standard for your regulatory environment.
Related articles:
- White-Label Tokenization Platform in 2026: Build, Buy, or Customize?
- MiCA Phase 2: Technical Checklist for Tokenization Platforms (coming soon)
- Tokenization Platform Architecture: What Actually Gets Built (coming soon)
