ERC-3643 Permissioned Token Standard
Abbreviation: ERC-3643
Pronunciation: EE-AR-SEE three-thousand-six-hundred-forty-three
Also known as: ERC-3643
Definition
ERC-3643 defines permissioned token interfaces that enforce identity and compliance checks for regulated real-world assets and security-token transfers. The architecture separates token balances from identity claims, trusted issuers, compliance modules, and administrative roles. It can support minting, burning, freezing, recovery, pausing, and forced transfers where the implementation grants those powers.
Overview
Meaning and scope
ERC-3643 defines permissioned token interfaces that enforce identity and compliance checks for regulated real-world assets and security-token transfers. The architecture separates token balances from identity claims, trusted issuers, compliance modules, and administrative roles. It can support minting, burning, freezing, recovery, pausing, and forced transfers where the implementation grants those powers.
Mechanism and operation
ERC-3643 standardizes a permissioned-token architecture commonly associated with the T-REX framework. Token transfers consult identity and compliance contracts so only eligible participants and authorized transactions can proceed under configured rules. Integrators should verify every deployed contract, identity registry, claim issuer, compliance configuration, agent role, and upgrade authority. Teams adopting ERC-3643 should track errata, compatibility changes, and the deployed software versions that enforce it. In ERC-3643 implementations, a published standard does not prove universal adoption, safe implementation, or activation on a particular blockchain or payment network. Operational records for ERC-3643 should retain the version and configuration used for each relevant transaction or message.
Practical payment example
A security-token transfer checks an investor’s eligibility through the configured identity and compliance modules before the token contract permits movement.
Operational checks
In ERC-3643 implementations, this allows reproducible debugging when a later upgrade changes parsing, validation, signing, or interoperability behavior. ERC-3643 should be implemented against an exact document revision, status, and activation context. In ERC-3643 implementations, draft, final, optional, and network-activated specifications have different authority, and similarly named deployments may support different subsets or extensions.
Distinctions and limits
A successful technical eligibility check does not replace legal due diligence. Wallets and custodians must disclose transfer restrictions and administrator controls because these assets do not behave like unrestricted bearer tokens. Conformance to ERC-3643 requires more than matching a field name or example.
Related reading
Related definitions: payment network, transaction.
Example
A security-token transfer checks an investor’s eligibility through the configured identity and compliance modules before the token contract permits movement.
Comparison
Wallets and custodians must disclose transfer restrictions and administrator controls because these assets do not behave like unrestricted bearer tokens. In ERC-3643 implementations, a published standard does not prove universal adoption, safe implementation, or activation on a particular blockchain or payment network.
Key Takeaway
ERC-3643 standardizes compliance-controlled tokens, making identity registries, rule modules, administrator powers, and legal validity essential.
Sources
- Ethereum Improvement Proposal EIP-3643 — Ethereum Foundation (2026-07-30)
- Ethereum Documentation: Smart Contracts — Ethereum Foundation (2026-07-30)
- Ethereum Documentation: Transactions — Ethereum Foundation (2026-07-30)