Category: permissioned-token standard / regulated-asset compliance control plane / identity-gated security-token infrastructure
Summary: ERC-3643 is best understood as a full regulated-token operating stack rather than as a thin token-interface tweak. Its primary materials describe an ERC-20-compatible security-token standard wired into onchain identity, trusted claim issuers, claim-topic registries, transfer-compliance modules, recovery flows, agent roles, forced transfers, freezes, and token pausing. The reusable mechanism insight is that ERC-3643 makes “permissioned tokenization” a modular but still opinionated control plane: the token is only one piece, while issuer-selected identity registries, compliance logic, and agent permissions determine who can hold assets, who can move them, and who can override ordinary transfer rights.
What it does:
Defines an ERC-20-compatible standard for permissioned security tokens and other compliant tokenized assets
Requires integration with an onchain identity system so receivers can be checked against trusted claims and trusted issuers before transfers settle
Separates investor eligibility from transfer-rule enforcement through distinct identity-registry and compliance-contract layers
Adds issuer/agent control surfaces such as pausing, wallet freezing, partial token freezing, minting, burning, forced transfers, and address recovery
Supports batch operations for regulated-token administration and lifecycle management
Uses ERC-173 ownership plus agent roles so issuers or delegated operators can administer token controls and compliance-linked actions
Key claims:
The EIP abstract says ERC-3643 is an institutional-grade security-token standard built around automated onchain validation using onchain identities for eligibility checks
The specification says a compliant transfer requires enough unfrozen balance, verified receiver identity, unfrozen sender/receiver wallets, an unpaused token, and a passing compliance check, which makes the token’s transfer path explicitly policy-gated rather than merely blacklist-aware
The EIP distinguishes isVerified identity checks from canTransfer global compliance checks, which matters because it separates holder eligibility from issuance-level market rules like holder caps or jurisdictional limits
The standard includes recovery, force-transfer, freeze, and pause functionality, which is the clearest signal that ERC-3643 is designed for issuer and regulator intervention rather than censorship-resistant neutrality
Tokeny’s docs say the protocol was opened up beyond its original creator and is now stewarded through the ERC3643 association, while the repository README frames T-REX as a comprehensive contract suite rather than a single interface
The README identifies ONCHAINID, trusted issuers, claim-topic registries, identity registries, compliance contracts, and the token contract itself as distinct components, revealing where practical control can fragment across vendors and operators even inside one “standard”
Relative to newer minimal RWA interfaces like ERC-7943, ERC-3643 is much more opinionated about identity and compliance plumbing, which makes it a useful anchor for comparing thick regulated-token stacks against thinner interoperability layers
Whitepaper: Official ERC-3643 materials point to a standalone T-REX v4 whitepaper, but this pass relied mainly on the EIP, official docs, and the core repository README; see ../../whitepapers/erc-3643-primary-sources-2026-05-08.md.