It's a stack, not a single standard
The first mistake is treating the choice as one decision. A security token needs the market to recognize the asset, a way to know who may hold it, a contract that represents it, data about what it's worth, and sometimes a way to move across chains. Each of those problems has its own standards, and they relate to each other in two different ways:
- Between layers, by dependency. ERC-3643 requires an identity system; an ERC-7540 fund needs a NAV source. These are relationships between layers, not inheritance.
- Inside the token layer, by inheritance. ERC-3643 extends ERC-20; ERC-7540 extends ERC-4626. That's where a real family tree exists.
That's why a single tree for everything misleads: MiCA isn't a parent of ERC-3643, and ONCHAINID isn't a child of ERC-20. Below we go layer by layer, and draw the tree only where the inheritance is real.
Layer 1: legal and regulatory frame
It isn't a technical standard, but it conditions all the others: it decides whether the token is a financial instrument, who can buy it and which transfer restrictions it must enforce. The regimes that come up most often:
| Regime | Scope | What it means for the token |
|---|---|---|
| MiCA (EU) | Crypto-assets that are not financial instruments | Tokenized securities are out of its scope; they stay under MiFID II |
| MiFID II + DLT Pilot Regime (EU) | Financial instruments; Regulation 2022/858, applicable since March 2023 | Lets DLT market infrastructures trade and settle tokenized securities under specific exemptions |
| Reg D, Reg S, Reg A+ (US) | Private placements, offshore offerings and small public offerings | Define investor eligibility and resale lock-ups that the contract must enforce |
| SCA and VARA (UAE, onshore) | Federal security tokens and commodity token contracts (SCA Decision 15/RM/2025); in Dubai, virtual assets including asset-referenced ones (ARVA) under VARA | Security tokens must trade and settle on a licensed market or ATS; an ARVA backed by non-security assets follows VARA's issuance rulebook instead |
| DFSA (DIFC) and FSRA (ADGM), UAE free zones | Their own financial regimes: Investment Tokens in the DIFC, digital securities in ADGM | A tokenized security is regulated as a security; the free zone you choose defines the rulebook and the license |
The technical point: every restriction the lawyer defines (eligible countries, accredited investors only, holding periods) has to end up as a rule the token enforces on-chain. Deciding those rules is the securities lawyer's job, not ours or the standard's.
Layer 2: asset identifiers
A token also has to be legible to traditional market infrastructure: custodians, transfer agents, reporting systems. For that, the ISO identifiers still apply:
| Standard | Identifies | Why it matters on-chain |
|---|---|---|
| ISIN (ISO 6166) | The security | The token is the same security; the ISIN usually lives in the token metadata |
| CFI (ISO 10962) | The instrument type | Classifies the instrument (equity, debt, fund unit) for reporting |
| DTI (ISO 24165) | The digital token and its ledger | Links a specific contract on a specific network to its ISIN |
| LEI (ISO 17442) | The legal entity (issuer, SPV) | Identifies who issues and who the counterparty is |
| ISO 20022 | Financial messaging | How the payment and settlement side talks to banks |
In practice, a contract address alone isn't an identifier the market recognizes. The ISIN and DTI pair is what connects the token to the traditional world.
Layer 3: identity and KYC
A permissioned token needs to know whether a wallet belongs to a verified, eligible person, without putting personal data on-chain. Two families of standards solve it.
ONCHAINID is the identity system ERC-3643 uses. It's based on ERC-734 (key management) and ERC-735 (claims), two proposals that never became final EIPs but run in production through ONCHAINID. Each investor has an identity contract holding claims signed by a trusted issuer (your KYC provider), such as "passed KYC" or "accredited investor." What lives on-chain is the proof, not the data.
W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) are the web-wide standard for the same idea: credentials issued by a trusted party that the holder presents and anyone can verify. They're more common off-chain and outside the EVM, and they can feed an on-chain claim.
The architecture decision here is where eligibility is checked: on every transfer (on-chain claims) or once, before a wallet is enabled (a registry or an allowlist). Both are valid; they differ in cost, privacy and how portable the identity is across tokens.
Layer 4: token standards, the family tree
The three roots
ERC-20 (fungible), ERC-721 (non-fungible) and ERC-1155 (multi-token) are the bases. None of them has compliance: they circulate freely. Almost every real-world asset standard extends one of the three.
Permissioned securities
ERC-3643 (T-REX), Final. An ERC-20 with an identity registry, a claim topics registry, trusted issuers and a modular compliance contract. Transfers to ineligible wallets revert. It includes freezing, forced transfers and wallet recovery, and it's the most mature option for tokenized securities on the EVM. We cover it in detail in Why ERC-3643 and not a plain token.
The ERC-1400 family, never finalized. ERC-1410 (partitions), ERC-1594 (issuance and redemption with transfer validation), ERC-1643 (documents) and ERC-1644 (controller operations). It was proposed in 2018 as GitHub issues and never entered the official ERC repository. It's still cited everywhere and has deployments, but it isn't a finalized standard, a detail many comparisons skip. Its ideas (partitions, attached documents) live on in newer standards.
ERC-7518 (DyCIST), in Review. A security token built on ERC-1155 with semi-fungible partitions: each token ID can represent a class or tranche with its own rules, and it includes provisions for cross-chain compliance. Worth watching; not final yet.
ERC-7943 (uRWA), Final. The newest and the most minimal. It doesn't prescribe how compliance is done, only the interface: canTransfer, canSend, canReceive, setFrozenTokens, getFrozenTokens and forcedTransfer, with variants for ERC-20, ERC-721 and ERC-1155. Its value is interoperability: a DeFi protocol or a wallet can ask any real-world asset token "can this transfer happen?" without knowing its internal logic. It doesn't compete with ERC-3643 so much as sit on top of it: a token with full compliance logic can also expose the uRWA interface.
Funds and vaults
ERC-4626, Final. The standard for tokenized vaults: you deposit an asset and receive shares, with a standard exchange rate between them. ERC-7540, Final, extends it with asynchronous requests: deposits and redemptions are requested now and settled later. That's exactly how a real fund works (subscriptions and redemptions at the next NAV cut-off), which is why ERC-7540 is the reference for tokenized funds and private credit.
Structured instruments
ERC-3525, Final. Semi-fungible: each token has an ID, a slot and a value, and tokens in the same slot are fungible with each other. It fits bonds with different maturities or tranches. ERC-6960 (dual-layer token) goes in a similar direction, with main categories and sub-categories of assets, but it's still a Draft.
The status of a standard isn't a detail. "Final" means the interface won't change; "Review" or "Draft" means it still can; and "never an EIP" means there's no official specification to audit against.
| Standard | Extends | What it adds | Status |
|---|---|---|---|
| ERC-3643 | ERC-20 | Identity, compliance, freezing, forced transfer | Final |
| ERC-1400 family | ERC-20 | Partitions, documents, controller | Never an EIP |
| ERC-7518 | ERC-1155 | Partitions, dynamic compliance, cross-chain | Review |
| ERC-7943 | ERC-20, 721 or 1155 | Minimal compliance interface | Final |
| ERC-4626 | ERC-20 | Vault shares | Final |
| ERC-7540 | ERC-4626 | Asynchronous deposits and redemptions | Final |
| ERC-3525 | ERC-721 | Slots and value (semi-fungible) | Final |
Beyond Ethereum: Polygon, Avalanche and Solana
The choice of network changes less than it seems between EVM chains, and a lot when Solana comes in.
Polygon and the Avalanche C-Chain are EVM: the same standards (ERC-3643, 7943, 4626, 7540) deploy without changes, with the same tooling and the same auditors. The differences are cost and ecosystem, which we compare in Which blockchain to deploy an RWA on.
Avalanche L1s (formerly subnets) add something the others don't have: permissioning at the network level. With the Subnet-EVM allowlist precompiles, TxAllowList and ContractDeployerAllowList, you can restrict who sends transactions or deploys contracts on the whole chain. That doesn't replace token-level compliance; it adds a second perimeter, useful for institutional environments.
Solana doesn't use ERCs. Its equivalent is the Token-2022 program (Token Extensions): instead of writing a new contract per token, you enable extensions on the mint. The same compliance functions exist, implemented differently:
| Requirement | EVM (Ethereum, Polygon, Avalanche) | Solana Token-2022 |
|---|---|---|
| Only verified holders | Identity registry (ERC-3643) or canReceive (ERC-7943) | Default Account State set to frozen; accounts are thawed after KYC |
| Custom transfer rules | Compliance module | Transfer Hook, a program called on every transfer |
| Forced transfer and recovery | forcedTransfer (ERC-3643, ERC-7943) | Permanent Delegate |
| Freeze and pause | Freeze and pause functions | Freeze authority and the Pausable extension |
| Metadata and documents | Token metadata, ERC-1643 documents | Metadata Pointer and Token Metadata |
| Confidential balances | Not native (private network or zero-knowledge) | Confidential Transfer |
| Yield display | Vault share price (ERC-4626) | Interest Bearing, Scaled UI Amount |
The practical consequence: the design of the compliance rules is portable, the code isn't. An issuance across EVM and Solana means two implementations of the same rules, and they have to stay in sync.
Layer 5: data and oracles
Two kinds of data reach the token from the real world. Proof of Reserve verifies that the asset backing the token exists (custody balances, certified inventory) and can block minting if supply exceeds reserves. NAV feeds publish the value per share of a fund, which is exactly what an ERC-7540 vault needs to settle subscriptions and redemptions. Chainlink is the most common provider on both the EVM and Solana. What matters here is less the interface than the process: who attests the data, how often, and what happens if it stops updating.
Layer 6: interoperability
When the same asset lives on more than one network, the question is how supply moves without being duplicated. Three approaches dominate:
| Option | Model | Where it fits |
|---|---|---|
| Chainlink CCIP (Cross-Chain Token standard) | Burn-and-mint or lock-and-release, with the issuer in control of its token pools | EVM networks and Solana |
| Wormhole NTT (Native Token Transfers) | Burn-and-mint of the native token, with rate limits | Especially EVM and Solana |
| xERC20 (ERC-7281) | The issuer sets mint limits per bridge | A proposal never merged into the official ERC repository |
For a permissioned token, the bridge is the delicate point: compliance has to hold on both sides. The receiving wallet needs a valid identity on the destination network, and the bridge contract needs the role to mint and burn without bypassing the rules. Before picking a bridge, ask how the destination chain enforces the same eligibility. If the answer is "it doesn't," the bridge is a compliance gap.
How the layers combine: typical starting points
No combination is universal, but these are reasonable starting points by asset type. They're an input for Discovery, not a recommendation for your specific case:
| Asset | Token | Identity | Data |
|---|---|---|---|
| Real estate (SPV shares) | ERC-3643 | ONCHAINID and a KYC provider | Valuation and rent reporting |
| Private credit or bonds | ERC-3643, or ERC-3525 for tranches and maturities | ONCHAINID | Payment schedule and NAV |
| Funds | ERC-7540 with a permissioned share token | ONCHAINID or an allowlist | NAV feed |
| Commodities and reserves | ERC-3643 | ONCHAINID | Proof of Reserve |
| Issuance on Solana | Token-2022 with Transfer Hook and Default Account State | Off-chain KYC, then thaw | Proof of Reserve or NAV |
Where our scope ends
Braincoders designs and builds the technical layers (token contracts, identity integration, compliance rules in code, oracles and cross-chain logic) on EVM networks and Solana. What we don't do is decide the legal layer: the nature of the instrument, who is eligible and which regime applies are defined by the securities lawyer, and we enforce them on-chain.
This map changes fast. The status of every standard in this post was checked against the official ERC repository in September 2026.
Need to decide which standards your tokenization should combine? Book a discovery call and we'll map your asset layer by layer.
