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

Traditional blockchain tokens like ERC-20 were designed for open financial systems—anyone can send tokens to anyone, without restrictions. But security tokens represent real-world assets: equities, bonds, real estate, private funds. These assets come with legal obligations. Investors must pass KYC/AML checks. Transfers may be restricted by jurisdiction. Holding caps may apply. Token holders must be verified.

This is where ERC-3643, also known as T-REX (Token for Regulated EXchanges), changes everything. Unlike ERC-20, ERC-3643 enforces compliance directly within the smart contract layer. Before any token transfer happens, the blockchain verifies the identity of both parties and checks compliance rules. If either party fails verification, the transfer simply doesn't execute.

For issuers and platforms operating in regulated markets—especially Europe's MiFID II and upcoming MiCA frameworks—ERC-3643 has become the de facto standard for compliant security token issuance. This guide explains how it works, why it matters, and how to implement it.

The Problem ERC-3643 Solves

Let's step back. Why can't you just issue an ERC-20 token and handle compliance off-chain?

The answer reveals a fundamental weakness in traditional blockchain: transparency and immutability work against compliance. Anyone can view the blockchain and trace every transaction. Anyone can potentially buy or receive tokens, and off-chain checks can be bypassed or overlooked. If you're issuing regulated securities, relying on off-chain enforcement is risky.

ERC-3643 inverts the paradigm. Compliance isn't bolted on top of the token—it's built into the token's DNA. The smart contracts themselves verify eligibility before allowing transfers. This creates what we call "compliance by design."

The key innovation: instead of a single token contract, ERC-3643 uses a modular architecture where multiple smart contracts work together:

• On-chain identities hold cryptographic proof of KYC/AML status

• Identity Registries map wallet addresses to verified identities

• Compliance modules enforce business rules (geographic restrictions, investor caps, lock-up periods)

• The token contract orchestrates all three layers before executing any transfer

This modular design is critical. It means compliance rules can be updated without touching the token contract itself, and different issuers can use the same infrastructure with different rules.

How ERC-3643 Architecture Works

On-Chain Identities (ONCHAINID)

Every participant in an ERC-3643 ecosystem needs an ONCHAINID—a smart contract that represents that person or entity on-chain.

Think of an ONCHAINID as a digital identity vault. It holds verifiable claims issued by trusted third parties: "This person passed KYC," "This person is an accredited investor," "This person is based in the EU." These claims are cryptographically signed by trusted KYC providers, making them tamper-proof.

The ONCHAINID standard (based on ERC-734/735) means these identity contracts are interoperable. A person can have a single ONCHAINID that they use across multiple ERC-3643 tokens and platforms.

Identity Registry

The Identity Registry is the contract that checks identities at transfer time. It maintains a mapping: wallet address → ONCHAINID contract.

When a token transfer is initiated, the Identity Registry's isVerified() function runs a check:

1. Is the sender's wallet linked to a valid ONCHAINID?

2. Does that ONCHAINID hold the required claims (e.g., "KYC passed," "Not US-based")?

3. Is the receiver also verified with the same requirements?

If both checks pass, the transfer continues. If either fails, the transaction reverts.

This verification happens on-chain and is auditable—you have a permanent record of who held what tokens and whether they were compliant at the time.

Compliance Module

Identity verification ensures "who" can hold tokens. The Compliance Module defines "how" tokens can move.

Examples of compliance rules:

• Investor caps: No single investor can own more than 5% of a token

• Jurisdictional restrictions: Tokens cannot be transferred to addresses associated with sanctioned countries

• Lock-up periods: Investors cannot sell within the first 12 months

• Holder limits: The token can have no more than 999 holders (to maintain exempt security status in some jurisdictions)

The Compliance Module is separate from the token contract, which means issuers can adjust rules over time without redeploying. Different tokens can reuse the same compliance module, or each can have custom logic.

The Token Contract

The ERC-3643 token contract itself extends the familiar ERC-20 interface but adds a critical gate: before any transfer executes, it performs two checks.

This design preserves backward compatibility (ERC-3643 tokens work in standard wallets) while ensuring compliance enforcement at the protocol level.

Comparing ERC-3643 to Other Token Standards

ERC-1400 pioneered the idea of compliance-aware tokens, but ERC-3643 improves on it by decoupling compliance logic from the token contract itself. This makes rules easier to update and tokens easier to reuse.

Step-by-Step: Deploying an ERC-3643 Token

Deploying a compliant security token requires orchestrating multiple smart contracts. Most projects don't do this manually—they use a T-REX Factory, which automates the entire setup in a single transaction.

Step 1: Prepare Your Configuration

Before deployment, you need to define:

Token Details:

• Token name, symbol, decimals (standard metadata)

• Addresses of agents who can mint, freeze, or manage the token

• Any pre-existing Identity Registry Storage you want to reuse

• Which compliance modules to activate

Claim Configuration:

• What types of claims are required (e.g., KYC passed, accreditation level)

• Which KYC providers you trust to issue claims

• What claims each provider can issue

Step 2: Call the Factory

Once parameters are assembled, you call deployTREXSuite() on the factory contract. This executes a single atomic transaction that:

1. Deploys a Trusted Issuers Registry (tracks which KYC providers are trusted)

2. Deploys a Claim Topics Registry (defines required claim types)

3. Deploys the Compliance Engine (enforces rules)

4. Deploys the Identity Registry Storage (stores identity data)

5. Deploys the Identity Registry (validates identities at transfer time)

