ERC-3643: the compliance token standard
ERC-3643 (T-REX - Token for Regulated EXchanges) is the EVM standard for compliance-first token issuance. Unlike ERC-20 (no built-in compliance) or ERC-1400 (permissioned but no unified identity layer), ERC-3643 has a decentralized Identity Registry at its core. Every transfer checks the receiver's on-chain identity claim - investor class, jurisdiction, accreditation - before executing.
The three components that make ERC-3643 different: the Identity Registry (ONCHAINID) stores verified claims about wallet holders, the Compliance module enforces configurable rules (max holders, jurisdiction limits, lock periods), and the Transfer Manager orchestrates the full compliance check pipeline on each transfer. This architecture keeps compliance logic on-chain and auditable rather than in off-chain API calls that can be bypassed.
ERC-3643 is the standard most commonly used for MiCA-compliant tokenization and security token platforms in the EU. If your platform needs investor classification, transfer restrictions, or compliance reporting tied to on-chain identity - ERC-3643 is the architecture to build on.
What you get
From ONCHAINID setup through compliance module configuration to KYC provider integration and operational tooling.
Full ERC-3643 implementation stack: contracts, identity layer, and backend integration.
Token contract & compliance modules
+ERC-3643 token deployment with configurable compliance modules: max investors, jurisdiction restrictions, lock periods, holding limits. Output: production-ready token with upgradeable compliance rules.
Identity Registry (ONCHAINID)
+Deploy and configure the ONCHAINID identity layer: claim topics schema, trusted issuers registry, and claim verification pipeline. Output: on-chain identity infrastructure ready for KYC claim issuance.
KYC/AML provider integration
+Bridge your KYC provider (Synaps, Sumsub, Onfido, or others) to the ONCHAINID claim issuance pipeline. Output: automated flow from KYC approval to on-chain identity claim - without manual issuer steps.
Transfer restriction engine
+Custom compliance rules beyond the standard modules: time-based vesting, regulatory event triggers, multi-jurisdiction logic. Output: compliance module implementation matching your specific transfer restriction requirements.
Issuer operations backend
+Admin interface for investor management: force transfers, freeze/unfreeze accounts, claim revocation, batch operations. Output: operations backend integrated with your team workflow and audit log.
Reporting & indexing
+On-chain event indexing for compliance reporting: holder lists, transfer history, compliance check outcomes. Output: reporting API and data exports for legal, ops, and regulatory use.
ERC-3643 architecture
Token contract
+ERC-3643 token with compliance hooks on every transfer.
Identity Registry
+ONCHAINID claim storage and verification layer.
Compliance module
+Configurable transfer rules: limits, jurisdictions, lock periods.
Claim issuer
+Trusted issuer contracts for KYC/AML claim signing.
Operations backend
+Admin tooling, reporting, audit log, and issuer workflows.
ERC-3643 vs ERC-1400 vs ERC-20
Standard selection determines your compliance architecture - choose based on requirements, not familiarity.
ERC-20 - simple fungible tokens
+No built-in compliance, transfer restrictions, or identity layer. Suitable for utility tokens with no regulatory requirements. Requires off-chain compliance enforcement (easily bypassed).
ERC-1400 - permissioned security tokens
+Partition-based permissioning for tranches and classes. No unified identity standard - each issuer builds their own claim system. More flexible but less standardized than ERC-3643.
ERC-3643 - compliance-first tokens
+Unified ONCHAINID identity layer + modular compliance rules enforced on-chain. The standard for MiCA platforms, security tokens, and any issuance requiring auditable on-chain compliance checks.
When to choose ERC-3643
+MiCA-regulated tokens (ART, EMT), security token platforms, real-world asset issuance with investor classification requirements, or any platform where compliance must be on-chain and auditable.
How we work
Related Case Studies
ERC-3643 Development – Frequently Asked Questions
- What is ERC-3643 (T-REX)?
- ERC-3643, also known as T-REX (Token for Regulated EXchanges), is an Ethereum token standard designed for compliance-first asset issuance. It combines the ERC-20 transfer interface with an on-chain Identity Registry (ONCHAINID) and modular compliance rules. Every transfer checks the receiver's verified identity claims before executing - making compliance auditable and enforceable at the protocol level.
- What is ONCHAINID?
- ONCHAINID is the decentralized identity standard used by ERC-3643. Each investor has an on-chain identity contract that stores verified claims (KYC status, jurisdiction, accreditation level) signed by trusted issuers. The ERC-3643 token checks these claims on every transfer - without requiring off-chain API calls that could be bypassed.
- How does ERC-3643 integrate with KYC providers?
- KYC providers (Synaps, Sumsub, Onfido, etc.) verify investor identity off-chain. Once approved, a trusted claim issuer contract signs a KYC claim and stores it in the investor's ONCHAINID identity contract. The ERC-3643 token then reads this claim during transfers. The integration is typically via a backend service that bridges KYC webhook events to on-chain claim issuance.
- Is ERC-3643 required for MiCA compliance?
- MiCA does not mandate ERC-3643 specifically - it mandates investor classification and transfer restrictions at the platform level. ERC-3643 is the most widely adopted technical standard for meeting these requirements on EVM chains. ERC-1400 is an alternative; standard ERC-20 is not sufficient for regulated issuance without significant off-chain enforcement infrastructure.
- Can ERC-3643 compliance rules be changed after deployment?
- Yes. ERC-3643 compliance modules are upgradeable - rules like maximum investor count, jurisdiction restrictions, and lock periods can be updated without redeploying the token contract. Identity claims can also be revoked or updated independently, allowing platforms to respond to changing regulatory requirements.
