What is ERC-3643 (T-REX) and why it matters

ERC-3643 is the token standard built specifically for the compliant, permissioned transfer of tokenized securities, and it has become a default reference point for anyone tokenizing real-world assets. Also known as T-REX (Token for Regulated EXchanges), it solves a problem that plain ERC-20 tokens were never designed to handle: making sure only eligible, verified holders can send, receive or hold a security token, checked at every single transfer and enforced on-chain rather than trusted to an off-chain spreadsheet. If you are structuring a tokenized bond, a real estate fund or an equity offering, understanding how ERC-3643 works, and where it differs from a standard ERC-20 token, is one of the first technical decisions you will face.

What problem does ERC-3643 solve

ERC-20 assumes that any wallet can hold and freely transfer the token. That works well for a utility token or a simple fungible asset, and it is exactly the wrong assumption for a security. An issuer of a tokenized bond, a fund share or an equity position needs to know, at all times, who holds the asset, confirm that each holder is eligible (KYC passed, accredited where required, not in a restricted jurisdiction), and often enforce rules such as lock-up periods, investor caps or transfer restrictions.

Before ERC-3643, teams handled this in one of two ways: keep the security off-chain and use the blockchain only for settlement records, or bolt custom permission logic onto a bespoke contract with no shared standard. Both approaches make audits, custodian integrations and secondary trading harder, because every platform reinvents the same identity and compliance logic in an incompatible way. ERC-3643 standardizes that logic so wallets, exchanges, custodians and compliance tooling can interoperate around the same rules.

The core components of ERC-3643 (T-REX)

An ERC-3643 token is not one contract but a small system of contracts that work together. The main pieces are:

• ONCHAINID. A portable, on-chain identity contract that belongs to the investor, not to the platform issuing the token. It can hold claims from multiple issuers and be reused across different tokenized offerings, so an investor does not repeat identity verification from scratch for every new asset.
• Trusted Issuers Registry. The list of parties, typically KYC and AML providers, auditors or notaries, that the token issuer trusts to certify facts about investors, such as verified identity, accreditation status or country of residence.
• Claim Topics Registry. Defines which categories of claims a holder must carry for this specific token, for example a completed KYC check, accredited-investor status, or confirmation that the holder is not a resident of a restricted jurisdiction.
• Identity Registry. Maps wallet addresses to ONCHAINID identities and, on every transfer, checks that both the sender and the receiver hold the claims required by the Claim Topics Registry, issued by an issuer on the Trusted Issuers Registry.
• Compliance contract. Enforces the business and regulatory rules layered on top of identity: maximum number of holders, jurisdiction caps, lock-up periods, transfer limits and any other rule the issuer configures.
• Token contract. An ERC-20-compatible contract that calls the Identity Registry and the Compliance contract before allowing any transfer to complete, and typically adds agent functions such as forced transfer and recovery that a security token issuer may need under regulation.

How a transfer is validated, step by step

A transfer that looks like a single click to an investor actually triggers a short chain of on-chain checks:

1. The sender’s wallet requests a transfer to a receiving address.
2. The token contract asks the Identity Registry whether the receiving wallet is linked to a registered ONCHAINID.
3. The Identity Registry checks that identity against the Claim Topics Registry, confirming it holds valid, unexpired claims issued by a party on the Trusted Issuers Registry.
4. The Compliance contract checks issuer-defined rules on top of identity: holder caps, jurisdiction restrictions, lock-up windows, transfer limits and any other configured condition.
5. If every check passes, the transfer executes atomically in the same transaction. If any single check fails, the transaction reverts and no tokens move.

That sequence is the practical difference between ERC-3643 and a plain ERC-20 transfer, where the contract only checks that the sender’s balance is sufficient.

ERC-20 vs ERC-3643: a side-by-side comparison

The table below lines up the two standards on the dimensions that matter most for a security token.

