TIP-3643: T-REX – Token for Regulated EXchanges on TRON

[lopeed]

tip: 3643
title: T-REX – Token for Regulated EXchanges on TRON
author: lopeed
status: Draft
type: Standards Track
category: TRC
created: 2026-03-30
requires: 20 (TRC-20)

---

Simple Summary

This TIP defines a token standard (TRC-3643) for issuing and managing regulated assets, such as real‑world assets (RWAs) and security tokens, on the TRON blockchain. It extends TRC‑20 with built‑in compliance features including on‑chain identity management (key and claim management), whitelisting, transfer restrictions, asset freezing, and recovery mechanisms. The standard is designed to align with global regulatory frameworks like MiCA and MiFID II while remaining compatible with the TRON DeFi ecosystem, MetaMask native TRON support, and existing ONCHAINID tooling.

---

Abstract

TRC-3643 introduces a modular set of smart contracts that work together to enforce regulatory requirements directly on‑chain:

· TRC-3643 Token: A TRC‑20 compliant token whose transfer function is gated by identity and compliance checks.
· Identity Registry (IR): Links wallet addresses to on‑chain identities that manage keys and verifiable claims.
· Trusted Issuers Registry (TIR): Lists entities authorised to issue claims to identities.
· Claim Topics Registry (CTR): Defines which claim topics (e.g., KYC status, accredited investor) are required for a user to hold or transfer the token.
· Compliance Module: Enforces global rules such as maximum token holdings per address or per country, and allows agents to freeze/unfreeze addresses or force transfers when required by law.

The standard preserves interoperability with existing TRC‑20 wallets and explorers while giving issuers the tools to meet anti‑money laundering (AML), counter‑terrorism financing (CTF), and securities regulations. It leverages the ONCHAINID SDK (which works with any Ethers‑compatible provider) and modern wallet adapters to enable seamless user experiences across both TRON and EVM ecosystems.

---

Motivation

TRC‑20 is the dominant token standard on TRON, but it lacks native mechanisms for compliance. Issuers of RWAs and security tokens must guarantee that only verified investors can hold the tokens, that transfers can be blocked by court order, and that tokens can be recovered if a private key is lost. Without a standardised approach, each project implements its own ad‑hoc solution, leading to fragmentation, security risks, and higher audit costs.

By providing a unified standard, TIP-3643:

· Lowers the barrier for institutions to tokenise assets on TRON.
· Ensures compatibility across multiple regulated tokens and service providers.
· Gives regulators confidence that TRON‑based assets can meet compliance requirements without leaving the blockchain.
· Leverages existing infrastructure: the ONCHAINID SDK, and MetaMask’s native TRON support.
· Allows reuse of identity contracts across multiple tokens, reducing deployment costs.

---

Specification

The standard defines the following core components. A token is considered TRC-3643 compliant if it implements the described interfaces and interacts with the corresponding registry contracts.

1. Token Contract (TRC-3643)

The token contract MUST implement all functions of TRC‑20 plus the following:

interface ITRC3643 /* is TRC20 */ {
    // Returns true if the address is fully verified (in identity registry + required claims)
    function isVerified(address user) external view returns (bool);

    // Checks whether a transfer between two addresses would be allowed
    function canTransfer(address from, address to, uint256 amount) external view returns (bool);

    // Forces a transfer between two verified addresses (only callable by agent)
    function forcedTransfer(address from, address to, uint256 amount) external;

    // Freezes a user's holdings (only callable by agent)
    function freeze(address user) external;

    // Unfreezes a user (only callable by agent)
    function unfreeze(address user) external;

    // Recovers tokens from a lost address to a new one (only callable by agent)
    function recoverTokens(address lostAddress, address newAddress, uint256 amount) external;

    // Modifier for compliance: the `transfer` and `transferFrom` functions MUST call `_beforeTokenTransfer` which invokes `canTransfer`
}

2. Identity Registry

Each token references an identity registry contract that stores the mapping between wallet addresses and on‑chain identities. The registry also interacts with the identities to check claims.

interface IIdentityRegistry {
    // Binds an address to an on‑chain identity (which must implement the required key/claim interface)
    function bindIdentity(address user, IIdentity identity, uint16 countryCode) external;

    // Unbinds an address (removes verification)
    function unbindIdentity(address user) external;

    // Checks if the address is currently verified (identity bound and has required claims)
    function isVerified(address user) external view returns (bool);

    // Returns the identity contract associated with an address
    function getIdentity(address user) external view returns (IIdentity);

    // Freeze / unfreeze an address at the identity level
    function freeze(address user) external;
    function unfreeze(address user) external;
    function isFrozen(address user) external view returns (bool);
}

3. On‑Chain Identity (Key and Claim Interface)

