RWA Token Standards Compared (2026): ERC-3643, ERC-1400, ERC-4626 and ERC-3525

When an issuer tokenizes a real-world asset, one of the earliest technical decisions is which token standard the on-chain representation follows. The choice is not cosmetic: it determines whether transfers can be restricted to vetted investors, whether the token can express yield, and whether wallets and exchanges can integrate it without bespoke code. Most secondary write-ups on this topic copy figures and statuses from 2022-era primers, and several of those statuses are now wrong.

This page is a long-lived reference. For each standard we verified the EIP number, title, status and category directly against eips.ethereum.org and the authoritative ethereum/ERCs GitHub repository — the primary sources for what an Ethereum standard actually is and where it stands. Where a widely repeated status was outdated, we corrected it and logged the correction. As with everything here, we read this through our four-layer lens (see our methodology): the standard is the on-chain structure layer, and it has to fit the legal wrapper above it.

All four standards are Standards Track / ERC category. Status and metadata below are as recorded on eips.ethereum.org and the ethereum/ERCs repository on 29 May 2026.

The single most common error in competing references is treating ERC-3643 or ERC-4626 as “Draft” or “in Last Call”. Both are Final. The second most common error is listing ERC-1400 alongside the others as if it carried the same official standing — it does not.

ERC-3643: T-REX — Token for Regulated EXchangesis, in its own abstract, “an institutional grade security token standard” for the “management and compliant transfer of security tokens, using an automated onchain validator system leveraging onchain identities for eligibility checks” (per the EIP-3643 text). It is ERC-20 compatible but permissioned: a transfer only succeeds if the receiver is whitelisted and verified in an Identity Registry, neither wallet is frozen, the token is not paused, and the offering’s compliance rules return true.

The problem it solves is that securities cannot be permissionless. The EIP’s motivation states plainly that security tokens “cannot be permissionless like utility tokens; they must be permissioned to track ownership and ensure that only eligible investors can hold tokens.” To do that, ERC-3643 standardizes a set of contracts — an Identity Registry, a Compliance contract, a Trusted Issuers Registry and a Claim Topics Registry — and pairs them with the ONCHAINID on-chain identity framework.

Status:Final on eips.ethereum.org (created 9 July 2021; requires ERC-20 and ERC-173). The standard is stewarded by the ERC-3643 Association, whose members include Tokeny, Apex Group, Archax, Invesco and Polygon, and which describes ERC-3643 as “the Token standard for RWA Tokenization.” The Association reports more than US$32 billion of assets tokenized with it; we cite that as the Association’s own figure rather than as independently audited data.

ERC-1400: Security Token Standardis the label most commonly attached to security tokens in older guides. It is best understood as an umbrella over a family of sub-standards: ERC-1410 (partially-fungible, “partitioned” balances), ERC-1594 (core security-token transfer restrictions), ERC-1643 (document management) and ERC-1644 (controller operation, i.e. forced transfers), all building on ERC-20 (per the ERC-1400 proposal text in GitHub issue #1411).

Its design goal is to give holders transparency into how different subsets of their balance behave with respect to transfer restrictions, rights and obligations — useful for securities with tranches, lock-ups or restricted partitions.

Status — the correction that matters: ERC-1400 is not a finalized, official EIP. The page eips.ethereum.org/EIPS/eip-1400returns a 404, and the standard’s GitHub issue (#1411, authored 9 September 2018 by Adam Dossa and others) is Closed and labelled stale. The proposal’s own front-matter once read “status: Draft,” but it was never merged into the EIPs repository. The same caveat applies to ERC-1404 (Simple Restricted Token), which also 404s on eips.ethereum.org. These remain influential community conventions, and real tokens implement them — but they do not carry the official standing that ERC-3643, ERC-4626 and ERC-3525 do.

ERC-4626: Tokenized Vaults standardizes a vault that issues ERC-20 shares against a single underlying ERC-20 asset, with a common interface for deposit, mint, withdraw, redeemand the conversion and preview functions around them. Its motivation is integration: before it, “tokenized Vaults have a lack of standardization leading to diverse implementation details,” forcing every protocol to write error-prone adapters (per EIP-4626). In RWA, it is the natural wrapper for yield-bearing products — tokenized money-market and Treasury funds, and RWA lending vaults — where a share price accrues over time. Status: Final (created 22 December 2021; requires ERC-20 and ERC-2612).

ERC-3525: Semi-Fungible Token introduces a <ID, SLOT, VALUE> model: tokens are ERC-721 compatible (each has a unique ID) but also carry a quantitative value, and two tokens sharing the same SLOT are fungible in their value. The EIP’s motivation calls out the exact RWA pain point: building “financial instruments such as bonds, insurance policy, or vesting plans” with ERC-721 leaves no standard way to control the value inside them, so you cannot transfer a portion of a position (per EIP-3525). ERC-3525 is therefore suited to structured instruments that need both identity and divisible quantity. Status: Final (created 1 December 2020; requires ERC-20, ERC-165 and ERC-721).

Crucially, neither ERC-4626 nor ERC-3525 enforces who may hold the token — that is a compliance concern handled by ERC-3643 or the ERC-1400 family. The standards compose: a regulated yield product might wrap ERC-4626 economics inside ERC-3643 permissioning.

A practical way to choose is to start from the legal wrapper and the instrument’s economics, then pick the standard that matches:

• A regulated security that needs investor gating (a tokenized fund, equity, bond or private placement that may only be held by vetted investors): ERC-3643, or an ERC-1400-family implementation where partitioned balances and document/controller features are required. Compliance and identity are the deciding factors.
• A yield-bearing product (a tokenized money-market or Treasury fund, an RWA lending vault) where users hold a share whose value accrues: ERC-4626 for the vault economics — often layered with ERC-3643 permissioning if the product is restricted.
• A structured or fractionalized instrument with quantitative slots (bonds with coupons, vesting schedules, positions you want to split by value): ERC-3525, whose semi-fungible model is purpose-built for this.
• An unrestricted, purely fungible representation (rare for genuine securities): plain ERC-20 may suffice, but it offers none of the compliance guarantees above — which is why regulated RWA almost never stops at ERC-20.

The real-world picture mirrors this split. Hong Kong’s tokenized money-market funds and digital bonds — tracked in our Hong Kong RWA regulation timeline — sit at exactly the intersection these standards address: a regulated wrapper (the asset and its authorisation) over an on-chain structure that must enforce who can hold and trade it. The standard is the machinery that makes the legal wrapper enforceable in code.