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 a final token standard maintained by the ERC-3643 Association, an association driven by Tokeny together with other industry players, which 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 in Spain
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.
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. A security token is governed by MiFID II and Law 6/2023 (LMVSI), not 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.
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 CNMV.