{"id":"ERC-3643","name":"T-REX (Regulated Exchanges)","status":"Final","chain":"both","category":{"id":"identity","name":"Identity & Privacy","description":"Who you are on-chain, and what you choose to reveal"},"journeyStages":[{"id":"authentication","name":"Authentication & Identity","description":"Proving who you are and logging in"},{"id":"management","name":"Asset Management","description":"Managing assets over time"}],"uxImpact":"ERC-3643 provides identity and compliance checks for ordinary token transfers; mint and forcedTransfer use distinct privileged paths and burn has its own rules. Read the deployed identity and compliance modules instead of assuming every operation uses the same gate.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-3643","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-3643","sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-3643","type":"official-spec"}],"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","summary":"ERC-3643 provides identity and compliance checks for ordinary token transfers; mint and forcedTransfer use distinct privileged paths and burn has its own rules. Read the deployed identity and compliance modules instead of assuming every operation uses the same gate.","designerTakeaways":["You can show the identity-registry result and compliance status before an ordinary transfer.","You can pre-check recipient eligibility and canTransfer before the user signs.","You can guide rejected users through issuer-defined KYC or compliance next steps."],"applicability":{"whenToUse":["Tokenized securities or regulated assets need identity and compliance checks for ordinary transfers.","The product can distinguish ordinary transfer/transferFrom from mint, forcedTransfer, and burn paths.","The issuer operates the target identity registry, trusted claims, and compliance stack."],"whenToAvoid":["Fully permissionless tokens with no compliance requirement.","Target chain lacks identity registry infrastructure.","Product cannot host or link KYC flow."]},"prototypeFirst":[{"screen":"KYC verification onboarding","why":"Users cannot invest without completing identity verification.","covers":["Unverified","Pending","Verified","Rejected"],"include":["Step list","Document upload","Status tracker","Retry path"]},{"screen":"Pre-transfer eligibility check","why":"Catch compliance failure before wallet signature.","covers":["Both verified","Recipient not verified","Sender restricted"],"include":["Recipient address field","Eligibility result","Block send with reason"]},{"screen":"Verified portfolio view","why":"Show holdings separately from current identity eligibility and transfer restrictions; a verification badge is not a guarantee of asset safety.","covers":["Verified holdings","Restricted token"],"include":["Verification badge","Transfer button gated","Contact issuer link"]},{"screen":"Compliance failure recovery","why":"Rejected transfers need human next steps.","covers":["KYC expired","Jurisdiction block"],"include":["Plain reason","Renew verification CTA","Support contact"]}],"mentalModel":[{"label":"Security token","description":"Regulated asset — not every wallet may hold it."},{"label":"Identity registry","description":"Links a wallet address to an identity contract and country code. isVerified checks that identity's required claims against the token's trusted claim issuers; registration alone is not sufficient."},{"label":"Compliance check","description":"Ordinary transfer and transferFrom check recipient identity, frozen/balance/pause state, and canTransfer compliance. Mint and forcedTransfer still require a verified recipient but bypass general compliance rules, while burn bypasses eligibility checks; show these privileged paths separately."},{"label":"Verification lifecycle","description":"KYC can expire or revoke — status is not permanent by default."},{"label":"Transfer eligibility","description":"Read recipient identity, compliance, pause, freeze, and available balance before signing. A passing pre-check describes the current state, not a guarantee that the later transaction will succeed."}],"statesToDesign":[{"state":"Recipient identity not verified","trigger":"The target token's identity registry returns false for the receiving wallet.","userNeed":"Understand the missing issuer-required claims before receiving this token.","designResponse":"Explain the issuer's verification steps. Keep any existing balance visible; loss of verification does not itself erase holdings."},{"state":"Verification pending","trigger":"KYC submitted, awaiting review.","userNeed":"Know the issuer's review timeline and what happens to any existing holdings.","designResponse":"Show pending status, an issuer-provided estimate if available, and the actual custody and transfer restrictions. Do not imply that verification guarantees fund safety."},{"state":"Transfer checks pass","trigger":"Recipient identity, compliance, pause, freeze, balance, and applicable allowance checks pass at the current chain state.","userNeed":"Review an eligible transfer without mistaking identity verification for a complete transfer check.","designResponse":"Enable review after the relevant checks, then show the observed transaction outcome. State can change before execution."},{"state":"Recipient not verified","trigger":"Pre-check fails on recipient.","userNeed":"Understand block before signing.","designResponse":"Recipient cannot receive this asset yet with explanation."},{"state":"Verification expired","trigger":"KYC lapsed.","userNeed":"Renew without losing holdings view.","designResponse":"Show the expired claim and issuer renewal path. Read the actual identity and compliance rules for the selected operation; do not assume expired sender verification alone blocks every outgoing transfer."}],"designDecisions":[{"question":"When to run eligibility check?","recommendation":"On address paste and before review step.","rationale":"Late failures waste signatures and trust."},{"question":"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."},{"question":"Show verification in public address display?","recommendation":"Optional Verified chip on known counterparties only.","rationale":"Do not leak KYC status broadly without consent."}],"problemsSolved":[{"problem":"Regulated transfers fail mysteriously","oldWay":"Revert after user signs full transaction","newWay":"Pre-transfer eligibility check with clear reason","impact":"critical"},{"problem":"Investors unsure if they qualify","oldWay":"Discover blocks at purchase","newWay":"Verification status visible in portfolio at all times","impact":"high"},{"problem":"Issuer support overwhelmed by KYC questions","oldWay":"Opaque compliance errors","newWay":"Guided renewal and rejection flows with next steps","impact":"medium"}],"uxPatterns":[{"name":"Verification Status Badge","description":"Persistent KYC state on portfolio and profile.","components":["VerifiedBadge","PendingState","RenewCTA"],"userFlow":["User opens portfolio","Sees verification status","Renews if expired","Re-check all conditions for the selected transfer"]},{"name":"Transfer Eligibility Pre-Check","description":"Validate recipient before send confirmation.","components":["AddressInput","EligibilityResult","SendGate"],"userFlow":["User pastes address","Check runs","Pass enables Send","Fail shows reason"]}],"antiPatterns":[{"pattern":"Allowing sign then compliance revert","why":"Wasted gas and legal frustration","instead":"Pre-check eligibility before wallet prompt","severity":"critical"},{"pattern":"Generic Transfer failed toast","why":"Users cannot fix KYC or pick new recipient","instead":"Specific compliance reason with renewal or support CTA","severity":"high"},{"pattern":"Hiding verification requirement until checkout","why":"Drop-off at payment after emotional investment","instead":"Verify gate at portfolio entry and asset page","severity":"high"}],"vocabulary":[{"use":"Verified investor","avoid":"Whitelisted ONCHAINID","why":"Regulatory-friendly status language."},{"use":"Cannot receive this asset","avoid":"Compliance module revert","why":"Outcome without Solidity terms."},{"use":"Complete verification","avoid":"Submit KYC claim","why":"Action-oriented onboarding copy."}],"specConstraints":[{"id":"permissioned-transfer","constraint":"An ERC-3643 token is ERC-20-compatible but transfer is subject to permissioned identity and compliance rules.","appliesTo":"application","normativity":"normative","specQuote":"- **MUST** be [ERC-20](./eip-20.md) compatible.\n- **MUST** be used in combination with an onchain Identity system\n- **MUST** be able to apply any rule of compliance that is required by the regulator or by the token issuer (about the factors of eligibility of an identity or about the rules of the token itself)","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-3643#specification","designImplication":"Token screens should explain permissioned transfer and avoid implying that a standard ERC-20 balance guarantees transferability."},{"id":"identity-verification","constraint":"The token must be used with an onchain Identity system.","appliesTo":"application","normativity":"normative","specQuote":"- **MUST** be used in combination with an onchain Identity system","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-3643#specification","designImplication":"Provide an identity-verification status and recovery path before offering regulated transfer actions."},{"id":"compliance-rules","constraint":"The token must apply regulator- or issuer-defined compliance rules.","appliesTo":"application","normativity":"normative","specQuote":"- **MUST** be able to apply any rule of compliance that is required by the regulator or by the token issuer (about the factors of eligibility of an identity or about the rules of the token itself)","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-3643#specification","designImplication":"Show a policy-driven transfer eligibility state and explain that approval can depend on rules beyond balance and allowance."},{"id":"transfer-precheck","constraint":"The standard must expose a way to pre-check whether a transfer will pass or fail.","appliesTo":"application","normativity":"normative","specQuote":"- **MUST** have a standard interface to pre-check if a transfer is going to pass or fail before sending it to the blockchain","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-3643#specification","designImplication":"Use the pre-check before signing and show the specific eligibility failure when the transfer cannot proceed."},{"id":"recovery-system","constraint":"The token must provide recovery when an investor loses access to a private key.","appliesTo":"account-implementation","normativity":"normative","specQuote":"- **MUST** have a recovery system in case an investor loses access to his private key","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-3643#specification","designImplication":"Design recovery as a visible regulated account state with authority, waiting, and completion states rather than an ordinary password reset."},{"id":"freeze-pause-state","constraint":"The token must support partial/total wallet freezing and token pausing.","appliesTo":"application","normativity":"normative","specQuote":"- **MUST** be able to freeze tokens on the wallet of investors if needed, partially or totally","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-3643#specification","designImplication":"Explain whether a blocked action is caused by the user wallet, receiver wallet, or token-wide pause, and show how to recover if a path exists."},{"id":"agent-force-transfer","constraint":"Agents can force transfers, while issuer roles control agent administration.","appliesTo":"application","normativity":"normative","specQuote":"- **MUST** be able to force transfers from an Agent wallet","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-3643#specification","designImplication":"Use explicit authority labels and warnings for forced-transfer/admin actions; do not present them as ordinary user-initiated transfers."},{"id":"batch-issuance","constraint":"Batch transactions are supported to save gas and execute in the same block.","appliesTo":"application","normativity":"normative","specQuote":"- **MUST** be able to issue transactions in batch (to save gas and to have all the transactions performed in the same block)","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-3643#specification","designImplication":"Batch admin flows should show the shared execution boundary and per-recipient results without hiding a partial or rejected item."},{"id":"transfer-preconditions","constraint":"A transfer requires free sender balance, a verified receiver, unfrozen wallets, an unpaused token, and compliance approval.","appliesTo":"application","normativity":"normative","specQuote":"- The sender **MUST** hold enough free balance (total balance - frozen tokens, if any)","specSection":"Specification > Main functions > Transfer","specUrl":"https://ercs.ethereum.org/ERCS/erc-3643#transfer","designImplication":"Present these checks as separate eligibility rows so users can see whether the blocker is balance, identity, freeze, pause, or compliance."},{"id":"claim-eligibility","constraint":"isVerified checks claims from the identity registry, trusted issuers, and required claim topics.","appliesTo":"application","normativity":"normative","specQuote":"The `isVerified` function is called from within the transfer functions `transfer`, `transferFrom`, `mint` and \n`forcedTransfer` to instruct the `Identity Registry` to check if the receiver is a valid investor, i.e. if his \nwallet address is in the `Identity Registry` of the token, and if the `Identity`contract linked to his wallet \ncontains the claims (see [Claim Holder](../assets/eip-3643/ONCHAINID/IERC735.sol)) required in the `Claim Topics Registry` and \nif these claims are signed by an authorized Claim Issuer as required in the `Trusted Issuers Registry`.\nIf all the requirements are fulfilled, the `isVerified` function returns `TRUE`, otherwise it returns `FALSE`. An \nimplementation of this function can be found on the T-REX repository of Tokeny.","specSection":"Specification > Main functions > isVerified","specUrl":"https://ercs.ethereum.org/ERCS/erc-3643#isverified","designImplication":"Show identity verification as claim-backed and issuer-scoped; avoid a generic “verified” badge without the relevant claim context."},{"id":"erc20-compatibility","constraint":"T-REX tokens should remain compatible with ERC-20 and ERC-173 and interact with a Claim Holder contract.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"## Backwards Compatibility\n\nT-REX tokens should be backwards compatible with ERC-20 and ERC-173\nand should be able to interact with a [Claim Holder contract](../assets/eip-3643/ONCHAINID/IERC735.sol) to validate \nthe claims linked to an [Identity contract](../assets/eip-3643/ONCHAINID/IIdentity.sol).","specSection":"Backwards Compatibility","specUrl":"https://ercs.ethereum.org/ERCS/erc-3643#backwards-compatibility","designImplication":"Keep familiar ERC-20 balance/transfer conventions but add the regulated identity and role context where those conventions alone are insufficient."}],"technicalNotes":"ERC-3643 builds on ERC-20 with identityRegistry and compliance checks. Ordinary transfer/transferFrom require a verified recipient and canTransfer compliance plus pause/freeze/balance rules. mint and forcedTransfer require a verified recipient but bypass general canTransfer compliance; burn bypasses eligibility checks. Show the operation type and the relevant identity, agent, and compliance authority.","relatedStandards":[{"id":"ERC-20","relationship":"Fungible token with compliance hooks"}]},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-3643","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-3643","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-3643","markdown":"https://www.eipsfordesigners.com/standards/ERC-3643/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-3643/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-3643","official":"https://ercs.ethereum.org/ERCS/erc-3643","discussion":"https://ethereum-magicians.org/search?q=ERC-3643"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}