When a tokenized asset issuer asks "which token standard should we use?", they're really asking three questions: How do we enforce compliance on-chain? How do we handle investor identity? And which standard gives us the best path to institutional adoption? The answer varies by program structure — but the comparison almost always comes down to ERC-3643 (T-REX), ERC-1400, and the simpler ERC-20 extension approach.
This piece breaks down each standard's compliance architecture, transfer restriction implementation, identity handling, and where each fits best in 2026.
The Comparison at a Glance
| Standard | Compliance Built-In | Transfer Restrictions | Identity Registry | Ecosystem Adoption |
|---|---|---|---|---|
| ERC-3643 (T-REX) | Yes — modular compliance contract | Pre-transfer hook, reverts on fail | On-chain identity registry (ONCHAINID) | Strongest institutional (Tokeny, major issuers) |
| ERC-1400 | Partial — transfer validation interface | canTransfer() check, tranche-aware | Off-chain or custom on-chain | Moderate (Polymath, St20, early programs) |
| ERC-20 Extension | No — custom override of transfer() | Manual allowlist in transfer() override | None standard — fully custom | Widest tooling, but compliance not standard |
ERC-3643 (T-REX): The Institutional Standard
ERC-3643, commonly referred to as T-REX (Token for Regulated EXchanges), was developed by Tokeny Solutions and proposed as an EIP in 2023. It's now the most widely deployed standard for institutional tokenized securities — particularly in Europe, where MiCA compliance drives many architectural decisions.
How Compliance Works
T-REX has a four-contract architecture: the token contract, a modular compliance contract, an identity registry, and an identity registry storage layer. Every transfer goes through the compliance contract before execution. The compliance contract is composed of modules — each module enforces one rule (country restrictions, max investor count, holding periods, supply limits). You add or remove modules without redeploying the token.
This modularity is T-REX's main architectural advantage. A single token contract can have compliance rules that change as the regulatory environment evolves. Adding MiCA-required restrictions after initial deployment is an admin transaction, not a contract migration.
Identity Registry: ONCHAINID
T-REX uses ONCHAINID — a decentralized identity system where each investor has an on-chain identity contract containing verified claims. Claims are attestations issued by trusted claim issuers (your KYC provider, your legal counsel, a government-approved verifier). The compliance module checks whether the receiving address's identity contract holds the required claims for the transfer type.
This is meaningfully different from a simple allowlist. An allowlist tells you "this address is permitted." ONCHAINID tells you "this address has verified KYC from provider X, holds accredited investor status attested by provider Y, and is in an eligible jurisdiction." When an investor re-verifies or when their attributes change, the claim updates on their identity contract — the token contract doesn't need to change.
Gas Costs and Trade-offs
T-REX transfers cost more gas than a plain ERC-20 transfer because each transfer queries the compliance contract and the identity registry. In practice, this means 150,000-300,000 gas per transfer versus ~21,000 for a simple ETH transfer. On high-throughput secondary markets, this cost accumulates. On Ethereum mainnet at peak congestion, this matters. On L2s (Polygon, Arbitrum, Base), where most institutional RWA programs run, it's largely irrelevant.
The bigger operational cost is registry maintenance. Every investor needs an ONCHAINID-compatible identity contract with current claims. Initial onboarding and ongoing claim management requires integration with your KYC provider and a pipeline to update on-chain identity state when off-chain verification changes.
Best for:
- Programs targeting European distribution (MiCA alignment)
- High investor count programs where claim-based identity beats per-investor allowlist updates
- Programs that need evolving compliance rules post-launch
- Issuers working with Tokeny or other T-REX infrastructure providers
ERC-1400: The Security Token Framework
ERC-1400 predates T-REX and takes a different approach: it defines a standard interface for security tokens without prescribing implementation. It introduced partition/tranche awareness (different token classes with different rules in one contract) and a standardized transfer validation interface (canTransfer() / canTransferByPartition()).
How Compliance Works
ERC-1400 defines the interface — the canTransfer() function that returns a bytes1 status code (0x51 = transfer allowed, 0x50 = transfer blocked) and a bytes32 application-specific reason code. The implementation of what goes inside canTransfer() is entirely up to the issuer. You can check an on-chain allowlist, call an off-chain oracle, query a custom registry — ERC-1400 doesn't care.
This flexibility is also the problem. ERC-1400 programs written by different teams have incompatible compliance implementations. There's no standard for what the identity data looks like or where it lives. Two ERC-1400 tokens can look identical at the interface level while having completely different (and potentially incompatible) compliance architectures underneath.
Partition / Tranche Support
ERC-1400's standout feature is first-class tranche support. A single contract can issue multiple token classes — common and preferred shares, Class A and Class B units, locked and unlocked tranches — with different compliance rules per tranche. This maps well to traditional capital structure: different investor tiers with different liquidity rights in the same token program.
T-REX's modular compliance can approximate this, but ERC-1400's tranche model is cleaner for multi-class structures. Issuers with complex capital tables (multiple equity classes, structured credit tranches) often find ERC-1400's native tranche handling simpler to model.
Ecosystem and Adoption
ERC-1400 was the primary standard for early institutional tokenization programs (2018-2022) through Polymath and Harbor. Most of those programs have since migrated or are moving toward T-REX or proprietary implementations. ERC-1400's tooling ecosystem is less active in 2026 than T-REX's, and major infrastructure providers (Tokeny, Securitize, Aurus) have standardized on T-REX or proprietary standards.
It remains relevant for programs built on Polymath's infrastructure and for issuers who need the tranche model and don't want to use T-REX.
Best for:
- Programs with complex tranche or partition requirements (multi-class equity, structured credit)
- Teams already on Polymath or ERC-1400 infrastructure
- Issuers who want standards-level interface compliance with custom implementation flexibility
ERC-20 Extensions: Simple but Costly to Maintain
Some programs use plain ERC-20 tokens with compliance logic added via overrides to the transfer() and transferFrom() functions. The compliance check (allowlist, basic KYC gate, jurisdiction block) is hardcoded or references an on-chain mapping maintained by the issuer.
How Compliance Works
It's simple: override transfer() to check require(allowlist[to], "recipient not approved") before executing the transfer. Add a function for the contract owner to add or remove addresses from the allowlist. Deploy. Done.
For small programs with few investors and stable compliance requirements, this works. The gas cost is minimal. The code is simple and auditable. Any Solidity developer can maintain it.
Where It Breaks Down
The ERC-20 extension approach doesn't scale operationally. Each new investor requires an on-chain transaction to add their address to the allowlist. Each compliance change (removing an expired investor, adding a jurisdiction restriction) is a separate transaction. For programs with 100+ investors and active compliance management, this becomes expensive and error-prone.
More critically: ERC-20 extensions have no standard. Every implementation is custom. There's no ecosystem of tooling, no standard way for wallets or exchanges to understand that a token has compliance requirements. Integration partners (DEXs, custody providers, analytics platforms) have no standard interface to query.
The compliance architecture in the AndxOS compliance dashboard is designed around ERC-3643 and ERC-1400 event schemas. For ERC-20 extension programs, compliance data integration requires custom indexing.
Best for:
- Very small programs (under 50 investors) with stable, simple compliance rules
- Proof-of-concept programs where development speed matters more than compliance infrastructure
- Programs that don't anticipate secondary market trading
Gas Costs and L2 Considerations
The gas cost comparison that matters is not token transfer cost in isolation — it's the full operational gas budget across the program lifecycle. On Ethereum mainnet:
- ERC-20 extension transfer: ~30,000-50,000 gas (simple allowlist check)
- ERC-1400 transfer: ~80,000-120,000 gas (canTransfer() evaluation)
- ERC-3643 transfer: ~150,000-300,000 gas (compliance module + identity registry query)
On Ethereum mainnet at $50 gas price and ETH at $3,000, each T-REX transfer costs roughly $0.10-$0.20 in gas. At high trading volumes, this adds up. On Polygon, the same transfer costs under $0.001. The L2 economics make T-REX's higher-than-ERC20 gas cost effectively irrelevant for most institutional programs — and all major RWA infrastructure providers have launched L2 deployments.
The more important gas cost to model is registry management: adding investors to an ONCHAINID system, issuing claims, updating compliance module parameters. These are one-time or infrequent operations, but they add up in large programs. Budget for this upfront.
Regulatory Alignment in 2026
From a regulatory standpoint, token standard selection matters less than the compliance infrastructure that runs on top of it. Regulators care about outcomes: are investors verified? Are transfer restrictions enforced? Is there an audit trail? The standard is the mechanism — the outcomes are what matter.
That said, ERC-3643 has the clearest regulatory alignment story in 2026:
- MiCA (EU): T-REX's ONCHAINID system maps naturally to MiCA's requirements for investor verification and transfer restriction enforcement. Tokeny's infrastructure has been explicitly developed with MiCA compliance in mind.
- SEC (US): No explicit standard preference. The SEC cares about whether restricted securities have effective transfer controls — which all three approaches can provide if implemented correctly.
- FATF Travel Rule: Requires transfer originator/beneficiary data for covered transfers. T-REX's identity architecture makes this data available on-chain; ERC-20 extensions typically require off-chain supplementation.
Multi-Standard Infrastructure
Most institutional RWA programs don't run on a single standard. An issuer may use ERC-3643 for a primary tokenized debt offering targeting European investors, ERC-1400 for a multi-tranche equity program, and ERC-20 extensions for an internal treasury management token that never hits secondary markets.
The operational implication is that infrastructure needs to handle multiple standards. Compliance dashboards, investor registries, transfer monitors, and analytics systems can't assume a single token contract shape. This is one of the design principles behind AndxOS's multi-standard architecture — the compliance tracking, exchange analytics, and investor registry layers are designed to ingest events from ERC-3643 and ERC-1400 programs without requiring issuers to standardize on a single token type.
Choosing the Right Standard
The decision framework is straightforward:
- Start with your investor base and compliance requirements. If you need on-chain identity (not just allowlists) and expect compliance requirements to evolve, ERC-3643 is the right architecture. If you need complex tranche structures, ERC-1400 deserves serious consideration.
- Evaluate your infrastructure partners. If you're using Tokeny, you're using T-REX. If you're on Polymath, you're using ERC-1400. The standard often follows the infrastructure choice.
- Consider secondary market path. Programs planning active secondary trading need a standard that exchange infrastructure and custody providers already support. T-REX has the most institutional exchange integrations in 2026.
- Don't let simplicity bias toward ERC-20 extensions for production programs. The operational costs of maintaining a custom allowlist-based system at scale routinely exceed the development costs of building on T-REX properly.
The standard is not the hard part. The identity registry design, the compliance rule specification, and the operational processes for maintaining them — that's where programs succeed or fail.