How To Create Compliant Security Tokens With ERC-3643 (T-REX)

Creating compliant security tokens with ERC-3643, also known as T-REX (Token for Regulated EXchanges), means building tokens that enforce identity and compliance rules directly in the token’s smart contract architecture. A standard ERC-20 token allows transfers between any addresses without checks, but a compliant security token must verify who holds or receives tokens, whether that person has passed KYC/AML checks, and whether transfers meet regulatory or issuer-defined conditions before they are executed on-chain. ERC-3643 brings those controls on-chain through a suite of cooperating contracts. This article explains what components you need, how they work together in the full token lifecycle, and why this approach matters for regulated asset tokenization.

To create compliant security tokens with ERC-3643 (T-REX), you must deploy and connect multiple smart contracts that enforce identity verification and compliance for every token issuance and transfer.

At a high level, this involves:

1. Deploying an Identity Registry that maps wallet addresses to on-chain identities (ONCHAINIDs), each linked to verified claims like KYC/AML.
2. Deploying a Compliance Contract that encodes transfer rules such as investor eligibility, jurisdictional restrictions, or investor caps.
3. Deploying the ERC-3643 Token Contract itself, which enforces eligibility and compliance before allowing minting, transfer, or burning.
4. Registering each investor’s ONCHAINID and appropriate claims issued by trusted KYC providers before they can receive tokens.

Together, these components ensure that a token can only be held or transferred by verified and compliant participants, making the token suitable for regulated use cases.

What Is ERC-3643 (T-REX)?

ERC-3643 is an official Ethereum token standard designed for permissioned and compliant tokens - digital assets that represent real-world value and can only be held and moved by identities that meet predefined eligibility requirements. It brings identity verification and compliance logic directly into the token infrastructure, rather than relying on off-chain processes alone.

Whereas an ERC-20 token allows free transfer between any Ethereum address because it was created for open fungible assets, ERC-3643 was developed explicitly to support security tokenization - tokenized financial instruments such as equity, bonds, or fractional real estate - where legal constraints around investor eligibility and transfer restrictions exist.

Because of this, every transfer in an ERC-3643 system passes through on-chain compliance logic before execution.

How ERC-3643 Works in Depth

ERC-3643 is not a single contract. It is a modular architecture composed of several cooperating elements:

On-Chain Identity - ONCHAINID

Every participant (investor, issuer, custodian) who wants to interact with an ERC-3643 token has an ONCHAINID, an identity contract that holds cryptographically verifiable claims about that user. These claims can include KYC or AML status, investor accreditation, residency, or any attribute needed for compliance.

ONCHAINID is based on the identity standard ERC-734/735, allowing trusted third parties such as appropriate KYC providers to issue claims to a user’s identity. The Identity Registry maintains the mapping from wallet addresses to their ONCHAINIDs and checks whether the associated claims satisfy the criteria required to hold or trade the token.

This means that before a transfer, the token system can verify an investor’s identity on-chain without exposing personal data publicly.

Identity Registry

The Identity Registry is the contract responsible for managing and validating the identities of token holders. It maps wallet addresses to ONCHAINID contracts and checks associated claims to verify whether a user is eligible to hold or receive tokens.

When a transfer is initiated, the token contract first interacts with the Identity Registry’s isVerified function to ensure both sender and receiver meet the required criteria. If either fails the identity check, the transfer is blocked.

Compliance Contract

While identity verification ensures that only eligible identities hold tokens, compliance rules define the conditions under which transfers are permitted. These can include rules like limits on the number of token holders in a particular jurisdiction, minimum holding periods, or caps on individual ownership.

The Compliance Contract is consulted after identity verification. It encodes bespoke transfer logic and returns whether a proposed transfer complies with all rules defined by the issuer or governing framework. This modular approach means rules can be updated or extended over time without rewriting the core token contract.

Token Contract

The core ERC-3643 token contract extends the familiar ERC-20 interface but adds compliance validation. When a token holder initiates a transfer:

1. The token contract checks the Identity Registry to see if both parties’ ONCHAINIDs are verified.
2. It then calls the Compliance Contract to evaluate transfer rules.

Only if both identity and compliance conditions return positive results does the token move. This layered check replaces the basic ERC-20 transfer logic with compliance-aware logic.

The token contract also supports administrative actions such as forced transfers, pausing, or recovery mechanisms that are often needed for regulated securities in critical compliance setups.

