ERC-3643 (T-REX)

What ERC-3643 adds to ERC-20

The specification is blunt about why it exists. Tokenized securities "cannot be permissionless like utility tokens; they must be permissioned to track ownership and ensure that only eligible investors can hold tokens." It requires EIP-20 and EIP-173, and it is designed "to work in conjunction with an on-chain Identity system, allowing for the validation of the identities and credentials of investors through signed attestations issued by trusted claim issuers."¹ Status on the Ethereum Improvement Proposals registry is Final, with the standard created in July 2021.

A plain ERC-20 will move to any address that asks. ERC-3643 inverts that default. Two conditions have to hold before a transfer executes: "The receiver MUST be whitelisted on the Identity Registry and verified" and "the transfer MUST respect all the rules of compliance defined in the Compliance smart contract," enforced in code as a require on canTransfer returning true.¹

This is a business decision dressed as a technical one. Permissioning is what makes a regulated asset issuable onchain in the first place, and it is also what decides which venues will ever list it. The standard does not create demand for the asset. The asset underneath still has to be worth owning.

The registries under the token

The Identity Registry "establishes the link between a wallet address, an Identity smart contract, and a country code corresponding to the investor's country of residence," and exposes isVerified, which returns a status based on the validity of the claims held in that investor's identity contract. There is a separate Identity Registry per security token.¹

Underneath it sits the Identity Registry Storage, which holds "the identity addresses of all the authorized investors... who have been authorized to hold the token(s) after having gone through the appropriate KYC and eligibility checks." The separation matters commercially: an issuer can run one Identity Registry per token while several tokens share a single whitelist of investors, so onboarding cost is paid once across a product family rather than once per issuance.¹

Two more registries decide whose word counts. The Trusted Issuers Registry names the claim issuers whose signatures the token will accept, and the Claim Topics Registry names the claims that must be present. ONCHAINID, the identity framework the standard is usually deployed with, frames the same idea from the holder's side: check counterparties against "proofs verified by trusted parties," and reuse "certified identity data (e.g. KYC check certificate) for compliance checks."³

isVerified and canTransfer answer different questions

Practitioners conflate these two constantly, and the spec draws the line precisely. "isVerified only checks the eligibility of an investor to hold and receive tokens, the canTransfer function is looking at global compliance rules, e.g. check if the transfer is compliant in the case there is a fixed maximum number of token holders to respect (can be a limited number of holders per country as well), check if the transfer respects rules setting a maximum amount of tokens per investor."¹

So isVerified is a question about a person. canTransfer is a question about the cap table. A perfectly eligible investor with current KYC claims will still be rejected if accepting the transfer would push the register past a holder count or a concentration limit. Every rule that is really a cap-table invariant belongs in the Compliance contract, and every rule that is really a statement about a person belongs in the claims.

One transfer, and the numbers that reject it

Take a fund token with 20,000,000 units outstanding, a Compliance contract configured for a maximum of 499 holders, a maximum of 149 holders resident in any single country, and a 10% cap on any one investor. Nothing about those three limits is unusual for a private placement, and none of them are visible in the token contract.

An existing holder tries to send 500,000 units to a new wallet. The Identity Registry resolves the receiving wallet to an ONCHAINID, checks that the required claim topics are present and signed by an issuer named in the Trusted Issuers Registry, and returns verified. That is isVerified done, and the transfer can still fail.

The Compliance contract then runs the cap-table arithmetic. Holder 500 is one over the limit, so the transfer reverts even though the investor is eligible. Change the facts: the receiver is holder 300 but already holds 1,700,000 units, and 1,700,000 plus 500,000 is 2,200,000, which is 11% of supply against a 2,000,000 cap. It reverts again, for a completely different reason. The failure message is the same to the user either way, which is why an issuer running this standard needs offchain tooling that can tell an investor which rule bit.

The powers the issuer keeps, and has to justify

The standard supports pausing and freezing, a forcedTransfer that "instruct[s] the Identity Registry to check if the receiver is a valid investor" before moving tokens without the holder's signature, and key recovery: "the recovery of security tokens in case an investor loses access to their wallet private key," with "a history of recovered tokens... maintained on the blockchain for transparency reasons."¹

Read those as what they are. A regulated issuer needs them, because a court order to reverse a transfer or a lost key at a pension fund is not a hypothetical. They are also, in aggregate, an admin capability set that any serious counterparty will ask you to document: who holds the keys, under what governance, with what evidence trail. Publishing that matrix before the first investor asks is the cheaper order of operations.

A named deployment: Hedera Asset Tokenization Studio

Hedera integrated ERC-3643 into its Asset Tokenization Studio in November 2025, describing the product as "an open-source, end-to-end toolkit designed for the configuration, issuance, and management of tokenized bonds and equities," with automated bond payments and dividends, investor verification and whitelisting, and issuer safeguards including transaction pausing and term updates.⁴

The positioning in that announcement is the useful part for a founder choosing a standard. Hedera runs ERC-3643 alongside its existing ERC-1400 implementation, and frames the split by jurisdiction: ERC-3643 as "a global, modular framework for non-US jurisdictions and cross-border operations, while ERC-1400 remains a trusted standard for US-based equity and bond issuers."⁴ Two standards on one network, chosen by where the investors are.

The ERC3643 Association describes the protocol as "an open-source suite of smart contracts that enables the issuance, management, and transfer of permissioned tokens," with ONCHAINID ensuring "only users meeting pre-defined conditions can become token holders, even on permissionless blockchains."² The association's own site reports more than 32 billion US dollars of assets tokenised on the standard and more than 20,000 active onchain identities.⁵ Both figures are self-reported by the standard's own ecosystem bodies and have not been checked here against an independent onchain analytics source, so treat them as adoption signal rather than audited data.

What permissioning costs you in distribution

A token that reverts on transfer to an unverified address cannot sit in a permissionless automated market maker pool, cannot be posted as collateral in a lending market that does not know your Identity Registry, and cannot cross a generic bridge. That is not a bug in the standard. It is the standard doing exactly what it says.

It does mean your distribution surface is chosen at the same moment as your compliance stack, usually by an engineer who was not in the room for the distribution conversation. Write down the venues, custodians and counterparties you need to reach before selecting the standard, then check each one against the whitelist model. The cases we see go wrong are almost never a contract bug. They are a listing conversation six months later with a venue that cannot hold a permissioned asset.

What to settle before you pick it

Four things, in order. Which claims your investors must carry and who is trusted to sign them, because that decides your onboarding cost and your Trusted Issuers Registry. Which rules are cap-table invariants that belong in the Compliance contract, expressed as numbers rather than intentions. Whether one Identity Registry Storage should be shared across a product family or kept per issuance. And which venues you need, tested against the whitelist before anything is deployed.

In our view the deeper reason ERC-3643 is picked well or badly is governance, not code. The standard hands an issuer freeze, forced transfer and recovery powers, and hands a compliance function the ability to change transfer rules on a live asset. If nobody has written down who may pull those levers and on what authority, the contract is enforcing rules that no one owns.

One caution. Whether a specific token is a security, and which regime applies to a specific issuance in a specific jurisdiction, is fact-specific and belongs to your counsel. A permissioned token standard is a way to implement restrictions counsel has already specified. It is not itself a compliance opinion. This page is reference material for design work. It is not legal advice, and it is not a recommendation to buy, sell or hold any asset.