ERC-3643 and RWA tokenization infrastructure: a practical guide

ERC-3643 is a finalized Ethereum standard for permissioned tokens: an ERC-20 that refuses any transfer unless the receiving wallet is linked to a verified onchain identity and the transfer passes a set of compliance rules. If you are tokenizing a security, a fund share or anything else where the law says who can hold it, ERC-3643 is the default starting point for your RWA tokenization infrastructure in 2026. It is not the only option, and for some products it is more machinery than you need.

Below: how the standard works at the contract level, where it hurts, and how it stacks up against ERC-1400, the newer ERC-7943 and the "ERC-20 plus allowlist" setup many teams start with.

Why RWA tokens need permissioning at all

A normal ERC-20 lets anyone send to anyone. That is fine for a governance token. It breaks the moment the token represents a security, because securities law follows the asset onto the chain. If a US fund can only be sold to qualified purchasers, the token for that fund can only sit in wallets owned by verified qualified purchasers. Securitize's BUIDL token for BlackRock works exactly this way: issuance and transfers are restricted to KYC-verified holders.

The market is real but still small. RWA.xyz shows about $39.3B in distributed tokenized assets at the end of October 2026, with treasury funds like USDY, USYC and BUIDL each above $2B. For background on asset classes and market structure, see our RWA overview. This post stays at the token layer.

Here is what an RWA token needs that plain ERC-20 doesn't have:

• Eligibility checks on every transfer, mint and receive.
• Freezing a wallet or part of a balance (court order, sanctions hit, dispute).
• Forced transfers by an authorized agent (inheritance, error correction, legal enforcement).
• Recovery of tokens when an investor loses their keys, without a new KYC round.
• Offering-level rules such as maximum holders, country restrictions or lockups.

Each standard below packages those differently.

How ERC-3643 works

ERC-3643, also called T-REX (Token for Regulated EXchanges), was created in July 2021 by the Tokeny team and is listed with Final status. It requires ERC-20 and ERC-173 (ownership), so it stays compatible with wallets and most tooling. The difference is that transfer and transferFrom run two checks first.

The contract set

A full ERC-3643 deployment is around six contracts per token, plus one identity contract per investor:

The investor side is ONCHAINID, an implementation of ERC-734 (keys) and ERC-735 (claims). Each investor gets an identity contract once. KYC providers sign claims onto it. Each issuer can hold one claim per topic per identity, and a new claim of the same topic overwrites the old one.

What happens on a transfer

1. The token asks the Identity Registry whether the receiver is verified. The registry looks up the receiver's identity, checks it holds every required claim topic, and checks each claim was signed by an issuer in the Trusted Issuers Registry.
2. The token asks the Compliance contract canTransfer(from, to, amount). This is a view call, so a frontend can pre-check a transfer and show the user why it would fail.
3. If both pass, the transfer goes through and the token calls back into compliance (transferred) so stateful rules, such as holder counts or monthly volume, stay current.

Agents and admin powers

The owner appoints agents through addAgent and removeAgent. Agents can mint, burn, freeze wallets (setAddressFrozen), freeze part of a balance (freezePartialTokens), pause the token, and run forcedTransfer. The spec is explicit that a forced transfer still checks the receiver is verified but may bypass compliance rules, and that mint checks eligibility but skips compliance. recoveryAddress moves a lost wallet's balance to a new wallet tied to the same identity.

People from DeFi find this uncomfortable. It is the point. A transfer agent who cannot correct the register is not a transfer agent.

Compliance modules

The reference implementation ships a ModularCompliance contract that you plug modules into. The T-REX repository includes modules for country allow and block lists, maximum balance per investor, supply limits, time-based transfer limits, exchange monthly limits, conditional transfers (agent approval per transfer), transfer fees and transfer restrictions. You can swap modules without redeploying the token. Offering rules change more often than anyone plans for, so this matters.

Where ERC-3643 gets painful

We like the standard. It also has costs that vendor material tends to skip.

Gas and contract count. Each transfer walks the registry, reads claims from identity contracts and runs every bound compliance module. That is several external calls per transfer. On Ethereum L1 that adds up; on an L2 it mostly doesn't. Measure your actual transfer gas with your real module set before you commit to a chain. Our chain cost comparison has baseline numbers.

DeFi composability. An AMM pool or lending market is just another address. If it has no identity, it cannot receive the token. You either register the pool contract with an identity and claims, build a permissioned pool, or accept that the token lives only on your own venue and a few integrated platforms. Decide this early, because "we will list on a DEX later" is the most common unplanned rework we see.

Identity is someone else's database. The token trusts claim issuers. If your KYC provider's claims expire, every affected holder silently becomes unable to receive. You need a process for claim renewal and monitoring, plus a support flow for "my transfer fails and I don't know why."

Upgradeability. The reference contracts sit behind proxies. That is usually right for a regulated asset, but it moves risk to whoever controls upgrades. Read our guide to upgradeable smart contracts before you decide who holds the proxy admin, and put a timelock on it.

Privacy. Claims and the investor-to-wallet mapping are onchain. Claim contents can be hashed, but the fact that a wallet is a verified holder of a specific fund is public. Some issuers accept that. Others will not, which pushes you toward private chains, confidential token variants or offchain registers.

The alternatives

ERC-1400

