ERC-3643 (T-REX): Permissioned Tokens for Tokenized RWAs

A plain ERC-20 token moves to any address that the holder names. A security token cannot work that way: such tokens "must be permissioned to track ownership and ensure that only eligible investors can hold tokens"^[1]. ERC-3643 puts that check into the token contract itself, so the rule applies on every transfer and not only at onboarding.

What ERC-3643 is

ERC-3643 is titled "T-REX - Token for Regulated EXchanges". Its status is Final, its type is Standards Track (ERC), and it was created on 2021-07-09. It requires ERC-20 and ERC-173^[1].

The motivation states the problem directly: "These tokens cannot be permissionless like utility tokens"^[1].

The token interface is declared as interface IERC3643 is IERC20, so every ERC-20 function can be called on an ERC-3643 token^[1]. The standard adds that "the implementation of these functions differs due to the permissioned nature of ERC-3643"^[1]. In ERC-20, transfer moves tokens and "SHOULD throw if the message caller's account balance does not have enough tokens to spend"^[2]. ERC-3643 keeps that interface and adds eligibility checks behind it.

The core requirement in the specification is that the token "MUST be used in combination with an onchain Identity system"^[1]. The standard is a set of contracts that work together:

• Token (IERC3643): the ERC-20 token with the transfer checks and issuer controls.
• Identity Registry (IIdentityRegistry): maps wallets to on-chain identities and answers whether a wallet is verified.
• Identity Registry Storage (IIdentityRegistryStorage): holds the wallet, identity and country records.
• Claim Topics Registry (IClaimTopicsRegistry): lists the claims a holder needs.
• Trusted Issuers Registry (ITrustedIssuersRegistry): lists who may issue those claims.
• Compliance (ICompliance): applies the offering rules to each transfer.

The interface names above are those of the EIP specification^[1].

Identity registry and claim topics

Eligibility in ERC-3643 is not a list of wallet addresses. It is a set of claims attached to an on-chain identity, and the registry checks those claims against rules the issuer sets.

The motivation describes "the validation of the identities and credentials of investors through signed attestations issued by trusted claim issuers"^[1]. The rationale defines a claim as "Signed attestations issued by a trusted claim issuer that confirm certain attributes or qualifications of the token holders, such as their identity, location, investor status, or KYC/AML clearance."^[1]

The Identity Registry

IIdentityRegistry links each wallet to an identity contract and a country code. Its functions include registerIdentity, deleteIdentity, updateIdentity, updateCountry, batchRegisterIdentity, contains, identity, investorCountry and isVerified^[1]. isVerified is the function the token calls on a transfer: it answers whether the wallet's identity holds the required claims from trusted issuers.

The records sit in a separate contract, IIdentityRegistryStorage, with functions such as addIdentityToStorage, modifyStoredIdentity, modifyStoredInvestorCountry, bindIdentityRegistry and linkedIdentityRegistries^[1].

Claim topics and trusted issuers

• IClaimTopicsRegistry holds the claim topics a holder needs, with addClaimTopic, removeClaimTopic and getClaimTopics^[1].
• ITrustedIssuersRegistry holds the issuers whose claims count, and the topics each one may attest, with addTrustedIssuer, removeTrustedIssuer, updateIssuerClaimTopics, isTrustedIssuer and getTrustedIssuersForClaimTopic^[1].

ONCHAINID

The EIP does not name an identity standard in its text. It links the identity interfaces it depends on (IIdentity, IClaimIssuer and the "Claim Holder" IERC735) as asset files of the proposal^[1].

Those interfaces come from ONCHAINID. Its documentation describes it as "a set of smart contracts (based on ERC734-735) and applications to represent individuals, companies, programs, objects and other types of assets on the blockchain"^[4]. The ERC-3643 documentation states that "ONCHAINID complies with the ERC-734 and ERC-735 standards"^[5] and stresses that "a blockchain wallet does not constitute an identity"^[6].

Compliance modules

Identity answers who may hold the token. The Compliance contract answers whether a given transfer respects the rules of the offering.

The EIP defines ICompliance with bindToken, unbindToken, isTokenBound, getTokenBound, canTransfer, transferred, created and destroyed^[1]. canTransfer is the check; the other three hooks let the contract track state after a transfer, a mint or a burn.

The EIP leaves the form of that contract open: it "can be either “tailor-made”, following the legal requirements of the token issuer, or can be deployed under a generic modular form, which can then add and remove external compliance Modules"^[1]. The rationale gives examples of what modules can enforce: "caps on the number of investors or the percentage of tokens held by a single investor, restrictions on transfers between certain types of investors, and more"^[1].

Modular compliance in the reference implementation

The modular form is not an interface of the EIP. It is defined in the reference implementation, in IModularCompliance, with functions that include addModule, removeModule, getModules, isModuleBound and canTransfer^[8]. Its documentation comments state that:

• canTransfer "will call moduleCheck() on every module bound to the compliance", and returns true only if each module check returns true^[8];
• "there cannot be more than 25 modules bound to the modular compliance for gas cost reasons"^[8].