The identity contract MUST implement a key management and claim management interface that allows trusted issuers to add, remove, and verify claims about the identity holder. The following interface is based on the widely adopted ONCHAINID implementation and satisfies the requirements of ERC-3643.

Key Management (simplified):

interface IIdentityKeys {
    function getKey(bytes32 _key) external view returns (uint256[] memory purposes, uint256 keyType, bytes32 key);
    function addKey(bytes32 _key, uint256 _purpose, uint256 _keyType) external returns (bool success);
    function approve(uint256 _id, bool _approve) external returns (bool success);
}

Claim Management (simplified):

interface IIdentityClaims {
    struct Claim {
        uint256 claimTopic;
        uint256 scheme;
        address issuer;
        bytes signature;
        bytes data;
        string uri;
    }
    function getClaim(uint256 _claimTopic) external view returns (Claim memory);
    function addClaim(uint256 _claimTopic, uint256 _scheme, address issuer, bytes calldata _signature, bytes calldata _data, string calldata _uri) external returns (uint256 claimRequestId);
    function removeClaim(uint256 _claimTopic) external returns (bool success);
    function hasClaim(uint256 _claimTopic) external view returns (bool);
}

A compliant identity contract SHOULD implement both interfaces (or equivalent functions) to support key recovery and claim verification.

The identity verification flow for isVerified in the Identity Registry must:

1. Check that the address is bound to an identity contract.

2. Verify that the identity contract has claims for all topics listed in the Claim Topics Registry.

3. Validate that each claim’s issuer is listed in the Trusted Issuers Registry for that claim topic.

4. (Optional) Validate the claim’s cryptographic signature and expiration (if present).

5. Trusted Issuers Registry (TIR)

interface ITrustedIssuersRegistry {
    function addTrustedIssuer(address issuer, uint256[] calldata claimTopics) external;
    function removeTrustedIssuer(address issuer) external;
    function isTrustedIssuer(address issuer, uint256 claimTopic) external view returns (bool);
}

5. Claim Topics Registry (CTR)

interface IClaimTopicsRegistry {
    function setClaimTopics(uint256[] calldata topics) external;
    function getClaimTopics() external view returns (uint256[] memory);
    function isUserVerified(address user, IIdentityRegistry identityRegistry) external view returns (bool);
}

6. Compliance Module (Optional but Recommended)

A separate contract that holds global rules, such as:

· Maximum number of tokens an address can hold.
· Maximum number of token holders.
· Country‑based restrictions.

The token’s canTransfer function should query this module before allowing a transfer.

---

Rationale

Identity and Claim Management

The choice to use the ONCHAINID‑style key and claim management is deliberate:

· Proven security: The ONCHAINID implementation has been audited and used in production since 2018.
· Interoperability: The ONCHAINID SDK and many third‑party tools are built to work with this interface.
· Separation of concerns: Key management and claims are separate, allowing flexible recovery (key rotation) and verifiable attestations from multiple issuers.
· Regulatory alignment: On‑chain claims provide an auditable trail of who issued each claim and when, satisfying audit requirements.

Agent Role

The agent role (distinct from the token owner) allows day‑to‑day compliance operations (freezing, forced transfers) without giving full ownership rights. This is a common requirement for regulated securities.

Recoverability

Unlike standard TRC‑20, the standard includes a recoverTokens function to handle lost private keys, a feature demanded by institutional investors.

EVM Compatibility and MetaMask Integration

TRON’s TVM is fully EVM‑compatible and exposes a JSON‑RPC interface that mirrors Ethereum’s. As a result, existing tooling such as the ONCHAINID SDK works seamlessly on TRON. Moreover, MetaMask now supports TRON natively (announced January 2026), allowing users to manage TRX and TRC-20 tokens directly within MetaMask. Official adapters like @metamask/connect-tron and @tronweb3/tronwallet-adapter-metamask-tron enable dApps to integrate MetaMask with the same API used for TronLink.

This means that TRC-3643 tokens can be used by millions of MetaMask users without installing additional wallets, greatly lowering the onboarding friction for regulated assets.

ONCHAINID SDK Compatibility

The ONCHAINID SDK is built on Ethers.js and works with any provider that supports the Ethers API. Because TRON’s JSON‑RPC interface is compatible, the same SDK can connect to TRON nodes and to MetaMask’s Web3 provider. The following code snippet illustrates this:

import { ethers } from 'ethers';
import { IdentitySDK } from '@onchainid/sdk';

// Connect to TRON node via HTTP or via MetaMask
const provider = new ethers.providers.JsonRpcProvider('https://api.trongrid.io');
// Or with MetaMask:
// const provider = new ethers.providers.Web3Provider(window.ethereum);

