ERC-3643 Complete Guide: Building Compliant Security Token Contracts on Blockchain 2026

ERC-3643 is the Ethereum token standard that makes real world asset tokenization legally compliant. Every regulated security token — tokenized real estate, bonds, equity, sukuk, carbon credits — needs transfer restrictions enforced at the smart contract level. A regular ERC-20 can be sent to anyone. A security token can only be transferred to verified, whitelisted investors who have passed KYC/AML checks and meet the eligibility requirements of the jurisdiction. ERC-3643 builds that compliance layer directly into the token contract.

This guide covers the complete ERC-3643 architecture — the T-REX standard, the identity registry, compliance modules, and how to deploy a production-ready security token. Run the free Blockhertz AI Smart Contract Auditor on your ERC-3643 contracts before testnet deployment — access control failures are the most common finding in security token reviews.

---

What is ERC-3643?

ERC-3643 is an Ethereum token standard for regulated security tokens, also known as the T-REX standard (Token for Regulated EXchanges). It was developed by Tokeny Solutions and formalized as an Ethereum Improvement Proposal in 2023. The standard extends ERC-20 with a mandatory compliance layer that enforces transfer restrictions on-chain — meaning the token contract itself checks investor eligibility before every transfer and reverts if the recipient is not authorized to hold the token.

The core insight of ERC-3643 is that compliance cannot be a middleware layer bolted on top of a standard ERC-20. If the compliance check runs off-chain and the token is a regular ERC-20, a determined actor can bypass the middleware and transfer tokens directly via the contract. ERC-3643 eliminates this attack surface by making compliance enforcement a core function of the token itself — the transfer function cannot succeed unless the compliance module returns true.

Feature	ERC-20	ERC-3643
Transfer restrictions	None	On-chain compliance check
Investor whitelisting	No	Identity registry required
KYC/AML enforcement	Off-chain only	Smart contract level
Jurisdiction rules	Not enforced	Compliance module enforced
Forced transfer	Not possible	Agent can force transfer
Token freezing	Not possible	Per-address + global freeze
Regulatory use	Utility tokens only	Regulated securities ✅

---

What is the T-REX Standard?

T-REX (Token for Regulated EXchanges) is the reference implementation of ERC-3643 developed and maintained by Tokeny Solutions. It is the most widely deployed security token architecture in production, used by banks, asset managers, and tokenization platforms across Europe, the Middle East, and Asia. When developers refer to ERC-3643 in practice, they almost always mean the T-REX implementation.

T-REX consists of four core smart contract components that work together to create a compliant security token system. Each component is independently deployable and upgradeable — the token contract, identity registry, compliance module, and claim issuers form a modular system where any component can be replaced without affecting the others.

---

What Are the Four Core Components of ERC-3643?

1. Token Contract

The ERC-3643 token contract extends ERC-20 with compliance hooks. Before every transfer, the token contract calls the compliance module's canTransfer() function. If it returns false, the transfer reverts. The token also has additional functions for agent operations — forced transfers for legal recovery scenarios, freeze and unfreeze of specific addresses, and minting to verified investors only.

2. Identity Registry

The identity registry is a whitelist of verified investor addresses. Each address maps to an on-chain identity (an ERC-734/735 ONCHAINID contract) that stores verified claims — KYC status, country of residence, accreditation status, and any other compliance attributes. The compliance module checks the identity registry to verify a recipient is authorized to hold the token before approving a transfer.

3. Compliance Module

The compliance module enforces the specific transfer rules of the token offering — maximum investor count, country restrictions, transfer lockup periods, and any other regulatory requirements. Different offerings have different compliance rules. A US Reg D offering needs a maximum of 2,000 investors and a 12-month lockup. A UAE DFSA offering needs investor eligibility verification and transfer approval. The compliance module is where these rules are implemented.

4. Claim Issuers

Claim issuers are trusted entities that sign verified claims about investors — KYC providers, accreditation verifiers, compliance firms. A claim issuer signs a statement that a particular investor is KYC-verified, or is an accredited investor, or is a resident of a particular country. The identity registry only accepts claims from approved claim issuers, ensuring that compliance data cannot be self-certified by investors.

---

How Does ERC-3643 Token Transfer Work?

Every ERC-3643 token transfer follows a specific verification sequence before tokens move. Understanding this sequence is essential for developers implementing the standard — each step must complete successfully or the transfer reverts.

// ERC-3643 Transfer Flow — simplified
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface ICompliance {
    function canTransfer(
        address from,
        address to,
        uint256 amount
    ) external view returns (bool);
}

interface IIdentityRegistry {
    function isVerified(
        address investor
    ) external view returns (bool);

