# ERC-3643: T-REX (Regulated Exchanges) Source: https://www.eipsfordesigners.com/standards/ERC-3643 Agent brief: https://www.eipsfordesigners.com/standards/ERC-3643/agent.md Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-3643 Last reviewed: 2026-05-25 Last updated: 2026-05-25 | Field | Value | | --- | --- | | Status | Final | | Chain | both | | Category | Identity & Privacy | | Journey stages | Asset Management | | Detailed guide | Yes | | Official specification | https://eips.ethereum.org/EIPS/erc-3643 | | Discussion search | https://ethereum-magicians.org/search?q=ERC-3643 | ## UX Impact Security tokens enforce compliance at transfer — only verified investors can hold, automatic checks against regulations. Design implications: show verification status prominently, guide through KYC/identity verification, display transfer eligibility before attempting. Design decisions: how to handle failed compliance checks — educational messaging, clear next steps for verification, balance regulatory requirements with user frustration. ## Summary Security tokens enforce compliance at transfer — only verified investors can hold, automatic checks against regulations. ## For Designers - You can show Verified investor badge prominently on portfolio and send screens. - Your send flow can pre-check recipient eligibility before the user signs. - You can guide rejected users through KYC next steps instead of raw revert reasons. ## Applicability ### When to Use - Tokenized securities or regulated assets. - Transfers must fail for non-verified wallets. - Issuer operates T-REX compliance stack. ### When to Avoid - Fully permissionless tokens with no compliance requirement. - Target chain lacks identity registry infrastructure. - Product cannot host or link KYC flow. ## Problems It Solves ### Regulated transfers fail mysteriously Impact: critical Old way: Revert after user signs full transaction New way: Pre-transfer eligibility check with clear reason ### Investors unsure if they qualify Impact: high Old way: Discover blocks at purchase New way: Verification status visible in portfolio at all times ### Issuer support overwhelmed by KYC questions Impact: medium Old way: Opaque compliance errors New way: Guided renewal and rejection flows with next steps ## Anti-Patterns ### Allowing sign then compliance revert Severity: critical Wasted gas and legal frustration Instead: Pre-check eligibility before wallet prompt ### Generic Transfer failed toast Severity: high Users cannot fix KYC or pick new recipient Instead: Specific compliance reason with renewal or support CTA ### Hiding verification requirement until checkout Severity: high Drop-off at payment after emotional investment Instead: Verify gate at portfolio entry and asset page ## Design Decisions ### When to run eligibility check? Recommendation: On address paste and before review step. Rationale: Late failures waste signatures and trust. ### How to message failed compliance? Recommendation: This wallet is not verified for this asset — not You are not allowed. Rationale: Neutral compliance language reduces offense. ### Show verification in public address display? Recommendation: Optional Verified chip on known counterparties only. Rationale: Do not leak KYC status broadly without consent. ## States to Design ### Unverified — cannot hold Trigger: User lacks KYC. User need: Complete verification to invest. Design response: Full-screen Verify to continue with step tracker. ### Verification pending Trigger: KYC submitted, awaiting review. User need: Know timeline and that funds are safe. Design response: Pending badge with estimated review time. ### Verified — can transfer Trigger: User and counterparty eligible. User need: Normal send experience with confidence. Design response: Verified badges on both parties; enabled Send. ### Recipient not verified Trigger: Pre-check fails on recipient. User need: Understand block before signing. Design response: Recipient cannot receive this asset yet with explanation. ### Verification expired Trigger: KYC lapsed. User need: Renew without losing holdings view. Design response: Expired badge; transfers disabled until renewal. ## Vocabulary - Use "Verified investor" instead of "Whitelisted ONCHAINID": Regulatory-friendly status language. - Use "Cannot receive this asset" instead of "Compliance module revert": Outcome without Solidity terms. - Use "Complete verification" instead of "Submit KYC claim": Action-oriented onboarding copy. ## What to Prototype First ### KYC verification onboarding Users cannot invest without completing identity verification. Covers: Unverified, Pending, Verified, Rejected - Step list - Document upload - Status tracker - Retry path ### Pre-transfer eligibility check Catch compliance failure before wallet signature. Covers: Both verified, Recipient not verified, Sender restricted - Recipient address field - Eligibility result - Block send with reason ### Verified portfolio view Holdings should reinforce trusted status. Covers: Verified holdings, Restricted token - Verification badge - Transfer button gated - Contact issuer link ### Compliance failure recovery Rejected transfers need human next steps. Covers: KYC expired, Jurisdiction block - Plain reason - Renew verification CTA - Support contact ## Mental Model ### Security token Regulated asset — not every wallet may hold it. ### Identity registry On-chain record of which addresses passed KYC. ### Compliance check Every transfer validates both parties against rules before execution. ### Verification lifecycle KYC can expire or revoke — status is not permanent by default. ### Transfer eligibility Pre-check answers will this send succeed before user commits. ## Seen in the Wild - Tokeny: T-REX implementation reference for compliance UX. (https://tokeny.com/) - Securitize: Tokenized securities onboarding and KYC patterns. (https://securitize.io/) - tZERO: Regulated trading sets verification expectations. (https://www.tzero.com/) - Polymesh: Identity-first chain informs verification badge UX. (https://polymesh.network/) ## On Monad ### KYC refresh Ethereum: Re-verification txs may feel costly Monad: Low fees reduce friction for status updates Design implication: Encourage periodic re-check without gas anxiety. ### Transfer pre-check speed Ethereum: Eligibility queries may lag Monad: Fast reads enable instant paste validation Design implication: Validate recipient on every keystroke debounce. ## UX Patterns ### Verification Status Badge Persistent KYC state on portfolio and profile. Components: VerifiedBadge, PendingState, RenewCTA User flow: - User opens portfolio - Sees verification status - Renews if expired - Transfers enabled Mockup registry key: `concept/siwe-sign-in` (React UI on the live standard page). ### Transfer Eligibility Pre-Check Validate recipient before send confirmation. Components: AddressInput, EligibilityResult, SendGate User flow: - User pastes address - Check runs - Pass enables Send - Fail shows reason Mockup registry key: `concept/verify-safety` (React UI on the live standard page). ## Related Standards - ERC-20: Fungible token with compliance hooks ## Technical Notes ERC-3643 T-REX requires identity registry integration; never allow send UI without eligibility pre-check.