ERC-3643 is a Final Ethereum standard for permissioned tokens, derived from the T-REX (Token for Regulated EXchanges) protocol. It is ERC-20-compatible, but every transfer is validated against an on-chain identity registry and a set of compliance rules — so tokens can only ever be held by eligible, verified investors. It has become the most widely adopted standard for tokenized securities on EVM chains and is supported by a non-profit industry association of issuers, custodians, law firms and technology providers.
Key takeaways
- ERC-3643 = ERC-20 token + Identity Registry + Trusted Issuers Registry + Claim Topics Registry + Modular Compliance.
- Investor identities are ONCHAINID contracts holding signed claims (e.g. “KYC passed”, “accredited investor”, “country = DE”) from trusted issuers — personal data stays off-chain.
- Agents can mint, burn, pause, freeze full or partial balances, force transfers and recover lost wallets — the controls regulators and transfer agents expect.
- It is the default choice for equity, debt, fund units and SPV shares; for portfolios of many asset types, compare with ERC-1155.
Why permissioned tokens exist
Securities laws require issuers and their agents to know who holds a security, to restrict who may buy it, and to act on regulatory or court instructions. A plain ERC-20 token cannot do any of that: once tokens leave the issuer, they can go anywhere. ERC-3643 moves eligibility into the token itself, so compliance does not depend on every exchange or wallet behaving correctly.
Architecture
| Contract | What it does |
|---|---|
| Token | ERC-20 interface plus agent functions; calls the registry and compliance on every transfer |
| Identity Registry | Links each wallet to an ONCHAINID and stores the investor’s country code |
| Identity Registry Storage | Separates storage so several tokens can share one investor registry |
| Trusted Issuers Registry | Lists which claim issuers (KYC providers, agents) are trusted for which claim topics |
| Claim Topics Registry | Lists the claim topics a holder must have to be “verified” |
| Modular Compliance | Holds pluggable modules: country allow/deny lists, max balance, max holders, time-based limits, transfer fees and more |
The transfer flow
- A holder calls
transfer(to, amount). - The token checks the sender is not frozen and has enough unfrozen balance.
identityRegistry.isVerified(to)confirms the receiver has an ONCHAINID with valid claims for every required topic, signed by a trusted issuer.compliance.canTransfer(from, to, amount)asks every module whether the transfer is allowed.- If all checks pass, balances update and modules are notified to update their state (e.g. holder counts).
If any check fails, the transaction reverts and the tokens stay put.
ONCHAINID and claims
ONCHAINID is a smart-contract identity (based on the ERC-734/735 key and claim pattern) owned by the investor or managed on their behalf. A KYC provider verifies the investor off-chain, then signs a claim for a topic such as “KYC/AML verified” and adds it to the identity. The token never sees a passport — only a signature from an issuer it trusts. Revoking or expiring a claim immediately prevents further receipts. Our guide to KYC, AML and on-chain identity covers design choices in depth.
Agent and issuer controls
| Control | Typical use |
|---|---|
mint / burn (and batch) |
Subscriptions, redemptions, corporate actions |
pause / unpause |
Halting trading during corporate events or incidents |
setAddressFrozen |
Freezing a wallet on regulatory instruction |
freezePartialTokens |
Locking part of a balance (lock-ups, pledges, disputes) |
forcedTransfer |
Court orders, error correction, estate transfers |
recoveryAddress |
Moving a lost wallet’s tokens to a new verified wallet |
These powers are significant, so in production we place them behind multisig wallets or governed contracts, log every action and disclose them in offering documents.
Ideal use cases
- Tokenized equity and private company shares — cap table always current, transfer restrictions enforced.
- Bonds and notes — eligible-investor rules, coupon payments, redemptions.
- Fund units — subscription and redemption with investor eligibility checks; pair with ERC-7540 for asynchronous flows.
- Real estate SPV shares — cross-border investor bases with country-specific rules. See real estate tokenization.
- Private credit notes — restricted to qualified investors. See private credit tokenization.
Implementation pitfalls we see
- Over-engineered compliance modules. Each module adds gas to every transfer. Encode the rules counsel actually requires; handle edge cases with agent actions.
- Claim expiry not planned. KYC refresh cycles mean claims expire. Design renewal flows before holders find they cannot receive distributions.
- Shared registries without governance. Several tokens can share one identity storage — powerful, but changes affect all of them. Treat it like core infrastructure.
- Ignoring DeFi integration. Pools and vaults that should hold tokens need identities too. Plan which contracts are verified.
- Single-key agents. Never leave agent or owner roles on one externally owned account.
ERC-3643 vs other security token standards
| ERC-3643 | ERC-1400 family | ERC-1404 | ERC-7943 | |
|---|---|---|---|---|
| Status | Final | Never finalised | Proposal | Final (2026) |
| Identity model | ONCHAINID claims | Off-chain / custom | Custom | Implementation-defined |
| Partitions | No (use separate tokens) | Yes (ERC-1410) | No | No |
| Scope | Full framework | Full framework | Minimal interface | Minimal interface |
Read ERC-3643 vs ERC-1400 and ERC-7943 for the details.
Deploying an ERC-3643 token: the practical sequence
A typical production deployment follows this order. Each step is a governance event that should be recorded and, ideally, executed by a multisig.
- Deploy (or reuse) identity infrastructure — Identity Registry Storage shared across your tokens, the Claim Topics Registry and Trusted Issuers Registry.
- Define claim topics — for example
KYC_VERIFIED,AML_CLEARED,PROFESSIONAL_INVESTOR,COUNTRY— matching the eligibility rules your counsel specifies. - Register trusted issuers — your regulated KYC provider(s), and any agent allowed to issue specific claims.
- Deploy Modular Compliance and add modules: country allow-list, maximum holders, maximum balance per investor, lock-up periods.
- Deploy the token (usually through a factory and proxy), link the registry and compliance contracts, and assign agent roles.
- Onboard investors — create or link ONCHAINIDs, have issuers add claims, register wallets in the Identity Registry.
- Mint against confirmed subscriptions.
- Verify and monitor — verify contracts on the explorer, configure alerts for agent actions.
Choosing compliance modules
| Rule from offering documents | Module pattern |
|---|---|
| Only residents of listed countries | Country allow-list (or deny-list) |
| Maximum number of holders (exemption limits) | Max-holders module |
| Single investor may not exceed X% | Max-balance / ownership-cap module |
| 12-month holding period | Time-based transfer restriction or partial freeze |
| Daily transfer limit | Transfer-volume module |
| Transfer fee to issuer | Fee module |
Keep modules few and well tested. Every module runs on every transfer, adding gas and failure modes.
Running corporate actions on ERC-3643
- Dividends and coupons: snapshot balances at the record date and distribute stablecoins pro-rata, or pay off-chain using the register exported from the token.
- Redemptions: burn tokens against payment confirmation; combine with ERC-7540 for queued fund redemptions.
- Splits and consolidations: mint or burn pro-rata through batch agent functions.
- Votes: use balance snapshots; ERC-3643 does not define voting, so add a governance module.
Operating model: who does what
| Role | Responsibilities |
|---|---|
| Issuer / owner | Governs registries, compliance and agent appointments |
| Token agent (often transfer agent) | Mints, burns, freezes, forced transfers, recoveries |
| Claim issuers (KYC providers) | Verify investors and sign claims |
| Investors | Hold verified identities and wallets |
| Platform operator (e.g. NUVZ-built) | Portals, integrations, monitoring, reporting |
Clarity here is as important as code: auditors and regulators will ask who can do what, and how actions are approved and logged.
Frequently asked questions
Yes. Balances and transfers use the ERC-20 interface, so wallets display tokens normally. Transfers simply fail if the receiver is not eligible.
No. Only identity contract addresses, country codes and signed claims are on-chain. KYC documents stay with the regulated provider.
Yes, where the protocol’s contracts are given verified identities or compliance modules permit them. Fully permissionless pools cannot hold them.
No. It runs on any EVM chain, including Polygon, Avalanche, Base and permissioned EVM networks.
Deploying the contracts is quick; the real work is identity onboarding, compliance rules, investor portals, integrations and audits. See our cost and timeline guide.
Yes. Sharing Identity Registry Storage lets an investor onboard once and invest in many tokens issued under the same framework.
Contracts can be deployed in days. A full platform with onboarding, portals, payments and audit typically takes a few months — see our cost and timeline guide.
Yes, through Hedera’s EVM-compatible smart contract service, with attention to Hedera account and fee specifics.
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