Dimension	ERC-20	ERC-3643 (T-REX)
Who can hold the token	Any wallet	Only wallets linked to a verified, eligible identity
Identity layer	None	ONCHAINID plus claims from trusted issuers
Transfer validation	Balance check only	Identity, claims and compliance rules checked on every transfer
Compliance enforcement	Off-chain, if any	Built into the compliance contract, on-chain
Lock-ups and holder caps	Not supported natively	Native support via the compliance contract
Lost-key recovery, forced transfer	Not supported	Supported, often required by regulators
Typical use case	Utility tokens, fungible assets	Tokenized securities, real-world assets

That contrast is exactly what the figure above illustrates: an ERC-20 token lets anyone with a compatible wallet receive and move it, while an ERC-3643 token checks identity and runs compliance logic before every transfer clears.

When to use ERC-3643 (and when you probably do not)

ERC-3643 fits when the underlying token is, or is likely to be treated as, a security: equity, debt, real estate shares, fund units or revenue-sharing instruments. In those cases, an on-chain identity and compliance layer is not an extra feature; it is close to a legal requirement, since the issuer must be able to show who holds the asset and confirm they remain eligible over time.

It is generally unnecessary for a genuine utility token with no securities characteristics, such as loyalty points or in-app credits, where permissionless transfer is a feature rather than a risk. That distinction is a legal one before it is a technical one, so it is worth reading through it carefully in our guide on security tokens vs utility tokens before choosing a standard.

A note on alternatives: the ERC-1400 family

ERC-3643 is not the only approach to compliant tokenized securities. The ERC-1400 family, a more modular set of standards that predates T-REX and includes related extensions such as ERC-1594 and ERC-1410, also targets permissioned, compliant security tokens, built around a different, more fragmented set of interfaces. Some issuers and platforms still build on ERC-1400-style contracts, and others use proprietary permissioned extensions of ERC-20 rather than either public standard. ERC-3643 has gained particular traction in real-world asset tokenization because it packages identity, claims and compliance into one interoperable standard with a large ecosystem of tooling around it, but that is not a claim that one standard has definitively won; the right choice still depends on your custodian, your exchange or distribution partners, and the jurisdictions you plan to operate in.

Why this matters if you are tokenizing real-world assets

Because tokenized real-world assets are usually securities, the token standard you choose is not a backend detail, it shapes who can legally buy in, how a secondary market can function, and how much manual compliance work your team carries versus how much the smart contracts carry for you. Teams building on a standard like ERC-3643 can automate identity and claims checks at the protocol level, then spend their design effort on the asset structure itself, whether that means tokenizing a piece of real estate or a fund, and on launching a white-label tokenization platform that a compliance team can actually operate day to day.

This also connects to two adjacent decisions. First, your custody model: whether investors or a regulated custodian holds the underlying keys interacts with how identity and compliance checks are enforced, covered in our guide on custodial vs non-custodial custody. Second, your onboarding flow: the claims an ONCHAINID carries usually originate from the same KYC process a compliant platform already runs, detailed in how KYC and AML work for crypto and fiat payments.

This article is general information about a token standard, not legal or investment advice. Whether a given asset must be tokenized as a security, and which standard fits your structure, depends on your jurisdiction and should be confirmed with qualified counsel before you build.

Related guides

• Real-world asset (RWA) tokenization: the complete guide
• How to tokenize real estate
• Security tokens vs utility tokens
• How to launch a white-label tokenization platform

Where Tokelia fits

Tokelia is the full-stack infrastructure to launch a fintech or a tokenization platform in Latin America: virtual accounts, unified crypto-and-fiat rails, local payment rails (PIX, SPEI, Bre-b) alongside ACH, Wire, FedNow, SEPA and FPS, card issuing and real-world asset tokenization, behind one API, with a non-custodial architecture and compliance built into the base stack. Money services are provided by Tokelia LLC, registered as a Money Services Business with FinCEN, and regulated banking is delivered by licensed institutions, so you can launch under your own brand while the hard-to-change parts are already solved.

If you are evaluating ERC-3643 for a tokenization program, talk to our team and we will walk through how identity, claims and compliance map to your specific asset and markets.