    function investorCountry(
        address investor
    ) external view returns (uint16);
}

contract ERC3643Token {

    ICompliance public compliance;
    IIdentityRegistry public identityRegistry;

    mapping(address => uint256) private _balances;
    mapping(address => bool) private _frozen;
    bool private _paused;

    // Core ERC-3643 transfer with compliance check
    function transfer(
        address to,
        uint256 amount
    ) external returns (bool) {

        // 1. Check sender not frozen
        require(
            !_frozen[msg.sender],
            "Sender frozen"
        );

        // 2. Check recipient not frozen
        require(
            !_frozen[to],
            "Recipient frozen"
        );

        // 3. Check contract not paused
        require(!_paused, "Paused");

        // 4. Check recipient is KYC verified
        require(
            identityRegistry.isVerified(to),
            "Recipient not verified"
        );

        // 5. Check compliance rules pass
        // (investor count, country restrictions,
        //  lockup periods, transfer limits)
        require(
            compliance.canTransfer(
                msg.sender, to, amount),
            "Compliance check failed"
        );

        // 6. Execute transfer
        require(
            _balances[msg.sender] >= amount,
            "Insufficient balance"
        );

        _balances[msg.sender] -= amount;
        _balances[to] += amount;

        return true;
    }
}

---

How Do You Build a Compliance Module for ERC-3643?

The compliance module is where the specific regulatory requirements of your token offering are implemented. A basic compliance module for a standard security token offering implements four common rules: maximum investor count, country restrictions, transfer lockup period, and minimum holding period.

// ERC-3643 Compliance Module
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/access/AccessControl.sol";

contract BasicCompliance is AccessControl {

    bytes32 public constant ADMIN_ROLE =
        keccak256("ADMIN_ROLE");

    // Maximum number of token holders
    uint256 public maxInvestors;
    uint256 public currentInvestors;

    // Country restrictions (ISO 3166-1 numeric)
    mapping(uint16 => bool)
        public restrictedCountries;

    // Transfer lockup period after purchase
    uint256 public lockupPeriod;
    mapping(address => uint256)
        public firstPurchaseDate;

    // Minimum holding period between transfers
    uint256 public minHoldingPeriod;
    mapping(address => uint256)
        public lastTransferDate;

    IIdentityRegistry public identityRegistry;

    constructor(
        uint256 _maxInvestors,
        uint256 _lockupPeriod,
        uint256 _minHoldingPeriod,
        address _identityRegistry
    ) {
        maxInvestors = _maxInvestors;
        lockupPeriod = _lockupPeriod;
        minHoldingPeriod = _minHoldingPeriod;
        identityRegistry =
            IIdentityRegistry(_identityRegistry);
        _grantRole(ADMIN_ROLE, msg.sender);
    }

    function canTransfer(
        address from,
        address to,
        uint256 // amount
    ) external view returns (bool) {

        // Rule 1: Recipient must be verified
        if (!identityRegistry.isVerified(to))
            return false;

        // Rule 2: Cannot exceed max investors
        // (only counts new investors)
        if (currentInvestors >= maxInvestors)
            return false;

        // Rule 3: Recipient country not restricted
        uint16 country =
            identityRegistry.investorCountry(to);
        if (restrictedCountries[country])
            return false;

        // Rule 4: Sender lockup period must pass
        if (firstPurchaseDate[from] > 0) {
            if (block.timestamp 
                firstPurchaseDate[from] +
                lockupPeriod)
                return false;
        }

        // Rule 5: Minimum holding period
        if (lastTransferDate[from] > 0) {
            if (block.timestamp 
                lastTransferDate[from] +
                minHoldingPeriod)
                return false;
        }

        return true;
    }

    // Add country restriction
    function restrictCountry(
        uint16 countryCode
    ) external onlyRole(ADMIN_ROLE) {
        restrictedCountries[countryCode] = true;
    }

    // Remove country restriction
    function allowCountry(
        uint16 countryCode
    ) external onlyRole(ADMIN_ROLE) {
        restrictedCountries[countryCode] = false;
    }

    // Update max investors
    function setMaxInvestors(
        uint256 _max
    ) external onlyRole(ADMIN_ROLE) {
        require(_max >= currentInvestors,
            "Below current count");
        maxInvestors = _max;
    }
}

---

How Does the Identity Registry Work in ERC-3643?

The identity registry maintains the list of verified investor addresses and their associated on-chain identities. Each investor address maps to an ONCHAINID — a smart contract that stores verified claims about that investor issued by trusted claim issuers. When the compliance module checks whether a recipient is verified, it queries the identity registry, which queries the investor's ONCHAINID for the required claims.

