ERC-3643 Permissioned Tokens: ONCHAINID Registries for AI Agents
How the ERC-3643 permissioned token standard leverages ONCHAINID identity registries and compliance modules to enable regulated institutional asset transfers.
Executive Summary
ERC-3643 standardizes institutional RWA transfers by separating asset balances from identity validation, enforcing on-chain KYC/KYB claims before executing trades.
In traditional decentralized finance (DeFi), standard ERC-20 tokens execute ledger mutations without evaluating the identity, geographical jurisdiction, or regulatory compliance of either the sender or receiver.
While permissionless balance transfers are ideal for public meme coins and open governance tokens, they are legally unusable for **Institutional Real World Assets (RWAs)**—including tokenized US Treasury bills, private credit facilities, real estate equity, and venture capital funds.
Under global securities regulations (including SEC Regulation D, Regulation S, and European MiCA frameworks), asset issuers are legally prohibited from transferring securities to unverified or sanctioned wallets.
┌────────────────────────────────────────────────────────────────────────┐
│ ERC-20 VS ERC-3643 COMPLIANCE COMPARISON │
│ │
│ Standard ERC-20 (Permissionless DeFi): │
│ Wallet A ──► transfer(Wallet B, 1000) ──► Executed Immediately ❌ │
│ (No KYC check • Zero regulatory compliance • High legal risk) │
│ │
│ ERC-3643 T-REX Standard (Institutional RWA): │
│ Wallet A ──► transfer(Wallet B, 1000) │
│ │ │
│ ▼ │
│ 1. IdentityRegistry.isVerified(Wallet B)? ──► True │
│ │ │
│ ▼ │
│ 2. ModularCompliance.canTransfer(A, B, 1000)? ──► True │
│ │ │
│ ▼ │
│ Transfer Executed Atomically & Verified by Regulators ✅ │
└────────────────────────────────────────────────────────────────────────┘The **ERC-3643 standard (formerly T-REX: Token for Regulated EXchanges)** solves this challenge by decoupling token balances from identity validation.
Instead of embedding rigid KYC lists inside the token contract itself, ERC-3643 delegates identity verification to decentralized **ONCHAINID registries** and customizable **Modular Compliance Engines**.
This cluster guide breaks down the core smart contract interfaces, cryptographic claim topic structures, and automated compliance validation hooks that make ERC-3643 the gold standard for institutional on-chain finance.
1. The 4-Module Architecture of ERC-3643
The ERC-3643 ecosystem consists of four interconnected smart contract modules:
┌────────────────────────────────────────────────────────────────────────┐
│ ERC-3643 MODULAR CONTRACT TOPOLOGY │
│ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ Institutional Token (ERC-3643) │ │
│ │ - Holds balances and standard ERC-20 API │ │
│ └─────────────────┬────────────────────────────┬─────────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────────────────────────────┐ ┌───────────────────────────┐ │
│ │ Identity Registry │ │ Modular Compliance │ │
│ │ - ONCHAINID Claims │ │ - Investor Caps (10%) │ │
│ │ - Country Code Whitelists │ │ - Jurisdictional Regs │ │
│ └─────────────────┬────────────────┘ └───────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────┐ │
│ │ Claim Topics Registry │ │
│ │ - Topic 1: KYC Passed │ │
│ │ - Topic 2: Accredited US │ │
│ └──────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────────┘- **The Token Contract:** Exposes standard ERC-20 transfer and balance methods while intercepting every transfer with automated compliance checks.
- **The Identity Registry:** Maps Ethereum wallet addresses to sovereign **ONCHAINID identity contracts**, ensuring identity verification persists across multiple wallets.
- **The Claim Topics Registry:** Defines required cryptographic attestations (e.g. `Topic 1 = KYC Verification`, `Topic 2 = US Accredited Investor Status`, `Topic 3 = Qualified Purchaser`).
- **The Modular Compliance Contract:** Implements dynamic business logic rules (e.g. maximum token holders per country, minimum holding periods, and individual wallet balance concentration limits).
2. Production Solidity Implementation: ERC-3643 Transfer Hook
The core mechanism of ERC-3643 is the transfer interceptor:
// contracts/erc3643/IERC3643Token.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
interface IIdentityRegistry {
function isVerified(address _userAddress) external view returns (bool);
function investorCountry(address _userAddress) external view returns (uint16);
}
interface IModularCompliance {
function canTransfer(address _from, address _to, uint256 _value) external view returns (bool);
function transferred(address _from, address _to, uint256 _value) external;
}
contract ERC3643Token {
string public name;
string public symbol;
uint8 public decimals = 6; // Standard 6 decimals for institutional USDC parity
uint256 public totalSupply;
IIdentityRegistry public identityRegistry;
IModularCompliance public compliance;
mapping(address => uint256) public balanceOf;
event Transfer(address indexed from, address indexed to, uint256 value);
constructor(
string memory _name,
string memory _symbol,
address _identityRegistry,
address _compliance
) {
name = _name;
symbol = _symbol;
identityRegistry = IIdentityRegistry(_identityRegistry);
compliance = IModularCompliance(_compliance);
}
function transfer(address _to, uint256 _amount) external returns (bool) {
return _transfer(msg.sender, _to, _amount);
}
function _transfer(address _from, address _to, uint256 _amount) internal returns (bool) {
require(_to != address(0), "Cannot transfer to zero address");
require(balanceOf[_from] >= _amount, "Insufficient token balance");
// 1. Mandatory Identity Registry Verification
require(identityRegistry.isVerified(_to), "Recipient wallet lacks valid ONCHAINID KYC");
// 2. Mandatory Modular Compliance Rule Check
require(compliance.canTransfer(_from, _to, _amount), "Transfer violates regulatory compliance rules");
// 3. Execute Balance Mutation
balanceOf[_from] -= _amount;
balanceOf[_to] += _amount;
// 4. Notify Compliance Module of State Mutation
compliance.transferred(_from, _to, _amount);
emit Transfer(_from, _to, _amount);
return true;
}
}3. Cryptographic Claim Validation via ONCHAINID
When an investor completes KYC/KYB with an authorized identity provider (e.g. Synaps, Sumsub, Fractal ID), the trusted issuer writes a cryptographically signed claim directly to the investor's ONCHAINID identity contract:
// scripts/issue-identity-claim.ts
import { ethers } from 'ethers';
// Claim Topic Constants
export const CLAIM_TOPIC_KYC = 1;
export const CLAIM_TOPIC_ACCREDITED = 2;
export async function constructInvestorClaim(
investorIdentityAddress: string,
topic: number,
issuerPrivateKey: string
) {
const issuerWallet = new ethers.Wallet(issuerPrivateKey);
// Hash identity claims conforming to ERC-735
const claimData = ethers.hexlify(ethers.toUtf8Bytes('KYC_LEVEL_2_APPROVED_US'));
const claimHash = ethers.keccak256(
ethers.solidityPacked(
['address', 'uint256', 'bytes'],
[investorIdentityAddress, topic, claimData]
)
);
// Cryptographic signature from trusted identity issuer
const signature = await issuerWallet.signMessage(ethers.getBytes(claimHash));
return {
topic,
scheme: 1, // ECDSA Signature Scheme
issuer: issuerWallet.address,
signature,
data: claimData,
uri: 'https://identity.hamidayub.com/attestations/kyc',
};
}4. Comparing Token Standards for Institutional Capital
5. Automated Transfer Restriction Testing in Foundry
To guarantee that non-compliant wallets can never receive permissioned tokens, we run automated invariant assertions in Foundry:
// test/ERC3643Compliance.t.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
import "forge-std/Test.sol";
import "../contracts/ERC3643Token.sol";
contract ERC3643ComplianceTest is Test {
ERC3643Token public token;
address public unverifiedUser = address(0x999);
address public verifiedUser = address(0x111);
function testFail_TransferToUnverifiedWalletReverts() public {
// Attempt transfer to wallet without valid ONCHAINID claims
vm.prank(verifiedUser);
token.transfer(unverifiedUser, 1000 * 1e6); // Must fail and revert!
}
}6. Architectural Checklist for Deploying ERC-3643
To ensure regulatory and technical compliance:
- **Deploy Isolated Identity and Compliance Modules:** Never hardcode compliance logic inside the token contract; keep modules independently upgradable.
- **Register Trusted Claim Issuers:** Only grant claim verification authority to accredited institutional identity providers.
- **Implement Emergency Forced Transfers:** Retain issuer legal compliance capabilities to freeze or seize assets under valid court orders without compromising unassociated balances.
- **Integrate Real-Time Gas Subsidies (Account Abstraction):** Use ERC-4337 Paymasters on Layer-2 networks (Base, Arbitrum) so institutional investors never need to hold native gas tokens.
- **Automate Continuous Compliance Audits:** Run automated testing pipelines during CI/CD to verify that transfer restrictions correctly reject non-accredited or sanctioned wallets.
- **Implement On-Chain Holding Lockups:** Enforce 12-month Rule 144 resale restrictions programmatically through the compliance rule engine.
- **Deploy Real-Time Sanction Watchlist Sync:** Subscribe to Chainlink OFAC oracle feeds to freeze compromised addresses dynamically.
To explore our end-to-end institutional tokenization architecture, read our [Master Guide on Institutional RWA Tokenization](/guides/institutional-rwa-tokenization-architecture) or book an [Institutional Architecture Consultation](/services/architecture).
Also in this series
Automated Dividend Distribution: Pro-Rata Yield Engines on Layer-2
How to architect automated, gas-optimized dividend and yield distribution smart contracts for tokenized debt and RWA funds on Base and Arbitrum.
Privacy-Preserving KYC for Autonomous Agents via zk-SNARKs
Architecting zero-knowledge KYC verification for institutional tokenized assets using Circom circuits, Groth16 proofs, and on-chain EVM verifiers.