ERC-3643

• Name: ERC-3643 (T-REX / Token for Regulated EXchanges)
• URL: https://eips.ethereum.org/EIPS/eip-3643
• Category: permissioned-token standard / regulated-asset compliance control plane / identity-gated security-token infrastructure
• Tags: ethereum-ecosystem ethereum-standards
• Summary: ERC-3643 is a full regulated-token operating stack, not 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 token is only one piece; issuer-selected identity registries, compliance logic, and agent permissions still decide 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.
• Sources:
  • https://eips.ethereum.org/EIPS/eip-3643
  • https://docs.tokeny.com/docs/the-erc-3643-token-standard
  • https://github.com/ERC-3643/ERC-3643
  • https://raw.githubusercontent.com/ERC-3643/ERC-3643/master/README.md
  • https://erc3643.org/
  • https://docs.erc3643.org/

Internal linkages

• Keep the stack anchored on onchainid and tokeny.
• That is enough here: identity-contract sublayer plus the main company/operator wrapper around the standard.

Control surface

• ERC-3643 makes the override surface explicit. Identity registries, trusted-issuer lists, claim-topic registries, compliance modules, and agent roles decide who can receive, who can transfer, and who can be frozen, recovered, or force-moved.

• Read it as a regulated-token operating stack, not a thin token interface.

• Last reviewed: 2026-06-05 UTC