const identity = await IdentitySDK.Identity.at('0x...', { provider });
// identity.addKey(...) etc.

All registry and identity methods work identically on TRON, ensuring that projects can reuse the same backend and frontend code across Ethereum and TRON deployments.

---

Implementation

Reference Implementations

Component Repository
ONCHAINID (Key/Claim contracts) https://github.com/onchain-id/solidity
T‑REX (ERC‑3643) https://github.com/TokenySolutions/T-REX
ONCHAINID SDK https://docs.onchainid.com/docs/developers/sdk

Using ONCHAINID SDK on TRON

The ONCHAINID SDK works out of the box with TRON by providing an Ethers-compatible provider pointing to a TRON RPC endpoint.

Example: Fetching a user’s claims on TRONGrid

import { ethers } from 'ethers';
import { IdentitySDK } from '@onchainid/sdk';

const provider = new ethers.providers.JsonRpcProvider('https://api.trongrid.io');
const identity = await IdentitySDK.Identity.at('0xUserIdentityAddress', { provider });

// Get claim for topic 1 (e.g., KYC approved)
const claim = await identity.getClaim(1);
console.log(`Issuer: ${claim.issuer}, data: ${claim.data}`);

MetaMask Adapters for TRON

Two packages are available to integrate MetaMask into TRON dApps:

Package Purpose
@metamask/connect-tron Official MetaMask adapter implementing the standard TronWallet interface.
@tronweb3/tronwallet-adapter-metamask-tron Community adapter compatible with the tronwallet-adapter ecosystem.

Usage example with @metamask/connect-tron:

import { MetaMaskAdapter } from '@metamask/connect-tron';
import TronWeb from 'tronweb';

const tronWeb = new TronWeb({ fullHost: 'https://api.trongrid.io' });
const adapter = new MetaMaskAdapter();
await adapter.connect();

console.log(adapter.address);
const signedTx = await adapter.signTransaction(unsignedTransaction);

Deploying TRC-3643 on TRON

To deploy a TRC-3643 token on TRON:

1. Deploy the ONCHAINID contracts (key and claim management), Identity Registry, Trusted Issuers Registry, and Claim Topics Registry (following the T-REX pattern).
2. Deploy the token contract (inheriting from TRC‑20 and adding the TRC-3643 interface), passing the addresses of the registries.
3. Configure trusted issuers and required claim topics.
4. Integrate the frontend using the ONCHAINID SDK and a wallet adapter (MetaMask or TronLink).

---

Security Considerations

· Claim validation: Only trusted issuers can add claims. The token owner must carefully manage the TIR to prevent unauthorised issuers from falsely verifying users.
· Agent privileges: Agents have significant power (freezing, forced transfers). The agent list must be protected by multi‑signature or DAO governance.
· Upgradeability: Proxy patterns introduce upgrade risks. All upgrades should be time‑locked and audited.
· Privacy: On‑chain identity stores only references to off‑chain data. No personal information (name, address) is stored on‑chain. This is intentional to comply with GDPR and other data protection laws.
· Network compatibility: When using MetaMask with TRON, ensure that the dApp correctly detects the network (TRON mainnet) and handles chain switching events to maintain consistent compliance rules.
· Claim expiration: Implementers SHOULD verify that claims are still valid (if expiration data is present in the claim) during isVerified checks.

---

Copyright

This TIP is licensed under the MIT License.

---

This proposal is based on the ERC-3643 standard developed by Tokeny Solutions and the ONCHAINID key/claim management implementation. It has been adapted for the TRON ecosystem, incorporating native MetaMask support and TRON wallet adapters.

[yanghang8612]

I cannot find information about ERC-734 or ERC-735 on EIPs websites. Are they officially included in EIPs or ERCs?

[lopeed]

I cannot find information about ERC-734 or ERC-735 on EIPs websites. Are they officially included in EIPs or ERCs?

Thank you for the careful review. You are correct that ERC-734 and ERC-735 are not listed as "Final" EIPs. However, they are referenced as required dependencies in the original ERC-3643 specification

https://docs.erc3643.org/erc-3643/overview-of-the-protocol/interoperability-and-standards

https://eips.ethereum.org/EIPS/eip-3643

and are implemented in production by the widely used ONCHAINID library .
https://amoy.polygonscan.com/address/0x2f0cc2a7e37098c12d4ff3ffc16195515c6c8066#code

This TIP follows the same architecture. I will update the draft to clarify their status as de facto standards and reference the concrete implementations rather than relying solely on the EIP numbers.

[yanghang8612]

I also couldn't find any description of ERC-734 or ERC-735 in the EIP-3643. Could you please point it out?

If you deem it necessary, ERC-734 or ERC-735 should be introduced into the TRON ecosystem before or at least simultaneously.