Technical Guide

ERC-3643 Explained: The Security Token Standard (T-REX)

ERC-3643 Explained: The Security Token Standard (T-REX)

Technical Guide · Token Standards · 2026
ERC-3643 Explained:
The Security Token Standard
ERC-3643 (T-REX) is the dominant token standard for regulated security tokens — used by Tokeny, most EU platforms, and increasingly by global institutional issuers. This guide explains how it works, why it matters, and when to use it.
6 sections
~10 min read
Technical
Updated April 2026

Technical Guide
ERC-3643
Token Standards
Compliance

✍️ GlobalTokenize
📅 April 2026

2019
Year ERC-3643 was first developed by Tokeny
$20B+
Assets issued using ERC-3643 globally
Open
Open standard — not proprietary to Tokeny
ERC
Ethereum Request for Comments — formal standard

📋 In this guide
6 sections · 10 min
1
The problem it solves and how it works
2
ONCHAINID, compliance modules, token contract
3
vs ERC-1400, ERC-20, proprietary standards
4
Platforms, deals, and geographies
5
Why ERC-3643 fits the EU regulatory framework
6
Decision framework for issuers

Section 1
What is ERC-3643?
ERC-3643 — also known as T-REX (Token for Regulated EXchanges) — is an Ethereum token standard specifically designed for regulated security tokens. It extends the basic ERC-20 standard with a compliance layer that enforces investor eligibility rules at the protocol level, directly within the smart contract.
The core problem it solves: traditional ERC-20 tokens can be transferred to any Ethereum wallet without restriction. For regulated securities, this is unacceptable — you cannot allow an unverified wallet to receive a tokenized bond or fund share. ERC-3643 solves this by building KYC and compliance checks directly into the transfer mechanism.
Developed by Tokeny in 2019 and formally ratified as an Ethereum ERC standard in 2023, ERC-3643 is now the dominant standard for regulated tokenization in Europe and is increasingly adopted globally. It is an open standard — not proprietary to Tokeny — and is governed by the ERC-3643 Association.
→
The key innovation
Compliance is enforced at the protocol level, not the application level. Every token transfer automatically checks whether the receiving wallet is eligible — verified identity, correct investor type, no transfer restrictions. If the check fails, the transfer is rejected by the smart contract. This happens automatically for every secondary market transaction, with no manual compliance review required.

Section 2
Technical architecture
ERC-3643 consists of four interconnected smart contract layers. Understanding each layer helps you evaluate whether a platform is genuinely using the standard or just claiming to.
1
Token Contract (T-REX Token)
The core token contract that extends ERC-20. Every transfer function includes a compliance check — before tokens move, the contract queries the Identity Registry and Compliance Module. If either check fails, the transfer reverts. Issuers deploy one token contract per asset.
2
Identity Registry (ONCHAINID)
A registry that maps wallet addresses to verified on-chain identities. Each investor completes KYC off-chain; their verified identity is then linked to their wallet address on-chain via an ONCHAINID smart contract. The Identity Registry stores which wallets are verified and what claims they hold (investor type, jurisdiction, accreditation status).
3
Compliance Module
A modular contract that defines the business rules for a specific token issuance — maximum number of investors, geographic restrictions (blocked jurisdictions), transfer lock-up periods, maximum token holding per investor. These rules are configurable by the issuer without redeploying the entire token contract.
4
Trusted Issuers Registry
A registry of authorised claim issuers — typically KYC providers or the tokenization platform itself. Only claims issued by trusted issuers are accepted by the Identity Registry. This prevents fraudulent identity claims while allowing multiple KYC providers to interoperate.
How a token transfer works
①
Investor A calls transfer() to send tokens to Investor B’s wallet
②
Token contract queries Identity Registry: Is Investor B’s wallet verified with the required claims?
③
Token contract queries Compliance Module: Does this transfer violate any business rules (max investors, lock-up, jurisdiction block)?
✅
Both checks pass: Transfer executes. Tokens move on-chain automatically.
❌
Either check fails: Transfer reverts. No tokens move. No manual compliance review needed.

Section 3
ERC-3643 vs other standards
StandardComplianceIdentityBest for
ERC-3643 (T-REX)On-chain, automaticONCHAINID per investorRegulated securities, EU MiCA, institutional tokenization
ERC-1400Partial on-chainExternal (off-chain)US security tokens, Polymath ecosystem
ERC-20NoneNoneUtility tokens, stablecoins, crypto-native assets
ProprietaryVariesVariesPlatform-specific — no portability
ERC-3643 vs ERC-1400 — the key differences
🔒
Compliance enforcement
ERC-3643 enforces compliance automatically on every transfer via on-chain identity. ERC-1400 provides transfer restriction hooks but relies on off-chain systems to manage investor identity — the compliance check is not automatic at the protocol level.
🌐
DeFi composability
ERC-3643 tokens are composable with DeFi protocols that understand the standard — Aave, MakerDAO, and others have integrated ERC-3643 compliance. ERC-1400 has less DeFi integration.
📍
Geographic adoption
ERC-3643 dominates in Europe — required by most MiCA-compliant platforms. ERC-1400 is more common in the US via the Polymath ecosystem. For global issuances, ERC-3643 provides broader distribution compatibility.

