Meta Title: Token Standards for RWA: ERC-3643, ERC-1400, ERC-7518 Compared | Technical Spec Meta Description: Deep technical comparison of ERC-3643 (T-REX), ERC-1400, and ERC-7518 for real-world asset tokenization. Architecture, compliance models, identity systems, and migration paths for smart contract developers. Primary Keyword: RWA token standards Secondary Keywords: ERC-3643, T-REX, ERC-1400, ERC-7518, identity registry, compliance module URL Slug: /knowledge/token-standards-rwa-erc3643-erc1400-erc7518 Canonical: /knowledge/token-standards-rwa-erc3643-erc1400-erc7518
RWA Token Standards: The Technical Reality Behind the Hype
Tokenizing real-world assets (RWA) sounds simple on paper: represent a building, a bond, or a fund share as a token on Ethereum. The reality hits when you try to enforce KYC on a permissionless blockchain, handle forced transfers for court orders, or manage multiple share classes with different lockup periods in a single contract.
Three standards dominate this space: ERC-3643 (T-REX), ERC-1400, and ERC-7518. Only one has reached Final status. One has been Stale since 2018. The newest is still in Review. If you're building production RWA infrastructure in 2025, this distinction matters more than the feature lists in their READMEs.
Why Standard Token Standards Fail for Securities
ERC-20 works for utility tokens because transfers only need one check: balanceOf(sender) >= amount. Securities are different. A transfer can fail because:
- The receiver hasn't passed KYC
- The sender's tokens are locked until a vesting cliff
- The token contract enforces a maximum holder count (e.g., 2,000 investors for Reg D)
- A regulator has frozen the receiver's wallet
- The transfer exceeds a single-holder concentration cap (e.g., 10% max)
- The asset is in a jurisdiction-specific partition (Reg S vs Reg D)
ERC-20's transfer returns bool. Security tokens need canTransfer(from, to, amount, data) → (byte reasonCode, bytes32 partition, bytes32 extraData) — a rich result explaining why a transfer would fail, not just that it would fail.
ERC-3643 (T-REX): The Production Standard
Status: Final | Audited: Kaspersky, Hacken | TVL: $32B+
ERC-3643 is the only security token standard that has graduated to Final on the EIP track. Developed by Tokeny (now part of Apex Group), it's built on a six-contract architecture that separates concerns cleanly:
` Token (ERC-20 compatible) ├── Identity Registry → Identity Registry Storage (shared whitelist) ├── Compliance (rules engine) ├── Trusted Issuers Registry (claim issuers + topics) └── Claim Topics Registry (required claims for eligibility) `
Core Innovation: ONCHAINID Identity Framework
ERC-3643 doesn't just support identity — it mandates ONCHAINID. Every investor must have an Identity contract (ERC-735 claim holder) linked to their wallet. Claims (KYC passed, accredited investor, jurisdiction) are signed by trusted issuers stored in the TrustedIssuersRegistry. The ClaimTopicsRegistry defines which claim topics (e.g., 1 = KYC, 2 = Accredited, 3 = Jurisdiction:US) are required.
`solidity // Simplified transfer logic from ERC-3643 function transfer(address _to, uint256 _amount) public override whenNotPaused returns (bool) { require(!_frozen[_to] && !_frozen[msg.sender], "Frozen wallet"); require(_amount <= balanceOf(msg.sender) - _frozenTokens[msg.sender], "Insufficient free balance"); require(_tokenIdentityRegistry.isVerified(_to), "Invalid identity"); // ONCHAINID check require(_tokenCompliance.canTransfer(msg.sender, _to, _amount), "Compliance failure"); _transfer(msg.sender, _to, _amount); _tokenCompliance.transferred(msg.sender, _to, _amount); return true; } `
The isVerified Check
isVerified(address investor) returns true only if:
- Investor's wallet is registered in the
IdentityRegistry - Their
Identitycontract holds all required claims fromClaimTopicsRegistry - Each claim is signed by an issuer in
TrustedIssuersRegistry - Claims haven't expired
This is on-chain KYC enforcement — no off-chain oracle needed for the verification itself.
Agent Role: Automation Without Owner Keys
The IAgentRole interface (required on Token, IdentityRegistry, Compliance, IdentityRegistryStorage) lets the owner appoint automated systems as agents:
`solidity interface IAgentRole { event AgentAdded(address indexed _agent); event AgentRemoved(address indexed _agent); function addAgent(address _agent) external; function removeAgent(address _agent) external; function isAgent(address _agent) external view returns (bool); } `
An agent can be a smart contract that auto-mints on subscription, auto-burns on redemption, or freezes wallets flagged by a compliance oracle — all without the owner's private key leaving cold storage.
Recovery: Lost Keys Aren't Lost Assets
`solidity function recoveryAddress( address _lostWallet, address _newWallet, address _investorOnchainID ) external returns (bool); `
The issuer (or authorized agent) can migrate an investor's balance to a new wallet, provided the investor proves ownership of their ONCHAINID. A RecoverySuccess event creates an immutable audit trail.
Batch Operations: Gas Efficiency at Scale
`solidity function batchTransfer(address[] calldata _toList, uint256[] calldata _amounts) external; function batchForcedTransfer(address[] calldata _fromList, address[] calldata _toList, uint256[] calldata _amounts) external; function batchMint(address[] calldata _toList, uint256[] calldata _amounts) external; `
Critical for fund administrators processing hundreds of investor transactions in a single block.
Trade-offs
| Pros | Cons |
|---|---|
| Final standard, audited, $32B+ live assets | Mandatory ONCHAINID = vendor dependency |
| Clear separation of concerns (6 contracts) | 2-3x gas cost vs ERC-20 transfer |
| Built-in recovery, freezing, pausing | No native partition support for share classes |
| Agent role enables automation | Compliance rules require custom contract per jurisdiction |
| ERC-20 compatible (wallets, explorers work) | Cross-chain = re-verify identity on destination |
ERC-1400: The Ambitious Umbrella That Stalled
Status: Draft (Stale since 2018) | Components: ERC-1410, ERC-1594, ERC-1643, ERC-1644
ERC-1400 isn't a single contract — it's a suite of four interdependent EIPs that together form a comprehensive security token framework:
| Sub-standard | Purpose | Key Interface |
|---|---|---|
| ERC-1410 | Partially Fungible Tokens (partitions) | balanceOfByPartition, partitionsOf, transferByPartition |
| ERC-1594 | Core Security Token (transfer gates) | canTransfer, canTransferByPartition, transferWithData |
| ERC-1643 | Document Management | getDocument, setDocument, Document event |
| ERC-1644 | Controller Operations | isControllable, controllerTransfer, controllerRedeem |
Partially Fungible Tokens (ERC-1410): The Partition Model
ERC-1410 introduces bytes32 partitions — logical tranches within a single token contract:
`solidity function balanceOfByPartition(bytes32 _partition, address _tokenHolder) external view returns (uint256); function partitionsOf(address _tokenHolder) external view returns (bytes32[]); function transferByPartition( bytes32 _partition, address _to, uint256 _value, bytes _data ) external returns (bytes32 _toPartition); `
Example: A real estate fund has two partitions:
0x01= "Class A - Primary Issuance" (12-month lockup)0x02= "Class B - Secondary Trading" (no lockup)
An investor's total balance = balanceOfByPartition(0x01, investor) + balanceOfByPartition(0x02, investor). Transfers specify the source partition; the contract determines the destination partition (returned as bytes32).
Transfer Validation with Reason Codes (ERC-1594)
`solidity function canTransfer( address _to, uint256 _value, bytes _data ) external view returns (byte, bytes32); // Returns: reasonCode (EIP-1066), destinationPartition
function canTransferByPartition( address _from, address _to, bytes32 _partition, uint256 _value, bytes _data ) external view returns (byte, bytes32, bytes32); // Returns: reasonCode, fromPartition, toPartition `
The _data parameter accepts off-chain signatures (e.g., broker approval, KYC attestation). The byte reason code follows EIP-1066:
0x50= transfer failure0x51= transfer success0x55= funds locked (lockup period)0x57= invalid receiver (KYC failed)
Controller Operations (ERC-1644): Legal Enforcement
`solidity function isControllable() external view returns (bool); function controllerTransfer( address _from, address _to, uint256 _value, bytes _data, bytes _operatorData ) external; function controllerRedeem( address _tokenHolder, uint256 _value, bytes _data, bytes _operatorData ) external; `
If isControllable() == true, the controller (issuer, regulator, transfer agent) can force transfers without the holder's approval. Events ControllerTransfer and ControllerRedemption flag these for audit trails.
Why It Stalled
- Complexity explosion: Four EIPs, each with multiple interfaces, create integration burden
- No reference implementation reached production — the SecurityTokenStandard repo has 115 stars but few production deployments
- ERC-3643 shipped first with a working product (Tokeny's T-REX platform)
- Partition model on ERC-20 base is gas-inefficient vs ERC-1155 native partitions
- Stale label on GitHub issues signals community consensus: move on
When You Might Still Use It
- Legacy systems already built on ERC-1400 (migration cost > rebuild cost)
- Need document management (
ERC-1643) without full compliance suite - Jurisdiction requires specific controller patterns ERC-1644 models well
ERC-7518 (DyCIST): The Modern Challenger
Status: Review | Base: ERC-1155 | Authors: Zoniqx Team
ERC-7518 learns from both predecessors. It uses ERC-1155's native tokenId as the partition primitive — no separate partition standard needed. Each tokenId = a distinct partition with its own compliance rules, lockup schedule, and payout rights.
Partition = tokenId: Native Semi-Fungibility
`solidity // ERC-1155 balanceOf(account, id) becomes partition balance function transferableBalance(address account, uint256 id) external view returns (uint256); // balanceOf - lockedBalanceOf function lockedBalanceOf(address account, uint256 id) external view returns (uint256); `
Partition use cases:
id = 1: "Reg D - US Accredited" (transfer restricted to KYC'd US investors)id = 2: "Reg S - Non-US" (different KYC rules)id = 3: "Founder Shares" (24-month lockup, voting rights)id = 4: "Preferred Series A" (liquidation preference, quarterly dividends)
All in one contract. No partition registry, no bytes32 mapping — just ERC-1155 id.
Voucher-Based Compliance: Off-Chain Rules, On-Chain Enforcement
ERC-7518's breakthrough is decoupling compliance logic from the token contract:
`solidity function canTransfer( address from, address to, uint256 id, uint256 amount, bytes calldata data ) external view returns (bool status); `
The data parameter carries an EIP-712 signed voucher from an off-chain compliance service:
`javascript // Off-chain compliance service generates voucher const voucher = { from: "0x123...", to: "0x456...", id: 1, // Reg D partition amount: 1000, expiry: 1735689600, nonce: 0xabc... };
// Signed by compliance service's EIP-712 key const signature = await complianceSigner.signTypedData(domain, types, voucher);
// User submits transfer with voucher in data await token.safeTransferFrom(from, to, id, amount, abi.encode(voucher, signature)); `
The canTransfer function:
- Verifies voucher signature
- Checks expiry, nonce, parameter binding
- Evaluates on-chain rules (frozen, restricted, locked)
- Returns
trueonly if all pass
Why this matters: Compliance rules can change (new regulation, updated sanction list) without redeploying the token contract. The off-chain service updates its logic; the on-chain gate stays the same.
Native Features ERC-3643 Lacks
| Feature | ERC-7518 | ERC-3643 |
|---|---|---|
| Time-based locking | lockTokens(account, id, amount, releaseTime) | ❌ Custom compliance module |
| Partition restrictions | restrictTransfer(id) / removeRestriction(id) | ❌ Custom compliance module |
| Payouts | payout(to, amount) / batchPayout(to[], amount[]) | ❌ Custom distribution contract |
| Interoperability | wrapToken, wrapTokenFromPartition, unwrapToken | ❌ |
| Cross-standard wrapping | Wraps ERC-20, ERC-721, ERC-1400 | ❌ |
Wrapping: The Migration Bridge
`solidity // Wrap ERC-20 security token → ERC-7518 partition function wrapToken(uint256 amount, bytes calldata data) external returns (bool);
// Wrap from specific partition of ERC-1400/ERC-3525 → ERC-7518 function wrapTokenFromPartition( bytes32 partitionId, uint256 id, uint256 amount, bytes calldata data ) external returns (bool);
// Unwrap back to original standard function unwrapToken(uint256 wrappedTokenId, uint256 amount, bytes calldata data) external returns (bool); `
This enables gradual migration: keep legacy ERC-1400 tokens for existing holders, issue new ERC-7518 partitions for new investors, wrap/unwap as needed.
Three-Contract Reference Architecture
` erc1155mod.sol (Base Ledger) └── ERC-1155 with partition = tokenId ├── mint/burn per partition └── balanceOf(account, partitionId)
STObasev2.sol (Security Token Offering) └── Sale lifecycle: pricing, settlement, investor onboarding └── Transfers purchased partitions to investors
erc7518.sol (Vault + Wrapper + Compliance Gateway) ├── Wraps external tokens (ERC-20, ERC-721, ERC-1400) ├── Pre-transfer gate: calls canTransfer(voucher) ├── Delegates balance management to erc1155mod └── Handles payouts, locking, freezing, force transfer `
Trade-offs
| Pros | Cons |
|---|---|
| Native partitions (ERC-1155) = gas efficient | Still in Review — spec may change |
| Voucher-based compliance = flexible, upgradable | Requires off-chain compliance service infrastructure |
| Native locking, payouts, wrapping | No mandatory identity standard (build your own) |
| Cross-standard interoperability | Smaller ecosystem, fewer audits |
| Single contract for multi-class assets | GPL-3.0 license (viral — may deter proprietary use) |
Head-to-Head Comparison
| Dimension | ERC-3643 (T-REX) | ERC-1400 | ERC-7518 (DyCIST) |
|---|---|---|---|
| EIP Status | ✅ Final | ⚠️ Draft (Stale) | 🔄 Review |
| Base Standard | ERC-20 | ERC-20/777 | ERC-1155 |
| Partition Model | ❌ None | ERC-1410 (bytes32) | Native (tokenId) |
| Identity System | ONCHAINID (mandatory) | Agnostic | Agnostic |
| Compliance Model | On-chain Compliance contract | canTransfer + off-chain data | Voucher-based (EIP-712) |
| Transfer Gas (est.) | ~85,000 | ~95,000 | ~75,000 |
| Forced Transfer | ✅ forcedTransfer | ✅ controllerTransfer | ✅ forceTransfer |
| Freezing | Address + partial tokens | Address (via partition) | Address + partition restrict |
| Time Locks | ❌ Custom module | Via partition metadata | ✅ lockTokens/unlockToken |
| Payouts | ❌ Custom | ❌ Custom | ✅ payout/batchPayout |
| Wrapping/Interop | ❌ | ❌ | ✅ ERC-20/721/1400 |
| Audit Status | Kaspersky, Hacken | None known | Not yet |
| Production TVL | $32B+ | Minimal | Pilot only |
| License | MIT (via Tokeny) | MIT | GPL-3.0 |
Decision Framework: Which Standard for Your Project?
Choose ERC-3643 If:
- Production deployment in EU/US regulated markets (MiCA, Reg D/Reg S)
- Team lacks compliance infrastructure — Tokeny's T-REX Engine provides off-the-shelf KYC/AML, investor onboarding, cap table management
- Identity standardization matters — ONCHAINID gives you a vetted, interoperable identity layer
- Audit trail is non-negotiable — Kaspersky/Hacken audits, $32B TVL proves battle-testing
- Timeline: need to launch in <3 months
Choose ERC-7518 If:
- Complex multi-class asset (real estate with floor-by-floor ownership, fund with 5+ share classes)
- Cross-standard interoperability needed — wrapping ERC-20/ERC-1400 legacy tokens
- Dynamic compliance — regulations change frequently, you need off-chain rule updates without redeploy
- Native payouts/locking — dividend distributions, vesting schedules built-in
- Team has compliance engineering capacity — you'll build the voucher service
- Timeline: 6+ months (spec may evolve)
Avoid ERC-1400 For New Projects Because:
- Stale since 2018 — no Final milestone in 7 years
- Gas inefficient — partitions on ERC-20 base cost more than ERC-1155 native
- Fragmented implementation — four EIPs, no unified reference deployment
- Migration path exists — ERC-7518's
wrapTokenFromPartitiontargets ERC-1400 specifically
Migration Paths: From Legacy to Modern
ERC-1400 → ERC-7518 (Recommended)
`solidity // 1. Deploy ERC-7518 contract with matching partitions // 2. For each ERC-1400 partition: token7518.wrapTokenFromPartition( partitionId, // ERC-1400 bytes32 partition tokenId, // ERC-7518 target partition (tokenId) amount, abi.encode(erc1400TokenAddress, investorAddress) );
// 3. Investor calls unwrap on ERC-7518 to retrieve original if needed // 4. Decommission ERC-1400 contract after full migration `
ERC-20 → ERC-3643 (Re-issuance Required)
ERC-3643 cannot wrap ERC-20 — the identity/compliance architecture is fundamentally different. Standard path:
- Snapshot ERC-20 holders
- KYC each holder via ONCHAINID
- Deploy ERC-3643 token
batchMintto verified investors- Burn old ERC-20 (or freeze permanently)
Gas Cost Reality Check
| Operation | ERC-3643 | ERC-1400 | ERC-7518 |
|---|---|---|---|
| Simple transfer (compliant) | ~85,000 | ~95,000 | ~75,000 |
| Transfer with voucher verification | N/A | ~120,000 | ~95,000 |
| Mint (single) | ~65,000 | ~70,000 | ~55,000 |
| Batch mint (100 recipients) | ~280,000 | ~320,000 | ~250,000 |
| Force transfer | ~70,000 | ~80,000 | ~65,000 |
| Freeze address | ~45,000 | ~50,000 | ~40,000 |
| Lock tokens (ERC-7518 only) | N/A | N/A | ~55,000 |
| Wrap token (ERC-7518 only) | N/A | N/A | ~110,000 |
Estimates based on Foundry gas snapshots, Ethereum mainnet, 2024 prices. Actual costs vary with compliance complexity.
Vietnam Context: Where RWA Tokenization Stands
Vietnam's RWA tokenization is in early stages but accelerating:
- Regulatory: MOF (Ministry of Finance) drafting securities tokenization framework; SBV cautious on crypto but supportive of blockchain for securities settlement
- Real estate: Proptech startups (RedSwan Vietnam, local pilots) exploring fractional ownership via tokenization
- Corporate bonds: VNDIRECT, SSI Securities piloting tokenized bond issuance on private chains
- Identity: VNeID (national digital ID) could integrate with ONCHAINID or custom registries for KYC
Practical recommendation for Vietnam teams: Start with ERC-3643 on Polygon or Base (lower gas, EVM-compatible). Use Tokeny's T-REX Engine for KYC/AML — it integrates with global providers and can plug in VNeID verification. Migrate to ERC-7518 when you need multi-class assets or cross-chain distribution.
Implementation Checklist for Smart Contract Devs
ERC-3643 Deployment
- [ ] Deploy ONCHAINID identity contracts for issuer, agents, compliance service
- [ ] Deploy IdentityRegistryStorage (shared whitelist)
- [ ] Deploy IdentityRegistry per token (links to storage, sets trusted issuers, claim topics)
- [ ] Deploy Compliance contract (configure max holders, concentration caps, allowed countries)
- [ ] Deploy Token contract (link registry, compliance, ONCHAINID)
- [ ] Register trusted claim issuers (KYC providers, accreditation verifiers)
- [ ] Define claim topics (1=KYC, 2=Accredited, 3=Jurisdiction, etc.)
- [ ] Appoint agents (automated mint/burn/freeze contracts)
- [ ] Test
recoveryAddressflow on testnet - [ ] Audit custom Compliance module if not using Tokeny's
ERC-7518 Deployment
- [ ] Deploy
erc1155mod(base ledger) - [ ] Deploy
erc7518(vault + wrapper + compliance gateway) - [ ] Deploy
STObasev2if running primary offering - [ ] Implement
canTransferwith voucher verification (EIP-712) - [ ] Deploy off-chain compliance service (signs vouchers)
- [ ] Define partitions (tokenIds) for each share class/jurisdiction
- [ ] Configure wrapping targets (ERC-20/1400 addresses if migrating)
- [ ] Test partition merge/split flows
- [ ] Audit
forceTransferaccess control (multi-sig required)
FAQ
Can I use ERC-3643 without ONCHAINID?
No. The EIP requires an on-chain identity system compatible withIIdentity (ERC-735) and IClaimIssuer. ONCHAINID is the reference implementation. You could build a compatible alternative, but you'd lose the ecosystem tooling (Tokeny dashboard, DINO network, wallet integrations).
Does ERC-7518's GPL-3.0 license affect my proprietary frontend?
GPL-3.0 applies to the smart contract code. If you fork/modifyerc7518.sol and deploy it, you must open-source your contract modifications. Your off-chain frontend, compliance service, and infrastructure remain proprietary. Consult legal counsel for your jurisdiction.
How do I handle cross-chain compliance with ERC-3643?
ERC-3643 has no native cross-chain support. Options:- Re-verify on destination: Bridge tokens → new ERC-3643 on target chain → re-run KYC
- Lock/mint: Lock on source, mint wrapped version on destination with compliance oracle
- Use ERC-7518 wrapping: Wrap ERC-3643 → ERC-7518 → bridge → unwrap on destination (experimental)
What's the gas cost of canTransfer with a voucher?
~95,000 gas on ERC-7518 (includes EIP-712 ecrecover). The voucher signature verification is ~3,000 gas. The rest is compliance rule evaluation. Compare to ERC-3643's ~85,000 for on-chain compliance check — similar, but ERC-7518's rules live off-chain.
Can ERC-1400 partitions map 1:1 to ERC-7518 partitions?
Yes. ERC-7518'swrapTokenFromPartition(bytes32 partitionId, ...) is designed for this. Each ERC-1400 bytes32 partition becomes an ERC-7518 uint256 tokenId. Map them in your migration script.
Conclusion: The Standard Is Only the Starting Point
Choosing a token standard is the easiest decision in RWA tokenization. The hard work is:
- Building the compliance service that issues vouchers (ERC-7518) or configures rules (ERC-3643)
- Integrating KYC/AML providers that work in your target jurisdictions
- Designing the legal structure (SPV, fund, direct ownership) that the token represents
- Getting regulators comfortable with your on-chain enforcement model
- Building investor tooling: dashboards, transfer wizards, tax reporting
My recommendation for 2025:
- New regulated securities issuance → ERC-3643 + Tokeny T-REX Engine (fastest to compliant production)
- Complex multi-class assets, cross-chain needs → ERC-7518 (invest in compliance service engineering)
- Existing ERC-1400 deployment → Migrate to ERC-7518 via wrapping
The standards will evolve. The compliance infrastructure you build around them is your moat.
This article is part of the VCC Technical Spec series for smart contract developers. For implementation code samples, see the accompanying GitHub repository. For Vietnamese translation, visit /vi/knowledge/token-standards-rwa-erc3643-erc1400-erc7518.