ERC-3643 or ERC-20 for a Fund: How to Actually Decide

The token standard is downstream of one legal fact — who is allowed to hold your units. The ten-minute decision, the mechanics behind it, and why compliance cannot be retrofitted later.

29 September 2026 · 11 min read

Almost every fund that asks this question asks it as a technology question. It is not. The token standard you choose is downstream of a single legal fact — who is allowed to hold your units — and once you accept that, the decision takes about ten minutes. Getting it wrong takes about nine months to undo.

In short

If the law restricts who may hold your units, the restriction has to live in the token. ERC-20 cannot express it; ERC-3643 can.
ERC-3643 is not an alternative to ERC-20 — it is ERC-20 plus a mandatory eligibility check on every transfer, so existing wallets and custodians can still read it.
ERC-20 is the right answer for the cash leg, for a wrapper whose register stays authoritative off-chain, and for nothing else in a regulated fund.
You cannot retrofit compliance onto a token that is already distributed. That is the whole cost of the decision.

The question behind the question

A fund unit is a financial instrument. That single classification drags in a body of law — offer restrictions, investor eligibility, jurisdictional caps, holding periods, beneficial-ownership reporting — that has nothing to do with blockchains and does not stop applying because you issued on one.

So before comparing standards, answer four questions about your own fund:

Can anyone hold a unit, or only a defined set of investors? Professional-only, accredited-only, jurisdiction-excluded, minimum-subscription — any of these is a restriction on holding.
Is the on-chain balance the register, or a mirror of it? If the transfer agent's book is authoritative and the token is a convenience layer, your constraints are very different.
Do units move between investors, or only to and from the fund? A closed-ended vehicle with no secondary transfers has almost no transfer-control problem.
Who is accountable when an ineligible party ends up holding? In practice: you are.

If the answer to the first question is "only a defined set", the restriction must be enforced somewhere. Your options are to enforce it in the token, or to enforce it by trusting every party who ever touches the token to check first. The second is not a control; it is a hope.

What ERC-20 actually gives you — and where it stops

ERC-20 is a balance ledger with an approval mechanism. It specifies transfer, transferFrom, approve, balanceOf and totalSupply. It is deliberately, usefully minimal, and that minimalism is why it won: every wallet, exchange, custodian, accounting system and block explorer on earth speaks it.

What the standard does not contain is any notion of who a holder is. An ERC-20 transfer to a well-formed address succeeds. The token has no opinion about whether the recipient passed KYC, lives in a sanctioned jurisdiction, is a retail investor buying a professional-only product, or is a smart contract that will fractionalise your units to 4,000 strangers by Friday.

Teams try to close that gap three ways, and all three leak:

A blocklist in the token. You can add a modifier that rejects known-bad addresses. It is the wrong polarity: a blocklist is default-allow, and a new address is by definition unknown to it.
Off-chain gating at the app. Your front end refuses to send to ineligible wallets. The token does not, and the token is what the rest of the world transacts against. Anyone can call the contract directly.
A transfer-approval queue. Every transfer waits for an operator to sign off. This works, and it is how plenty of early security tokens ran, but you have now rebuilt a manual transfer agent and lost the settlement finality that was the reason to tokenise.

An ERC-20 with a blocklist bolted on is a permissionless token that you have promised to supervise. That promise is the part regulators test.

What ERC-3643 adds, mechanically

ERC-3643 — implemented as the T-REX suite, originally from Tokeny and now stewarded by the ERC-3643 Association — keeps the full ERC-20 interface and inserts a mandatory eligibility check in the transfer path. If the check fails, the transaction reverts on-chain. There is no path around it, including for the issuer.

It is not one contract but a small set of them, and the separation matters because it is what lets you change policy without reissuing the token:

Identity registry — maps each permitted wallet to an on-chain identity contract (ONCHAINID). It answers one question: is this address verified to hold this token?
Trusted issuers registry — which KYC providers, fund administrators or verification agents you accept claims from.
Claim topics registry — which claims a holder must carry: identity verified, accreditation, country of residence, and so on.
Modular compliance — the rules that are about the transfer rather than the holder: country caps, maximum holder counts, per-investor balance ceilings, lock-up windows, transfer-size limits. Modules are plugged in and swapped individually.
The token — ERC-20 on the outside, with an agent role that can mint, burn, freeze a balance in part or whole, pause the token, force a transfer, and recover a holder's balance to a new wallet when keys are lost.

Both checks are on-chain and unconditional. The same logic is exposed as a read-only canTransfer call, so a custodian or a front end can test a transfer before submitting it — the difference between a clear error message and a failed transaction the investor pays for.

Two features tend to decide the argument inside operations teams, and neither is about compliance:

Key recovery. A bearer instrument that vanishes when an investor loses a laptop is not an institutional product. Because ERC-3643 binds balances to an identity rather than only to an address, an agent can reissue a holder's position to a new wallet under the same identity — which, as the custody models piece sets out, splits control of the asset across two parties. You are not relying on the investor's backup discipline to preserve their subscription.

Forced transfer. Courts order transfers. Estates get distributed. Errors get corrected. An agent-executed forced transfer lets you comply with an order without the contortions required when the only way to move a token is the holder's private key.

Is ERC-3643 compatible with ERC-20 wallets and custodians? Yes for reading and holding — it implements the full ERC-20 interface, so balances, transfers and approvals appear normally in any ERC-20-aware system. The difference is behavioural, not structural: a transfer to an unverified address reverts instead of succeeding. Infrastructure that assumes every valid-looking transfer will settle needs to handle that revert, which is why the read-only pre-flight check matters in integration work.

The comparison that actually matters

Requirement	ERC-20	ERC-3643
Restrict holding to verified investors	No — enforced only by convention	Yes — enforced in the transfer path
Jurisdiction and holder-count caps	No	Yes — compliance modules
Lock-ups and holding periods	Custom code per token	Module, configurable post-issuance
Recover a lost-key position	No — balance is stranded	Yes — reissue under the same identity
Comply with a court-ordered transfer	No without a custom backdoor	Yes — agent forced transfer
Freeze a specific holder	Custom code	Full or partial balance freeze
Trade on a public AMM	Yes	No — and that is the point
Change policy without reissuing	No	Yes — swap a module
Integration burden on counterparties	Lowest possible	Must handle reverts and onboarding

Read the last two rows together, because they are the real trade. ERC-3643 buys you enforceable control and costs you frictionless composability. A permissioned token cannot sit in a public liquidity pool, because a pool is an unverified address holding units for anonymous depositors. If your distribution thesis depends on that, you do not have a compliance problem — you have a product that regulated fund units cannot be.

When ERC-20 is genuinely the right answer

It is worth being precise here, because "use ERC-3643 for everything" is bad advice too.

The cash leg. Subscriptions and redemptions settle in a stablecoin or tokenised deposit, and that instrument is somebody else's ERC-20. You are a taker of that standard, not a chooser.
A mirror token over an authoritative off-chain register. If the transfer agent's book remains the legal register and the token is a reporting or collateral convenience that never moves between investors, ERC-20 plus tight minting control can be defensible. Be honest about what you have built: this is not a tokenised fund, it is a fund with a token attached.
A single-holder or wholly-internal vehicle. No secondary transfers, one verified counterparty, controls elsewhere.
Utility and governance tokens — which is what ERC-20 was designed for and remains excellent at.

Everything else that a securities regulator would recognise as a fund unit belongs in a permissioned standard. If ERC-3643 does not fit your structure, the honest alternative to compare against is the ERC-1400 family, which models partitioned share classes — not plain ERC-20.

The retrofit trap

The single most expensive mistake in this space is launching on ERC-20 to "move fast" and planning to add compliance later. You cannot. Compliance in ERC-3643 lives in the token's transfer path, and you cannot change the code of a token that is already distributed across holders you do not control.

What you can do is issue a new compliant token and move everyone across, which in practice means: onboard and verify every existing holder before they can receive anything; force-transfer or burn-and-reissue balances; handle the holders who have gone quiet, and the ones who have moved units to addresses you cannot identify; restate the register; and explain to your auditor why the register was wrong for the period in between.

Budget that as a project, not a migration script. It is the reason the standard decision deserves ten minutes of clear thinking at the start rather than a retrofit later.

The ten-minute decision

Write down who may legally hold a unit. If that list is narrower than "anyone", continue.
Decide whether the on-chain balance is the register or a mirror. If it is the register, you need enforcement in the token.
List the rules that must hold at all times: eligibility, jurisdiction caps, holder counts, lock-ups. Each one maps to a compliance module — or to a manual process you will run forever.
Decide who holds the agent keys, and how a forced transfer or a recovery gets authorised. This is a governance question and it will take longer than the technical build.
Confirm your distribution route can transact a permissioned token. If it cannot, resolve that before writing a contract.

Can a tokenised fund use ERC-3643 and still offer liquidity? Yes, but through venues that can verify participants rather than through open pools — regulated trading venues, alternative trading systems, broker-dealer networks, or bilateral matching with settlement on-chain. Each participant is onboarded to the token's identity registry once and can then trade freely within the rules. The liquidity is real; it is permissioned, and it arrives through relationships rather than through listing on an AMM.

A note on scope. This piece is about the token standard. It does not settle where your fund is domiciled, which regime it is offered under, who acts as transfer agent, or how the cash leg settles — all of which shape the build more than the standard does. ERC-3643 is a control mechanism, not a licence, and nothing here is legal advice on your structure.