Each module implements IModule, with moduleCheck for the pre-transfer test and moduleTransferAction, moduleMintAction and moduleBurnAction for state updates^[9]. The ERC-3643 documentation lists add-on modules such as country allow and restrict lists, maximum balance and supply limits, and notes that "These modules were developed by tokenization platforms and are not part of the open-source protocol"^[7].

Transfer validation flow

The specification lists the conditions a transfer must meet. A transfer that fails any one of them does not execute.

In the words of the EIP, "To be able to perform a transfer on T-REX you need to fulfill several conditions"^[1]:

1. "The sender MUST hold enough free balance (total balance - frozen tokens, if any)"
2. "The receiver MUST be whitelisted on the Identity Registry and verified (hold the necessary claims on his onchain Identity)"
3. "The sender's wallet MUST NOT be frozen"
4. "The receiver's wallet MUST NOT be frozen"
5. "The token MUST NOT be paused"
6. "The transfer MUST respect all the rules of compliance defined in the Compliance smart contract (canTransfer needs to return TRUE)"

The standard also requires "a standard interface to pre-check if a transfer is going to pass or fail before sending it to the blockchain"^[1]. In the EIP's example implementation, the token calls transferred on the Compliance contract after the balances move, so the compliance state stays current^[1]. That call order is shown in example code; the specification does not state it as a MUST.

Mint, forced transfer and burn

Not every movement of tokens runs the full list. The EIP states: "The transferFrom function works the same way while the mint function and the forcedTransfer function only require the receiver to be whitelisted and verified on the Identity Registry (they bypass the compliance rules). The burn function bypasses all checks on eligibility."^[1]

Agents, forced transfer, recovery, freeze and pause

ERC-3643 gives the issuer side a defined set of powers over the token. The standard names the roles and the functions. It does not say who should hold them.

Owner and agents

The token "MUST define an Agent role and an Owner (token issuer) role"^[1]. IAgentRole provides addAgent, removeAgent and isAgent^[1]. The EIP states that "it is the owner role, as defined by ERC-173, that has the responsibility of appointing and removing agents"^[1]. ERC-173 standardizes reading the owner with owner() and changing it with transferOwnership(address newOwner)^[3].

The issuer functions

• Forced transfer. The token "MUST be able to force transfers from an Agent wallet", through forcedTransfer^[1].
• Recovery. The token "MUST have a recovery system in case an investor loses access to his private key"^[1]. The function is recoveryAddress(address _lostWallet, address _newWallet, address _investorOnchainID), and "A history of recovered tokens is maintained on the blockchain for transparency reasons."^[1]
• Freeze. The token "MUST be able to freeze tokens on the wallet of investors if needed, partially or totally"^[1], through setAddressFrozen for a whole wallet and freezePartialTokens / unfreezePartialTokens for an amount. isFrozen and getFrozenTokens read the state^[1].
• Pause. The token "MUST have the possibility to pause the token", with pause, unpause and paused^[1].
• Batch operations. The token "MUST be able to issue transactions in batch (to save gas and to have all the transactions performed in the same block)"^[1]: batchTransfer, batchForcedTransfer, batchMint, batchBurn, batchSetAddressFrozen, batchFreezePartialTokens and batchUnfreezePartialTokens.

The token can also replace its Identity Registry and its Compliance contract, through setIdentityRegistry and setCompliance^[1].

ERC-20, ERC-1400 and ERC-3643 compared

ERC-1400 is a security token proposal for Ethereum, opened as a GitHub issue on 2018-09-13. Its primary text is ethereum/EIPs issue #1411, which describes it as a "library of standards for security tokens on Ethereum", marked "status: Draft"^[10]. The table reads the three designs against the questions an issuer or an allocator asks. "Not specified" means the cited source does not define the feature.

Both security token designs require ERC-20 compatibility[10]^[1] and both add a pre-transfer check. The difference is where eligibility lives. ERC-1400 returns a reason code from canTransfer and leaves the source of the decision to the implementation^[10]. ERC-3643 names the source: claims on an on-chain identity, checked through its registries^[1].

EU regulatory framing

A token standard describes how a contract behaves. The legal regime that applies to the asset depends on what the asset is. This section quotes the EU texts; it does not apply them to any specific token.

MiCA and financial instruments

MiCA, Regulation (EU) 2023/1114, states in Article 2(4): "This Regulation does not apply to crypto-assets that qualify as one or more of the following: (a) financial instruments;"^[12]. Article 2(5) required ESMA to issue guidelines "on the conditions and criteria for the qualification of crypto-assets as financial instruments"^[12].

Those guidelines state that "Tokenised financial instruments should continue to be considered as financial instruments for all regulatory purposes" and that "A substance over form approach should be adopted to determine if a crypto-asset qualifies as a financial instrument"^[13].

The DLT Pilot Regime

