Every tokenized asset on a blockchain is governed by a token standard — a set of rules that defines how the token behaves, who can hold it, how it transfers, and what rights it represents. Choosing the wrong standard is not a technical inconvenience. It determines whether a tokenized asset can comply with securities law, whether it can be used as collateral in decentralized finance (DeFi) protocols, whether it can be held by institutional custodians, and whether it can be transferred across different blockchain networks.
The real-world asset (RWA) tokenization market uses at least a dozen distinct token standards. Most commentary on this topic conflates them, presents them as interchangeable, or simply avoids the technical detail. This guide maps every major standard in current institutional use, explains what each one does and does not support, and identifies which standards match which use cases.
The Baseline: ERC-20
The ERC-20 standard — Ethereum Request for Comment 20, proposed in 2015 and finalized in 2017 — is the foundational fungible token standard on Ethereum. Every token issued under ERC-20 is interchangeable with every other token of the same type: one USDC is identical to any other USDC, one BUIDL share is identical to any other BUIDL share of the same class. The standard defines six mandatory functions: totalSupply, balanceOf, transfer, transferFrom, approve, and allowance. Every decentralized exchange, lending protocol, and DeFi application on Ethereum is built to interact with ERC-20 tokens.
ERC-20's strength is its ubiquity. Its weakness for RWA applications is what it lacks: no built-in access control, no compliance enforcement, no mechanism to restrict transfers to authorized wallets, no partition of token balances into separate tranches, and no on-chain record of investor identity. A plain ERC-20 token can be sent to any Ethereum address without restriction — which makes it incompatible with securities regulations that restrict transfers to accredited investors, qualified purchasers, or verified KYC (know your customer) participants.
Several major RWA projects use ERC-20 as their base token type but add an access control layer on top through smart contract restrictions. BlackRock's BUIDL fund uses a modified ERC-20 with a transfer allowlist that restricts movement to addresses verified by Securitize's identity infrastructure. The token is ERC-20 compatible for composability with DeFi — but it is not a plain ERC-20 in practice.
ERC-1400: The Security Token Standard
ERC-1400 was proposed in 2018 as a comprehensive standard for security tokens — tokens that represent ownership interests in regulated financial instruments. It is a family of interrelated standards rather than a single specification, combining several components:
- ERC-1410 (Partially Fungible Tokens): Allows token balances to be divided into tranches — different classes of the same token with different rights. A tokenized bond might have senior and subordinated tranches with different payment priority; a tokenized fund might have Class A and Class B shares with different fee structures. Each tranche is separately transferable under different rules.
- ERC-1594 (Core Security Token): Adds transfer restrictions and a verification function (
canTransfer) that checks whether a proposed transfer is valid before execution. A transfer from a non-verified wallet, to a jurisdiction-restricted recipient, or in excess of a holding limit will fail thecanTransfercheck and be rejected before the transaction executes. - ERC-1643 (Document Management): Attaches legal documents — prospectuses, offering memoranda, transfer agent agreements — directly to the token contract. The document hash is stored on-chain; the document content may be stored off-chain but is verifiably linked to the token.
- ERC-1644 (Controller Operations): Allows a designated controller (the issuer, a transfer agent, or a regulatory authority) to force transfer tokens — for example, in response to a court order, a regulatory action, or an error correction. This is controversial in crypto-native communities but is a legal requirement for regulated securities in most jurisdictions.
ERC-1400 is the most widely implemented security token standard among institutional issuers. Securitize's infrastructure is largely built on ERC-1400 variants. The standard is flexible enough to handle most regulated security use cases but complex enough that implementation requires specialist legal and technical expertise.
ERC-3643: The T-REX Standard
ERC-3643 — informally known as T-REX (Token for Regulated Exchanges) — was developed by Tokeny Solutions and formalized as an Ethereum standard in 2023. It addresses what practitioners identified as the core limitation of ERC-1400: the standard defines the transfer restriction mechanism but does not specify how identity verification is implemented or how identity information is stored and maintained.
T-REX adds an identity layer through the ONCHAINID protocol — a decentralized identity standard that stores verified investor identity claims on-chain. A T-REX token transfer requires that the recipient's ONCHAINID contains valid claims from a trusted claim issuer (a licensed know your customer / anti-money laundering (KYC/AML) provider) before the transfer executes. The entire compliance workflow — identity verification, claim issuance, transfer validation — is automated through smart contracts with no human intervention required at the point of transfer.
The practical implication: when an investor with a verified ONCHAINID buys a T-REX token on a secondary market, the transfer executes automatically if their identity checks pass and is rejected automatically if they do not. No transfer agent needs to manually review and approve the secondary market transaction — the compliance check is embedded in the token itself.
ERC-3643 has been adopted by several major European institutional tokenization platforms. The European Investment Bank's 2023 digital bond issuance used T-REX infrastructure. BNP Paribas, Santander, and Deutsche Bank have conducted T-REX-based tokenization pilots.
ERC-3525: Semi-Fungible Tokens
ERC-3525, finalized in 2022, introduces a token type that is neither purely fungible nor purely non-fungible — it sits between ERC-20 and ERC-721 (non-fungible tokens, or NFTs). Each ERC-3525 token has an ID (making it uniquely identifiable, like an NFT) and a slot (grouping it with similar tokens) and a value (a quantity that is fungible within the same slot).
The RWA applications for ERC-3525 are in complex financial instruments where identity matters but fungibility within a class also matters:
- Tokenized bonds with specific maturities: Each bond series has a unique ID but the face value within that series is fungible. A $1 million bond in the 2028 series can be split into $100,000 units that are interchangeable with each other but distinct from 2029 series units.
- Structured financial products: A collateralized loan obligation (CLO) with multiple tranches can be represented as a single ERC-3525 token structure where each tranche is a slot, the specific investor's position has a unique ID, and the value within each tranche is fungible.
- Vesting schedules: Equity with time-based vesting can be represented where the vested and unvested portions are tracked separately but the vested portion is fungible with other vested equity of the same class.
ERC-3525 is less widely implemented in live institutional products than ERC-1400 or ERC-3643, but it has attracted interest from tokenized bond and structured finance applications where the tranche and maturity structure of traditional fixed income maps naturally to its slot-and-value architecture.
ERC-4626: Tokenized Vaults
ERC-4626, finalized in 2022, standardizes the interface for yield-bearing vaults — smart contracts that accept deposits of one token and return shares representing a proportional interest in a pool of assets. It is not a security token standard; it is a DeFi composability standard. But it has become central to RWA tokenization because it defines how tokenized assets generate and distribute yield.
The BUIDL fund's on-chain mechanism is ERC-4626 compatible: investors deposit USDC, receive BUIDL tokens representing their share of the Treasury bill pool, and the vault automatically accrues yield. Ondo Finance's USDY and OUSG products use ERC-4626 vault structures. The standard's importance is that any DeFi protocol built to interact with ERC-4626 vaults can automatically interact with any RWA product that implements the standard — without needing custom integration code for each product.
This is why ERC-4626 compatibility has become a common feature request for institutional RWA products seeking DeFi composability. A tokenized Treasury product that is ERC-4626 compatible can be used as collateral in Aave, Compound, or other major lending protocols without those protocols writing bespoke support for the specific RWA token.
ERC-7943: The Emerging Institutional Standard
ERC-7943 is a proposed Ethereum standard specifically designed for regulated securities, building on the lessons of ERC-1400 and ERC-3643. It introduces a modular compliance architecture where the token contract, the identity verification system, and the transfer restriction logic are separate, upgradeable components — allowing issuers to update their compliance rules (for example, adding a new jurisdiction's restrictions) without redeploying the token contract itself.
The standard is in active development as of 2026, with contributions from institutional tokenization platforms including Fireblocks, Securitize, and several European bank technology teams. It is not yet widely implemented in live products but is expected to become a reference standard for institutional RWA issuance as the compliance requirements for tokenized securities in the EU (under MiCA), the US (under eventual market structure legislation), and Asia-Pacific (under South Korea's February 2027 framework) crystallize into specific technical requirements.
Non-EVM Standards
Not all institutional RWA tokenization happens on Ethereum or Ethereum-compatible blockchains. Several major alternative networks have their own native token standards that are relevant to the RWA market:
Stellar (SEP-0030 / SEP-0008): Stellar's native token standard with regulated asset extension has been used by Franklin Templeton's BENJI token (the OnChain US Government Money Fund) and several central bank digital currency (CBDC) pilots. Stellar's fast finality (3-5 second settlement) and low transaction costs make it attractive for payment-adjacent RWA applications.
XRP Ledger (IOU / Trustlines): The XRP Ledger's native token infrastructure uses a trustline model where holders explicitly authorize receipt of tokens from specific issuers. This built-in counterparty trust model has made it popular for tokenized asset issuance in the Asia-Pacific region. The JPMorgan cross-border settlement pilots and Ripple's institutional infrastructure use XRPL token standards.
Hyperledger Fabric: The permissioned blockchain platform used by most enterprise and bank-deployed private blockchain networks. Not a public standard in the Ethereum sense — each network defines its own token structure — but the IBM Food Trust supply chain platform, the DTCC's Project Ion predecessor, and several interbank settlement systems run on Fabric.
Which Standard to Use — A Decision Framework
| Use Case | Recommended Standard | Key Reason |
|---|---|---|
| Tokenized money market fund | ERC-20 + allowlist OR ERC-4626 | DeFi composability; yield accrual standardization |
| Regulated security (EU distribution) | ERC-3643 (T-REX) | ONCHAINID compliance; automated KYC enforcement |
| US-regulated security (accredited investors) | ERC-1400 variant | Transfer agent integration; Reg D/Reg S compliance |
| Tokenized bond with tranches | ERC-3525 OR ERC-1410 | Partial fungibility; tranche-specific transfer rules |
| Cross-border payment RWA | Stellar SEP-0008 OR XRPL | Fast finality; low cost; payment infrastructure integration |
| Enterprise supply chain provenance | Hyperledger Fabric | Permissioned access; existing enterprise integration |
| Future institutional standard (EU/US/Korea) | ERC-7943 (emerging) | Modular compliance; future-proof regulatory updates |
The Interoperability Problem — What No Single Standard Solves
The proliferation of token standards creates a fragmentation problem: a T-REX token issued on Ethereum cannot natively interact with a Stellar SEP-0008 token or an XRPL IOU. Transferring tokenized assets across chains — necessary for global distribution of RWAs — requires bridge infrastructure that introduces security risk and operational complexity.
Chainlink's Cross-Chain Interoperability Protocol (CCIP) addresses this by creating a message-passing layer that allows token contracts on different chains to communicate and coordinate transfers without requiring a centralized bridge. Several Project Guardian deployments use CCIP as the interoperability layer between institutional blockchain networks. But CCIP compatibility requires that both the sending and receiving token contracts implement CCIP's interface — adding another layer of standardization pressure on top of the underlying token standard choice.
The long-term trajectory is toward convergence. The same regulatory requirements that drove adoption of ERC-1400 and ERC-3643 will eventually create pressure for a single dominant compliance standard for regulated securities on public blockchains — similar to how PDF became the dominant document standard for regulatory filings despite competing formats. ERC-7943's modular architecture is designed to be that convergence point, but whether it achieves adoption depends on how the major institutional platforms align over the next two to three years.
→ What Is Tokenization? — the foundational guide
→ What You Actually Own — the legal rights behind the token
→ BUIDL — how ERC-20 with compliance layer works in practice
→ DTCC October Launch — where DTCC's standard fits in this landscape