Step-by-Step: Deploying a Compliant Security Token (Full T-REX Factory Guide)

Deploying a compliant ERC-3643 token involves many coordinated smart contracts — Identity Registry, Claim Topics Registry, Trusted Issuers Registry, Identity Registry Storage, Compliance module, and the Token contract itself. Rather than deploying each component manually, the T-REX Factory lets you deploy the entire suite in one transaction, ensuring consistent setup and reducing room for error.

1. Prepare Deployment Input Parameters

Before calling the factory, you must assemble the required configuration details that define the token and compliance logic:

TokenDetails struct

This struct contains critical token configuration fields:

• owner: the account that will own all deployed contracts.
• name, symbol, decimals: standard ERC-20 token metadata.
• irs: (optional) pre-deployed Identity Registry Storage to reuse across tokens.
• ONCHAINID: (optional) a pre-existing ONCHAINID for the token itself.
• irAgents: addresses allowed to manage identity registry actions.
• tokenAgents: addresses allowed to act on the token (e.g., mint, forced transfer).
• complianceModules: addresses of pre-built compliance modules to bind.
• complianceSettings: calldata instructions to configure those modules.

ClaimDetails struct

This includes:

• claimTopics: numeric identifiers for required claim types (e.g., KYC, AML).
• issuers: addresses of trusted claim issuer contracts.
• issuerClaims: arrays of the specific claim topic sets each issuer can issue.

These two inputs let the T-REX Factory know what to deploy and how to configure it.

2. Call deployTREXSuite on the T-REX Factory

Once parameters are assembled, you (as the factory owner) call:

deployTREXSuite(salt, tokenDetails, claimDetails)

• salt: an arbitrary string used to create deterministic contract addresses via CREATE2.
• tokenDetails: the token and agent setup.
• claimDetails: claim topic & trusted issuer configuration.

This executes a single atomic transaction with the following internal actions:

• Deploy Trusted Issuers Registry — tracks which issuers are trusted for claims.
• Deploy Claim Topics Registry — stores which claim types are required.
• Deploy Modular Compliance — the compliance logic engine.
• Deploy Identity Registry Storage if none provided, for storing identity data.
• Deploy Identity Registry — the on-chain validator for investor identities.
• Deploy Token contract linked to the identity and compliance layers.
• Optionally create a token ONCHAINID if none was provided.
• Add all claim topics and register all claim issuers.
• Bind all compliance modules and run their initial setup calls.
• Assign agent roles to the token and identity registry.
• Transfer contract ownership to the owner specified in TokenDetails.
• Emit events indicating successful deployment of the full suite.

On completion, you receive a TREXSuiteDeployed event containing the addresses for:

• Token
• Identity Registry
• Identity Registry Storage
• Trusted Issuers Registry
• Claim Topics Registry
• Compliance Engine

Each component is now linked and ready for use.

3. Post-Deployment Interaction Overview

Once deployed, you interact with the suite through contract functions, including:

Identity Registry

• Register investor wallets with their ONCHAINID using setIdentityForWallet.
• Update identity metadata like country or legal status as needed.
• Query isVerified(wallet, claimTopics[]) to confirm eligibility for holding or receiving tokens.

Trusted Issuers & Claim Topics Registries

• Add or remove claim issuers post-deployment if needed (provided you control the registry).
• Add or adjust claim topics, which define what identity claims are required.

Compliance Engine

• Bind additional compliance modules (automated rules that check global conditions like max holders or holding caps).
• Configure module logic using module-specific setup calls passed via complianceSettings.
• For example, enforce a lock-up period or geographic restrictions.

Token Contract

• Mint tokens to verified investors via agent-authorized mint functions.
• Execute transfers, where each call triggers the identity registry and compliance engine to validate the transfer before completing.
• Support admin functions like forced transfers, freezing, or pausing the token.

4. Onboarding Investors & Issuing Tokens

With the suite live and configured:

1. Create or provide ONCHAINIDs for each investor. These are identity contracts that hold valid claims issued by trusted issuers.
2. Use Identity Registry to bind each investor’s wallet to its ONCHAINID and ensure the right claims are associated.
3. Mint tokens only after identity verification. The token contract enforces that the investor’s ONCHAINID has the required claims before allowing issuance or transfer.
4. From this point forward, every transfer is automatically subject to identity and compliance checks — no off-chain process required.

5. Practical Tips & Best Practices