6. Deploys the Token contract (your security token)

7. Links all components together

8. Assigns agent roles for operational management

All of this happens atomically. If any step fails, the entire deployment reverts.

Step 3: Register Trusted KYC Providers

Before investors can hold tokens, their identities must be verified by a trusted provider. You register approved KYC providers (like Tokeny, Passbase, or other RegTech firms) in the Trusted Issuers Registry.

These providers will issue cryptographic claims to investor ONCHAINIDs, proving they've passed KYC/AML.

Step 4: Onboard Investors

For each investor:

1. Create or provide an ONCHAINID (a smart contract holding their identity)

2. Work with a trusted KYC provider to issue claims to that ONCHAINID

3. Register the investor's wallet address and link it to their ONCHAINID in the Identity Registry

4. Only after verification can the investor receive tokens

Step 5: Mint and Transfer

Once everything is in place, you can mint tokens to verified investors. Every subsequent transfer automatically checks identity and compliance rules before execution.

The investor doesn't need to do anything special—they use standard wallets and interfaces. The compliance logic runs invisibly at the smart contract layer.

Regulatory Alignment: MiFID II and MiCA

ERC-3643 wasn't designed in a vacuum. It was created with European financial regulation in mind.

MiFID II (Markets in Financial Instruments Directive II) requires:

• Investor identification and verification

• Suitability checks (ensuring investments match investor profile)

• Clear record-keeping of transactions

MiCA (Markets in Crypto-Assets Regulation), coming into force in 2024, extends these requirements to crypto-native issuers.

ERC-3643 directly addresses these requirements:

• ONCHAINID and Identity Registries satisfy identification requirements

• Compliance modules can enforce suitability rules

• On-chain transactions create immutable audit logs

For European issuers, using an ERC-3643-compatible platform significantly de-risks regulatory compliance. The compliance logic is transparent, verifiable, and documented at the code level.

Real-World Implementations

ERC-3643 isn't theoretical. It's already powering regulated token issuances:

• Tokeny: A leading platform for security token issuance on ERC-3643, powering institutional deployments across Europe

• Private debt tokens: European asset managers tokenizing private bonds and credit funds

• Real estate: Fractional real estate tokenization, with geographic and investor restrictions enforced on-chain

• Fund tokens: Private equity and hedge fund tokens with lock-up periods and accreditation requirements

These deployments prove that ERC-3643 works at scale and meets real regulatory requirements.

Why Choose ERC-3643 for Regulated Tokenization

Compliance as Code: Compliance rules are transparent, auditable, and enforced automatically—no reliance on manual off-chain processes.

Investor Confidence: Clear on-chain verification builds trust in token legitimacy.

Regulatory Clarity: Built for MiFID II and MiCA, reducing legal risk for European issuers.

Operational Efficiency: Automating transfer validation reduces administrative overhead.

Flexibility: Modular architecture means rules can be updated without redeploying the token.

Interoperability: ONCHAINID-based identities work across multiple tokens and platforms.

Simplify ERC-3643 Implementation with ONINO

Deploying and managing an ERC-3643 token stack is complex. You need to understand smart contracts, compliance rules, identity management, and KYC integrations.

That's where ONINO comes in. Our platform abstracts away the technical complexity, letting you focus on business logic.

With ONINO, you can:

• Deploy compliant tokens in minutes, not months, with pre-configured ERC-3643 infrastructure

• Integrate KYC providers seamlessly—ONINO handles identity verification and claim issuance

• Manage compliance rules through an intuitive dashboard without writing smart contracts

• Access institutional-grade security and regulatory expertise

• Scale efficiently across multiple tokens and issuances

Whether you're tokenizing real estate, private equity, or emerging asset classes, ONINO provides the regulated tokenization platform built for European compliance.

Frequently Asked Questions

Do investors need a separate ONCHAINID for each token?

No. An investor can have a single ONCHAINID that holds verified claims from multiple KYC providers. That same identity can be used across different ERC-3643 tokens and platforms. This reduces onboarding friction for repeat investors.

Does ERC-3643 eliminate off-chain KYC?

No—KYC/AML checks still happen off-chain with regulated providers. However, the results are represented on-chain as cryptographic claims stored in the investor's ONCHAINID. The token system reads these claims during transfers, enabling automated on-chain compliance.

Can ERC-3643 tokens trade on secondary markets?

Yes, but transfers remain permissioned. Even if a token is listed on an exchange, every transfer must pass identity and compliance checks. This means the token can trade, but only between verified, compliant investors.

Is ERC-3643 compatible with standard wallets?

Yes. ERC-3643 maintains backward compatibility with ERC-20, so it works in MetaMask, hardware wallets, and other standard interfaces. The compliance logic runs transparently at the smart contract layer.

How do compliance rules get updated?

Since compliance modules are separate from the token contract, rules can be updated by the token issuer without redeploying the token itself. This allows issuers to adapt to regulatory changes or adjust business rules over time.

Ready to Issue Compliant Security Tokens?

ERC-3643 provides the technical foundation for regulated tokenization, but implementation requires expertise in smart contracts, compliance, and KYC integration.

Let ONINO handle the complexity. Our platform provides institutional-grade infrastructure for deploying, managing, and scaling ERC-3643 tokens—designed for European issuers navigating MiFID II and MiCA requirements.

Book a demo with our team to see how ONINO can accelerate your tokenization roadmap.

Or explore our regulated tokenization solutions to learn more about how we support compliant asset financing and issuance.