ERC-1400 came out of Polymath in 2018 and bundles four proposals: ERC-1410 (partitions, i.e. partially fungible balances), ERC-1594 (transfer checks with reason codes), ERC-1643 (document management) and ERC-1644 (controller/forced transfers). It never reached Final status. Taurus also notes that Polymath's own implementation does not appear to have been publicly maintained since 2019.

Partitions are the one feature ERC-1400 has that the others do not. If one token contract has to track locked versus unlocked tranches, or different share classes, partitions model that directly. You pay for it with a non-standard balance model that most wallets and indexers do not understand. We would not start a new product on ERC-1400 in 2026 unless you are integrating with a platform that already runs it.

ERC-7943 (uRWA)

ERC-7943, the Universal RWA Interface, was created in June 2025 and is now Final. It takes the opposite approach to ERC-3643: a minimal interface (canSend, canReceive, canTransfer, forcedTransfer, setFrozenTokens, getFrozenTokens) that can sit on top of ERC-20, ERC-721, ERC-1155 or ERC-6909. It says nothing about how you verify identity. Pausing, metadata and identity integrations are left out on purpose.

That makes ERC-7943 useful when your asset is not fungible (individual property deeds, invoices, art) or when you already have an identity system and just want integrators to have one standard interface to call. It does not give you the registry and compliance architecture, so you write that yourself or adopt someone else's.

CMTAT

CMTAT is the Capital Markets and Technology Association's open-source framework, designed for securities under Swiss law. It is not an ERC. It extends ERC-20 with pause, freeze, a rule engine for conditional transfers, document management and proxy upgradeability, and it is MPL-2.0 licensed. In Taurus's comparison, ERC-3643 is the only one of the three with onchain identity management, while CMTAT and ERC-1400 include document management.

Plain ERC-20 with an allowlist

The simplest version: an OpenZeppelin ERC-20 with a _update hook that checks both parties against a mapping the issuer controls, plus pause, freeze and an admin transfer function.

This is a legitimate choice for a single-issuer product with a small, known investor base and one KYC provider. It is cheap to audit and cheap per transfer. It falls apart when you need investors to reuse identity across tokens, when several KYC providers are involved, or when a regulator or distribution partner expects a recognized standard. Retrofitting ERC-3643 later means migrating the register, which is a legal event as much as a technical one.

Side-by-side

How we would choose

Start from the legal structure, not the code. Your lawyers will tell you who may hold the asset, under which exemption, in which countries, and with what resale limits. Our real estate tokenization guide walks through that for one asset class. Then:

1. Many investors, several distributors, recurring issuance? ERC-3643. Shared identity across tokens is worth the setup cost the second time you issue.
2. Non-fungible or semi-fungible assets? ERC-7943 on ERC-721 or ERC-1155, with your own eligibility logic behind canReceive.
3. One issuer, under a few hundred investors, a pilot? ERC-20 with an allowlist, written so the transfer hook can later call an ERC-3643-style registry. Treat it as a pilot, not the final architecture.
4. Swiss issuance, or a custodian that already runs CMTAT? Use CMTAT.
5. Must trade on public DeFi venues from day one? Rethink the asset first. Either it is permissionless, or the venues must be permissioned. There is no token standard that resolves this for you.

Implementation checklist

Whichever standard you pick, work through these before launch. Most first-year problems we see trace back to one of them:

• Key map. Who holds owner, agent, proxy admin and claim-issuer keys. Use multisigs and hardware signers, and write down the procedure for each admin action.
• Off-chain register. The legal register of holders often still lives with a transfer agent. Define which one wins if they disagree.
• Claim lifecycle. Expiry, renewal, revocation and what the UI shows when a claim lapses.
• Recovery flow. Who verifies a lost-key request and how long it takes.
• Compliance tests. Unit tests per module, plus fuzzing of transfer paths against eligibility rules.
• Audit. Audit your modules and any changes to the reference code. Our audit preparation checklist covers what auditors will ask for.
• Indexing. Your investor dashboard, cap table and reporting need an indexer that tracks freezes, forced transfers and recoveries as well as Transfer events.

This is the work our digital and RWA platforms team does day to day.

FAQ

Is ERC-3643 an official Ethereum standard?

Yes. EIP-3643 is listed as Final in the ERC track. It is maintained by the ERC3643 Association, a Luxembourg non-profit founded in 2023.

What is the difference between ERC-3643 and ERC-1400?

ERC-3643 includes an identity system (ONCHAINID with trusted claim issuers) and modular compliance on a standard ERC-20 balance model. ERC-1400 uses partitioned balances, includes document management, has no identity model, and was never finalized.

Can ERC-3643 tokens be used in DeFi?

Only with venues whose contracts are registered as eligible holders, or with permissioned pools built for the token. A standard Uniswap-style pool has no identity, so transfers into it revert.

Does ERC-3643 work on chains other than Ethereum?

It works on any EVM chain, including L2s, where per-transfer gas is far cheaper. Non-EVM chains need a separate implementation.

Do I need ERC-3643 for a tokenized fund pilot?

Not always. A small single-issuer pilot can run on an ERC-20 with an allowlist. Decide the migration path before launch: moving a live register to a new contract needs sign-off from lawyers and, usually, investors.

Who can freeze or force-transfer ERC-3643 tokens?

Agents appointed by the token owner. Those keys should sit in a multisig with a documented approval process, since regulators and investors will ask who controls them.

Talk to us

Stuck between ERC-3643, ERC-7943 and a plain allowlist? Send us the legal structure (who can hold it, where, under which exemption) and we'll tell you which contract setup fits and what it will take to build. Get in touch.