• Reuse Identity Storage: Provide an existing IRS address if deploying multiple tokens that share a common identity registry. This saves gas and centralizes investor identity data.
• Plan Agent Roles: Assign irAgents for identity registry operations and tokenAgents for token governance actions to separate responsibilities.
• Deterministic Deployment: Choosing a meaningful salt string allows you (or other applications) to discover deployed addresses using the same salt across chains. This improves consistency in multi-chain deployments.
• Module Configuration: Carefully order your complianceSettings — each module may require specific initialization for correct behavior.

Why ERC-3643 Matters for Compliance

ERC-3643’s compliance-centric design ensures that tokens cannot be transferred between parties unless all identity and regulatory conditions are met. This is crucial for real-world asset tokenization because:

• Traditional ERC-20 tokens are open and unrestricted.
• Security tokens often represent legal rights and are subject to KYC/AML and jurisdictional laws.
• Embedding compliance logic on-chain builds trust, reduces reliance on off-chain checks, and provides auditability.

This compliance-by-design model makes ERC-3643 a leading standard for regulated digital assets.

Summary

ERC-3643 (T-REX) is a robust Ethereum token standard for compliant security tokens. It enforces identity verification and compliance on-chain through a modular architecture comprised of ONCHAINIDs, an Identity Registry, a Compliance Contract, and the token itself. Every transfer is validated against eligibility and rule-based compliance before execution, making ERC-3643 suitable for regulated assets like securities, real estate, and private funds.

Deploying an ERC-3643 token requires careful orchestration of identity and compliance layers, but it brings programmable compliance and auditability that traditional ERC-20 tokens cannot deliver.

Implementing the full ERC-3643 stack is technically demanding. Teams often leverage tokenization engines that abstract away much of the manual contract orchestration. Such platforms handle identity registry management, connect trusted KYC providers, and manage compliance rules as a service - letting developers focus on product logic while still benefiting from ERC-3643’s compliance framework.

This approach reduces integration risk, accelerates development, and makes adopting compliant token standards more accessible.

FAQ

Do investors need an ONCHAINID for every token they hold?
Yes. Each investor interacting with an ERC-3643 security token must have an on-chain identity contract (ONCHAINID) that stores verifiable identity claims — such as KYC/AML status, jurisdiction eligibility, or accreditation — issued by trusted claim issuers. These identity contracts are linked to wallet addresses via the Identity Registry and are required before the investor can receive or transfer tokens. This on-chain identity model prevents transfers to unverified wallets and ensures compliance by design.

Does ERC-3643 eliminate the need for off-chain KYC/AML checks?
No. Off-chain KYC/AML processes still occur with regulated providers. However, the results of those checks are represented on-chain as cryptographically signed claims stored in an investor’s ONCHAINID. The token system reads these claims during identity and transfer verification, enabling smart contracts to enforce compliance without exposing personal data or relying on manual off-chain enforcement.

How does the Identity Registry verify an investor’s eligibility?
The Identity Registry maintains a mapping of wallet addresses to their ONCHAINID and associated claims. When a transfer or controlled action is requested, the registry’s isVerified function checks whether the linked ONCHAINID holds valid, non-revoked claims issued by trustworthy issuers and satisfying the required topics. If the investor’s claims meet all configured requirements, the action proceeds; otherwise, it is blocked.

Can ERC-3643 tokens trade on public exchanges?
Yes — but transfers still require on-chain compliance validation. Even if an ERC-3643 token is listed on a decentralized or centralized exchange, every transfer must pass identity verification and compliance rule checks before execution. This means that peer-to-peer trading is permissioned, not permissionless, with the contract enforcing eligibility and rule constraints automatically at the protocol level.

What additional compliance features does ERC-3643 support?
Beyond basic eligibility checks, ERC-3643 supports advanced compliance capabilities including:

• Forced transfers (e.g., for regulatory or court orders),
• Token freezing and pausing (global or per address),
• Batch operations for efficient issuance or distribution,
• Administrative agent roles with controlled operational permissions.
  These features make it suitable for regulated token lifecycles where issuer control and auditability are required.

Is ERC-3643 compatible with ERC-20 wallets and tooling?
Yes. ERC-3643 is designed to be backward-compatible with the ERC-20 interface, meaning standard wallets and ecosystem tooling that support ERC-20 can interact with ERC-3643 tokens. The difference lies in the underlying compliance and identity logic, which runs checks before transfers occur — while still maintaining familiar functions like transfer, transferFrom, and balanceOf.

‍