Section 4
Who uses it and where
ERC-3643 has become the default standard for regulated tokenization in Europe and is increasingly adopted globally. Here are the key users and use cases.
🏢
Tokeny — the creator and primary deployer
Tokeny developed ERC-3643 and is the largest deployer. Their platform is used by major European financial institutions including Société Générale, AXA, and Crédit Agricole for security token issuances. Tokeny’s platform is built natively on ERC-3643.
🏦
Société Générale — digital bond issuances
SocGen’s digital asset subsidiary (SG-Forge) has issued multiple digital bonds using ERC-3643 on Ethereum, including covered bonds and structured products. One of the highest-profile institutional deployments of the standard.
🔗
MakerDAO — RWA collateral integration
MakerDAO accepts ERC-3643 compliant tokens as collateral for DAI minting via Centrifuge’s Spark protocol integration. This is the largest single DeFi integration of a regulated security token standard.
🌍
EU tokenization platforms broadly
Most EU-regulated tokenization platforms now require or strongly prefer ERC-3643 for new issuances — including platforms operating under MiCA, BaFin, and AMF oversight. The standard’s alignment with MiCA’s AML and Travel Rule requirements has made it the de facto EU choice.
🏭
ERC-3643 Association — governance body
The ERC-3643 Association was formed in 2023 to govern the open standard and drive adoption. Members include tokenization platforms, custodians, and financial institutions. The association maintains the standard specification and coordinates with regulators.

Section 5
MiCA and regulatory alignment
ERC-3643’s architecture aligns closely with the requirements of MiCA (Markets in Crypto-Assets Regulation), the EU’s comprehensive crypto framework that came into full force in December 2024. This alignment is a primary reason for the standard’s dominance in European markets.
✅
AML / Travel Rule compliance
MiCA requires CASPs (Crypto Asset Service Providers) to implement the FATF Travel Rule — sharing sender and receiver identity for transactions above €1,000. ERC-3643’s ONCHAINID system provides the verifiable on-chain identity infrastructure required for Travel Rule compliance at the protocol level.
✅
Investor protection — transfer restrictions
MiCA requires appropriate investor protection measures for token transfers. ERC-3643’s compliance module can enforce investor eligibility, holding limits, and geographic restrictions automatically — meeting MiCA’s investor protection requirements technically.
✅
Auditability and transparency
All compliance events — identity verification, transfer approvals, restriction updates — are recorded on-chain with full audit trails. This provides the verifiable compliance record that MiCA requires CASPs to maintain.
⚠️
MiCA does not mandate ERC-3643 specifically
MiCA specifies compliance outcomes, not technical implementations. ERC-3643 is not the only way to meet MiCA requirements — but it is the most widely adopted technical solution that demonstrably meets them. Regulators are familiar with it, which reduces approval friction.

Section 6
Should you require ERC-3643?
As an issuer selecting a tokenization platform, you don’t necessarily choose the token standard directly — the platform determines which standard it uses. But understanding which standard a platform uses is an important evaluation criterion.
Require ERC-3643 if:
✅
Your offering is regulated in the EU under MiCA or MiFID II — ERC-3643 is the path of least resistance with EU regulators
✅
You want secondary market composability with DeFi protocols (Aave, MakerDAO, Centrifuge)
✅
You anticipate needing to migrate platforms in future — ERC-3643 tokens are portable, proprietary standard tokens are not
✅
You have a large investor base where automated compliance for secondary transfers is important
ERC-3643 may not be essential if:
⚠️
Your offering is US-only and uses Reg D — the US market has less ERC-3643 adoption and ERC-1400 or proprietary standards are common
⚠️
You’re using a private/permissioned blockchain (Quorum, Corda) — ERC-3643 is an Ethereum standard, not applicable to non-EVM chains
⚠️
You have a small, fixed investor base with no secondary market — the complexity of on-chain identity may not be worth the overhead
→
Bottom line
If you’re issuing regulated securities in Europe in 2026, ERC-3643 is effectively the default choice. It’s not mandated by MiCA, but it’s what regulators expect, what major platforms deploy, and what DeFi protocols integrate with. The question is not whether to use ERC-3643, but which platform’s implementation of it best fits your deal.

Evaluating platforms for ERC-3643 compliance?
We provide vendor-neutral platform assessments including token standard evaluation, smart contract audit review, and compliance architecture analysis. Book a free discovery call.

Frequently asked questions

They are the same thing. T-REX (Token for Regulated EXchanges) was the original name developed by Tokeny. When it was submitted as a formal Ethereum standard, it was ratified as ERC-3643. Both names refer to the same token standard and smart contract architecture.

No — MiCA specifies compliance outcomes, not technical implementations. However, ERC-3643 is the most widely adopted technical solution that demonstrably meets MiCA’s AML, Travel Rule, and investor protection requirements. Most EU-regulated platforms use ERC-3643 by default, making it the practical standard for MiCA compliance.

Yes — ERC-3643 was specifically designed to be composable with DeFi protocols. Major protocols including MakerDAO and Aave have integrated ERC-3643 compliance, allowing ERC-3643 tokens to be used as collateral or traded within DeFi while maintaining compliance checks on every interaction. This is one of the key advantages over ERC-1400 and proprietary standards.

ONCHAINID is the on-chain identity standard used by ERC-3643. Each investor gets an ONCHAINID smart contract deployed to their wallet address. This contract stores verified claims about the investor — KYC status, investor type, jurisdiction, accreditation — issued by trusted claim issuers (KYC providers). When a transfer is attempted, the ERC-3643 token contract checks the receiver’s ONCHAINID for the required claims.

Tokeny (the creator) uses ERC-3643 natively. Other platforms that deploy ERC-3643 or are compatible with it include Securitize (for some issuances), ADDX (for Ethereum-based deals), BlockInvest, and most EU-regulated tokenization platforms. When evaluating a platform, ask directly: “Does your platform deploy ERC-3643 compliant smart contracts?” and “Can you share an example issuance where ONCHAINID was used?”

Share this content:

Tag