ERC-3643 in practice: what it solves and what it leaves to you

Xora Labs RWA  ·  10 min read

The standard gives you permissioned transfers and an identity hook. Everything that makes a security token actually compliant is still your design problem.

What the standard is

ERC-3643 is a permissioned token standard. It keeps the ERC-20 interface so wallets and explorers work, and adds two things: every holder is bound to an on-chain identity, and every transfer is checked against a compliance contract before it executes. A transfer that fails the check reverts.

That is a genuinely useful primitive. It moves the restriction from a legal agreement nobody can enforce at settlement time into code that runs at settlement time.

What it actually solves

• Enforcement at the token layer. A restricted token cannot be moved to an unverified address, including through a DEX, because the check runs regardless of who initiated the transfer.
• Identity without publishing identity. The chain holds a reference to a verified identity and a set of claims, not the underlying documents.
• Recovery. Lost keys are a real and frequent problem for issuers with retail holders. The standard has a defined path to reissue a holder's balance to a new wallet, which unregulated token standards simply do not.
• Forced transfers and freezing. Uncomfortable, and required in most jurisdictions for court orders and error correction.

What it leaves entirely to you

This is the part that decides whether a deployment survives contact with counsel.

• The compliance rules themselves. The standard defines where the check happens, not what it checks. Jurisdiction limits, holder caps, lock-ups, accreditation tiers and volume restrictions are all yours to write.
• Who runs the identity registry. Somebody decides which claim issuers are trusted. That role is operationally and legally significant, and it is a centralisation point no standard can remove.
• Key management for privileged roles. The agent role can freeze balances and force transfers. If that key is a single EOA on somebody's laptop, the token's compliance guarantees are worth exactly that key's security.
• Cross-jurisdiction conflicts. When a holder in one country sells to a holder in another, whose rules apply? The contract needs one deterministic answer, and the standard has no opinion.
• Liquidity. A permissioned token cannot trade on a permissionless AMM without every counterparty being verified. That is a market-structure consequence, not a bug, but issuers are regularly surprised by it.

The questions we ask before writing any of it

• Who are the permitted holders, expressed as rules rather than a list?
• What happens on the day a rule changes, to holders who were compliant under the old one?
• Who signs a forced transfer, and what evidence is recorded alongside it?
• What does the regulator need to see two years from now, and can it be reconstructed from chain state alone?

That last question is the one that separates a token that works from a token that holds up. We have written about how to design for it in designing transfer restrictions a regulator will accept.

Working on something in this area? Tell us about it.