// Simplified Identity Registry
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/access/AccessControl.sol";

contract IdentityRegistry is AccessControl {

    bytes32 public constant AGENT_ROLE =
        keccak256("AGENT_ROLE");

    // Investor address → ONCHAINID address
    mapping(address => address)
        public investorIdentity;

    // Investor address → country code
    mapping(address => uint16)
        public investorCountry;

    // Trusted claim issuers
    mapping(address => bool)
        public trustedIssuers;

    event IdentityRegistered(
        address indexed investor,
        address indexed identity,
        uint16 country
    );

    // Register verified investor
    function registerIdentity(
        address investor,
        address identity,
        uint16 country
    ) external onlyRole(AGENT_ROLE) {
        require(investor != address(0),
            "Zero address");
        require(identity != address(0),
            "Zero identity");
        require(
            investorIdentity[investor]
            == address(0),
            "Already registered"
        );

        investorIdentity[investor] = identity;
        investorCountry[investor] = country;

        emit IdentityRegistered(
            investor, identity, country);
    }

    // Remove investor from registry
    function deleteIdentity(
        address investor
    ) external onlyRole(AGENT_ROLE) {
        require(
            investorIdentity[investor]
            != address(0),
            "Not registered"
        );
        delete investorIdentity[investor];
        delete investorCountry[investor];
    }

    // Check if investor is verified
    function isVerified(
        address investor
    ) external view returns (bool) {
        return investorIdentity[investor]
            != address(0);
    }
}

---

What Are the Most Common Security Vulnerabilities in ERC-3643 Contracts?

ERC-3643 contracts have a wider attack surface than standard ERC-20 tokens because of the additional components — identity registry, compliance module, and claim issuers — each of which introduces its own vulnerability class. The most common findings in ERC-3643 security reviews are access control failures on the identity registry agent functions, compliance module bypass via direct token contract calls, and centralization risks in the claim issuer structure.

Vulnerability	Component	Impact	Prevention
Agent role misconfiguration	Identity Registry	Anyone can whitelist	Strict AGENT_ROLE assignment
Compliance module bypass	Token Contract	Non-KYC transfer succeeds	Always check canTransfer()
Single claim issuer	Claim Issuers	Single point of failure	Multi-issuer with threshold
Country code manipulation	Identity Registry	Bypass country restrictions	Validate ISO codes on-chain
Frozen address bypass	Token Contract	Frozen tokens transferred	Check freeze in transfer()
Forced transfer abuse	Token Contract	Agent drains any wallet	Multi-sig agent role
Lockup period bypass	Compliance Module	Early token transfer	Strict timestamp validation

Run the free Blockhertz AI Smart Contract Auditor on your ERC-3643 contracts — it checks for access control failures, compliance module bypass, and reentrancy in forced transfer functions in under 60 seconds.

---

How Do You Deploy ERC-3643 Contracts in Production?

A production ERC-3643 deployment involves deploying four contracts in sequence and wiring them together. The deployment order matters — the identity registry must be deployed before the token contract, and the compliance module must be deployed before the identity registry is connected to the token.

// ERC-3643 Production Deployment Script
// Using Hardhat + ethers.js

const { ethers } = require("hardhat");

async function deployERC3643Suite() {
    const [deployer] = await ethers.getSigners();

    console.log("Deploying ERC-3643 suite...");
    console.log("Deployer:", deployer.address);

    // Step 1: Deploy Identity Registry Storage
    const IRStorage = await ethers.getContractFactory(
        "IdentityRegistryStorage"
    );
    const irStorage = await IRStorage.deploy();
    await irStorage.waitForDeployment();
    console.log("IR Storage:", await irStorage.getAddress());

    // Step 2: Deploy Identity Registry
    const IR = await ethers.getContractFactory(
        "IdentityRegistry"
    );
    const identityRegistry = await IR.deploy(
        await irStorage.getAddress(),
        [], // trusted issuers (add after)
        []  // claim topics required
    );
    await identityRegistry.waitForDeployment();
    console.log("Identity Registry:",
        await identityRegistry.getAddress());

    // Step 3: Deploy Compliance Module
    const Compliance = await ethers.getContractFactory(
        "BasicCompliance"
    );
    const compliance = await Compliance.deploy(
        2000,       // maxInvestors (Reg D)
        365 days,   // lockupPeriod
        0,          // minHoldingPeriod
        await identityRegistry.getAddress()
    );
    await compliance.waitForDeployment();
    console.log("Compliance:",
        await compliance.getAddress());

    // Step 4: Deploy Token
    const Token = await ethers.getContractFactory(
        "ERC3643Token"
    );
    const token = await Token.deploy(
        await identityRegistry.getAddress(),
        await compliance.getAddress(),
        "My Security Token",  // name
        "MST",                // symbol
        deployer.address,     // onchainId
    );
    await token.waitForDeployment();
    console.log("Token:",
        await token.getAddress());

    // Step 5: Wire contracts together
    await identityRegistry.bindToken(
        await token.getAddress()
    );

    console.log("✅ ERC-3643 suite deployed");

    return {
        token: await token.getAddress(),
        identityRegistry:
            await identityRegistry.getAddress(),
        compliance: await compliance.getAddress(),
        irStorage: await irStorage.getAddress()
    };
}