Regulation (EU) 2022/858 sets up "a pilot regime for market infrastructures based on distributed ledger technology"^[14]. It applies from 23 March 2023, with some articles applying earlier (Article 19(2))^[14]. It defines:

• a "DLT financial instrument" as "a financial instrument that is issued, recorded, transferred and stored using distributed ledger technology" (Article 2(11))^[14];
• a "DLT market infrastructure" as "a DLT multilateral trading facility, a DLT settlement system or a DLT trading and settlement system" (Article 2(5))^[14].

Article 3 limits which DLT financial instruments these infrastructures may admit to trading or record, by type and size^[14]. The regime governs the market infrastructure and its operator. It does not name or require a token standard.

Limits and open questions

The standard defines mechanisms. Each one moves a question to a party or a key that a reviewer still has to examine. These are open questions for a review, not recommendations.

1. Which implementation, and which audit? The EIP's Security Considerations section reports audits by two firms and notes that "the audits were primarily focused on the specific implementation by Tokeny"^[1]. A token deployed from different code raises its own audit question.
2. Who are the trusted claim issuers? Eligibility rests on "signed attestations issued by trusted claim issuers"^[1]. The Trusted Issuers Registry and the Claim Topics Registry of a given token decide which attestations count.
3. Who holds the owner and agent keys? Agents can force transfers, freeze wallets, pause the token and recover balances, and the ERC-173 owner appoints the agents^[1]. The controls on those keys sit outside the standard.
4. Which compliance modules are bound, and who wrote them? The EIP allows a tailor-made or a modular Compliance contract^[1], and the documented add-on modules "are not part of the open-source protocol"^[7].
5. Which paths skip the compliance rules? mint and forcedTransfer bypass the compliance rules, and burn bypasses the eligibility checks^[1].
6. What is the legal qualification of the asset? On-chain checks do not decide it. Under ESMA's guidelines, qualification follows substance over form^[13].

How this relates to Rekord

Rekord's vaults follow the ERC-4626 tokenized vault standard and its ERC-7540 asynchronous extension^[15]. The on-chain control that page describes is of a different kind from ERC-3643. The vault Safe carries a public Zodiac Roles Modifier that scopes outgoing transfers to a single whitelisted destination, the Fordefi settlement vault^[15].

That control restricts where funds can go. It does not restrict who can hold a token, which is the question the ERC-3643 Identity Registry answers. Rekord is offered to qualified counterparties^[16]. For the vault standards in detail, see How Rekord works.

Sources

1. ERC-3643: T-REX - Token for Regulated EXchanges. Ethereum Improvement Proposals, Final, created 2021-07-09; Specification, Rationale and Security Considerations. Accessed Oct 24, 2026.
2. ERC-20: Token Standard. Ethereum Improvement Proposals, Final, created 2015-11-19. Accessed Oct 24, 2026.
3. ERC-173: Contract Ownership Standard. Ethereum Improvement Proposals, Final, created 2018-06-07. Accessed Oct 24, 2026.
4. ONCHAINID documentation, Introduction. ONCHAINID protocol concepts. Accessed Oct 24, 2026.
5. ERC-3643 documentation, Onchain identities. Smart contracts library. Accessed Oct 24, 2026.
6. ERC-3643 documentation, Built-in compliance framework. Overview of the protocol. Accessed Oct 24, 2026.
7. ERC-3643 documentation, Modular compliance add-ons. Overview of the protocol. Accessed Oct 24, 2026.
8. ERC-3643 reference implementation, IModularCompliance.sol. GitHub, ERC-3643/ERC-3643, contracts/compliance/modular. Accessed Oct 24, 2026.
9. ERC-3643 reference implementation, IModule.sol. GitHub, ERC-3643/ERC-3643, contracts/compliance/modular/modules. Accessed Oct 24, 2026.
10. ERC 1400: Security Token Standard. GitHub, ethereum/EIPs issue #1411, opened 2018-09-13, status: Draft; issue closed 2022-06-11. Accessed Oct 24, 2026.
11. ERC 1410: Partially Fungible Token Standard. GitHub, ethereum/EIPs issue #1410. Accessed Oct 24, 2026.
12. Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA). EUR-Lex, Official Journal L 150, 9.6.2023; Art. 2(4)(a) and 2(5). Accessed Oct 24, 2026.
13. ESMA, Guidelines on the conditions and criteria for the qualification of crypto-assets as financial instruments (ESMA75453128700-1323). Paragraphs 4, 12 and 14. Accessed Oct 24, 2026.
14. Regulation (EU) 2022/858 on a pilot regime for market infrastructures based on distributed ledger technology. EUR-Lex, Official Journal L 151, 2.6.2022; Art. 1, 2, 3 and 19. Accessed Oct 24, 2026.
15. Rekord, How it works. Stablecoin vaults; Governance and custody controls. Accessed Oct 24, 2026.
16. Rekord, Vaults. FAQ, "Who can deposit?". Accessed Oct 24, 2026.

This guide is for information only and is not legal advice. Standards, regulatory texts and their interpretation change; read the current sources before you act.