ERC-3643, also known as T-REX (Token for Regulated EXchanges), is a permissioned token standard for Ethereum and other EVM chains, designed to represent securities and other security tokens. Its purpose is to enforce on-chain who can hold or receive the token, tying every transfer to a verified identity.
What ERC-3643 (T-REX) is
ERC-3643 is an Ethereum token standard (ERC) with Final status in the official proposal repository (EIP-3643, created on July 9, 2021); its documentation is published by the ERC3643 Association, and the proposal points to Tokeny's T-REX repository for an implementation of the suite. It defines how to issue and manage tokens whose transfer is restricted to eligible investors. Unlike an open token, an ERC-3643 token can only be held by previously verified accounts, which makes it suitable for assets subject to regulation.
The core idea is identity-based compliance: the contract does not merely move balances but checks, on every operation, whether the recipient meets the conditions defined by the issuer. This is why it sits in the realm of tokenized securities versus crypto-assets, where the identity and eligibility of the holder are decisive. It should also be distinguished from a utility token, a difference we develop in the comparison between security token and utility token.
How it works: on-chain identity and programmed compliance
The standard combines an on-chain identity with a suite of contracts, known as the T-REX suite, which distributes responsibilities across several components:
- ONCHAINID. This is the decentralized identity associated with each investor. On top of it, verified attributes (claims) are anchored, such as the result of KYC or eligible-investor status, which are used to decide whether an account may hold the token.
- Token. The contract for the tokenized security itself, which delegates to the rest of the suite the verification of each transfer before executing it.
- Identity Registry. A registry that links each address to its ONCHAINID and maintains the list of authorized holders.
- Compliance. A module that applies the compliance rules defined by the issuer (for example, limits by jurisdiction or by investor type) and that can combine several rule modules.
- Trusted Issuers Registry. A registry of the trusted entities authorized to issue the claims that are taken into account (for example, the provider that certifies KYC).
- Claim Topics Registry. A catalogue of the types of claim required in order to operate with the token.
With these components, transfer restrictions are enforced on-chain: an operation only completes if the recipient is verified and meets the rules in force; otherwise, the transfer is rejected. This approach turns compliance into a property of the token itself, rather than an external control that depends on the willingness of the parties.
ERC-3643 vs ERC-20 vs ERC-1400
Compared with other standards in the EVM family, ERC-3643 stands out by incorporating identity and compliance as part of the design. The following table summarizes the main differences:
| Feature | ERC-20 | ERC-1400 | ERC-3643 (T-REX) |
|---|---|---|---|
| Primary use | General-purpose fungible token | Security token (family of standards) | Permissioned security token |
| Transfer restrictions | No | Yes, through partitions and rules | Yes, based on verified identity |
| Holder identity | Not contemplated | Depends on implementation | ONCHAINID with verified claims |
| Programmed compliance | No | Partial | Built into the contract suite |
ERC-20 is the open, non-compliant fungible standard, designed so that any address can receive the token. ERC-1400 (and neighbouring standards such as ERC-1404) introduce the concept of restricted transfers for securities, but leave part of the logic to the specific implementation. ERC-3643 takes that approach further by grounding compliance in a verifiable identity and in a standardized suite of registries and rules.
Why it matters for regulated security tokens: Spain, the EU, the US and Latin America
ERC-3643 is a technical tool that helps comply with certain obligations (investor verification, KYC/AML and transfer restrictions), but it is not a legal framework and does not replace regulation. The legal coverage of a security token comes from the applicable regulatory framework, not from the contract that represents it.
In Spain, a security token remains a financial instrument and is governed by MiFID II (Directive 2014/65/EU) and by Law 6/2023 on Securities Markets and Investment Services (LMVSI), with recording and registration through an ERIR and, where applicable, a prospectus approved under the Prospectus Regulation (EU) 2017/1129. The standard can facilitate compliance with those requirements at the technical layer, but it does not exempt the issuer from any of them. That is why it is useful to place its use within a project of regulated tokenization in Spain and within the process described in the guide on how to issue a security token in Spain. In the specific case of equity, the fit is detailed in the article on tokenized shares in Spain.
Other EU Member States
The same base applies across the EU: a security token that falls within Annex I, Section C, of MiFID II is a financial instrument (Article 4(1)(15) of Directive 2014/65/EU), MiCA does not apply to it (Article 2(4)(a) of Regulation (EU) 2023/1114), and a public offer needs a prospectus or an exemption under Regulation (EU) 2017/1129. The standard's per-country rules help where requirements are counted by Member State: for example, a cap on investors per country when an offer relies on the exemption for fewer than 150 persons per Member State (Article 1(4)(b)). That exemption refers to who the offer is addressed to, so whether it applies is a legal call, not a setting in the token.
United States
In the US, a tokenized security is still a security: the SEC and CFTC interpretation of March 17, 2026 (Release 33-11412) calls it a "digital security" and states that a security is a security whether it is issued or represented on-chain or off-chain. ERC-3643 fits three parts of that market:
- Transfer agent. The official record of holders is kept by the issuer or a transfer agent, and registration as a transfer agent is only mandatory for securities registered under Section 12 of the Exchange Act, or that would be but for certain exemptions (Section 17A(c)(1)). According to SEC Division of Trading and Markets FAQs (staff views, not binding), a registered transfer agent may use a blockchain as that official record if it meets the transfer agent rules on records, turnaround, safeguarding and internal controls. The standard's agent functions (freezing, forced transfers and recovery of tokens from a lost wallet, with the recovery history kept on-chain) keep the token in line with that record.
- Transfer restrictions. Regulation D securities are restricted securities, and the Rule 144 safe harbor requires a holding period of six months or one year depending on whether the issuer reports to the SEC (17 CFR 230.144(d)(1)); under Regulation S, Category 3 requires the issuer to refuse to register non-compliant transfers of equity (230.903(b)(3)). Time locks, investor whitelists and country codes are rules the token can check on every transfer through its Identity Registry and compliance contract, and accredited investor status can be a claim issued by a trusted verifier.
- ATS. A platform that brings together orders from multiple buyers and sellers and uses established, non-discretionary methods for them to interact meets the definition of an exchange (17 CFR 240.3b-16): it must register as an exchange or operate as an ATS under Regulation ATS, which among other things requires registering as a broker-dealer (240.3a1-1(a)(2); 242.301(b)(1)). Because an ERC-3643 token only reaches wallets verified in its Identity Registry, the accounts used by the ATS or the broker-dealer have to be onboarded there as well.
For more detail, see our guide to asset tokenization in the United States and, for offerings with investors on both sides of the Atlantic, cross-border security token offerings between the EU and the US. The short definition is in our ERC-3643 glossary entry.
Latin America
Each country has its own securities regime and regulator. The standard is configured per jurisdiction (accepted countries, investor types, limits per investor) together with local legal counsel; our regulatory map of Latin America summarizes the framework country by country.
Frequently asked questions
Does ERC-3643 make a token comply with MiCA or MiFID II on its own?
No. ERC-3643 is a technical standard that helps apply controls such as investor eligibility or transfer restrictions, but regulatory compliance depends on the applicable legal framework. In Spain a security token is governed by MiFID II and Law 6/2023 (LMVSI), and in the US by the federal securities laws; in neither case by the standard itself.
What is ONCHAINID?
It is the on-chain identity associated with each investor, on top of which verified attributes (claims) are anchored, such as KYC or eligible-investor status. The standard uses it to decide whether an account may hold or receive the token.
Is it mandatory to use ERC-3643 to issue a security token?
No. It is an available and widely adopted standard for permissioned tokens, but it is not mandatory. The obligation falls on the legal requirements of the financial instrument; the specific standard is a technical decision of the issuer.
Does it work on other EVM chains?
Yes. As a standard for EVM environments, it can be deployed on Ethereum and on other EVM-compatible chains, provided they support the T-REX suite contracts and the associated identity infrastructure.
Can ERC-3643 enforce US restrictions such as Regulation S or Rule 144?
It can apply them as rules: the Identity Registry links each wallet to an identity and an ISO-3166 country code, and the compliance contract can limit accepted countries, investor types and transfers before a set date. What the token cannot do is decide which restriction applies: the Regulation S category and the Rule 144 holding period (17 CFR 230.903; 230.144(d)) are determined with the issuer's US securities counsel, and the platform then encodes them.
If you are considering issuing a security token and want to analyze which technical standard and which regulatory fit apply to it, book a consultation with our team.
This article is informational and technical; it does not constitute legal or financial advice. Issuing a security token requires an individualized analysis and verification against official sources and the competent regulator (the CNMV in Spain, the SEC in the US).