deployERC3643Suite()
    .then(addresses => {
        console.log("\nDeployment Summary:");
        console.log(JSON.stringify(addresses, null, 2));
    })
    .catch(console.error);

---

Which KYC Providers Integrate with ERC-3643?

ERC-3643 is KYC-provider agnostic — any identity verification provider can integrate by becoming a trusted claim issuer on the identity registry. In practice, the most commonly used providers for ERC-3643 deployments are those that support the ONCHAINID standard and can issue on-chain claims directly.

Provider	ONCHAINID Support	Best For
Synaps	Native ✅	DeFi + RWA platforms
Sumsub	Integration ✅	High volume onboarding
Fractal	Native ✅	European projects
Shufti Pro	Integration ✅	UAE + GCC projects
Onfido	Integration ✅	Enterprise deployments

---

How Does Blockhertz Build ERC-3643 Token Platforms?

At Blockhertz we build full-stack ERC-3643 security token platforms covering the complete technical stack — T-REX token contracts, identity registry deployment and configuration, compliance module development for your specific regulatory requirements, KYC provider integration, investor portal development, and a security audit on every contract before mainnet deployment.

Every ERC-3643 platform we build includes the complete four-contract T-REX suite, custom compliance modules for the target jurisdiction (DIFC, ADGM, Reg D, MiFID II), and integration with your chosen KYC provider for on-chain claim issuance. We work across Ethereum, Polygon, Avalanche, and BNB Chain and help clients select the right chain based on their investor base and transaction volume requirements.

Learn more about our RWA tokenization services or book a strategy call to discuss your ERC-3643 project.

Building an ERC-3643 security token? Run your contracts through the free Blockhertz AI Auditor before testnet deployment — access control failures appear in over 70% of first-pass ERC-3643 reviews.

---

Frequently Asked Questions About ERC-3643

What is the difference between ERC-3643 and ERC-1400?

Both ERC-3643 and ERC-1400 are security token standards but with different design philosophies. ERC-1400 (also known as ST-20) partitions tokens into tranches and focuses on document management and partition-based transfer restrictions. ERC-3643 (T-REX) focuses on identity-based compliance enforced through an on-chain identity registry. ERC-3643 has seen broader institutional adoption in Europe and the Middle East, particularly for real estate and bond tokenization, while ERC-1400 has been used more in North American security token offerings.

Is ERC-3643 compatible with DeFi protocols?

ERC-3643 tokens are not directly compatible with standard DeFi protocols like Uniswap or Aave because the transfer restrictions prevent tokens from being deposited into smart contracts that are not whitelisted in the identity registry. Some platforms have developed permissioned DeFi solutions specifically for ERC-3643 tokens — where the DeFi protocol smart contract is whitelisted and KYC checks are performed at the protocol level. Tokeny's own TREX Uniswap integration is an example of this approach.

How long does it take to deploy an ERC-3643 platform?

A production ERC-3643 token platform typically takes 8-14 weeks from specification to mainnet deployment. The technical deployment of the four T-REX contracts can be completed in a few days. The majority of the timeline is the compliance layer — configuring the compliance module for the specific regulatory requirements, integrating the KYC provider, and building the investor onboarding portal. At Blockhertz we deliver ERC-3643 platforms in 8-12 weeks including security audit.

What blockchains support ERC-3643?

ERC-3643 is an EVM standard and is deployable on any EVM-compatible blockchain. Production deployments exist on Ethereum mainnet, Polygon, Avalanche, BNB Chain, and several Layer 2 networks. The reference implementation from Tokeny is tested on Ethereum and Polygon. For high-frequency investor operations where gas costs matter — such as large-scale identity registry updates or frequent coupon distributions — Polygon is the most common choice.

---

Building an ERC-3643 security token platform? Talk to the Blockhertz team — we build compliant T-REX token infrastructure on Ethereum, Polygon, Avalanche, and BNB Chain.