Smart Contracts
Smart Contracts
Every tokenized offering on T-Suite is backed by smart contracts. For permissioned securities on EVM chains that means the ERC-3643 (T-REX) standard, where identity and compliance checks run inside the token’s own transfer logic. This page describes the contract stack, how primary orders settle on-chain, which standards run on which chain, and how to find the address of any contract.
For what each standard means to an issuer or investor, see Token standards.
Chain matrix
| Chain (mainnet) | ERC-3643 (T-REX) | ERC-20 | ERC-721 |
|---|---|---|---|
| Base | Live | Live | Live |
| Ethereum | Live (since 21 July 2026) | Live (since 8 September 2026) | — |
| Polygon | Live | — | — |
| Arbitrum | Live | — | — |
| Cardano | CIP-20 metadata tokens live |
- Testnets: Base Sepolia, Ethereum Sepolia, Polygon Amoy, Arbitrum Sepolia and Avalanche Fuji are available for testing. See Environments & networks.
- Not live for tokenization: BNB Chain and Avalanche mainnets.
- CIP-113 is not live on Cardano mainnet — it runs on the Cardano preview testnet.
- Secondary market (P2P): live on Base mainnet; Ethereum and Cardano mainnet are next.
The ERC-3643 stack
An ERC-3643 token only moves between wallets whose owners have a verified on-chain identity and only when every compliance rule allows it. The stack has four layers.
1. Identity (ONCHAINID)
| Contract | Role |
|---|---|
| Identity | An on-chain identity contract per investor, linked to their wallet and holding signed claims (for example, “KYC approved”) |
| Identity Factory | Deploys investor identity contracts |
| Identity Factory Gateway | Controlled entry point to the Identity Factory, so that only authorised deployers can create identities |
| Claim issuer | The trusted party that signs claims onto identities |
2. Registries
| Contract | Role |
|---|---|
| Identity Registry | Answers “is this wallet verified for this token?” — links wallets to identities and checks the required claims |
| Identity Registry Storage | Stores the wallet → identity → country mapping; can be shared between tokens |
| Claim Topics Registry | Lists which claim types a token requires |
| Trusted Issuers Registry | Lists which claim issuers a token trusts, and for which claim types |
3. Compliance
| Contract | Role |
|---|---|
| Modular Compliance | Called by the token on every mint and transfer; asks each bound module whether the action is allowed |
| Country Allow module | Only holders from listed countries — a strict whitelist |
| Country Restrict module | Blocks holders from listed countries |
| Max Balance module | Caps how many tokens a single holder can hold |
| Hold Time module | Locks tokens for a minimum period after acquisition |
| Supply Limit module | Caps the total supply of the token |
The issuer chooses and configures these rules in the Tokenization Wizard; the same limits are also checked off-chain when an order is placed. See Compliance enforcement.
4. Token and factories
| Contract | Role |
|---|---|
| Token | The ERC-3643 security token for one offering. Its agent can mint, burn, freeze and force-transfer, as the standard requires for regulated securities |
| Implementation Authority | Points each token’s proxy at the approved token implementation |
| TREX Factory | Deploys a complete token suite — token, registries and compliance — for an offering in one transaction |
| TREX Gateway | Controlled entry point to the TREX Factory, so that only authorised deployers can create token suites |
Fund contract
Alongside its token, each ERC-3643 offering gets a Fund contract, deployed through the Fund Factory. It holds offering-level parameters that other contracts read — the latest NAV, an optional off-chain asset price and dividend distribution status. The Fund Factory also holds the per-offering fee configuration that Escrow reads at settlement.
Escrow settlement
Primary orders paid in USDC or USDT settle through the Escrow contract:
- Deposit. The investor’s wallet approves the stablecoin and calls Escrow to record the order — offering, amount, number of tokens. Escrow checks that the investor is verified in the token’s Identity Registry, that the token was deployed by Libertum’s factory, and that the stablecoin is supported. Funds remain in the investor’s wallet under the approval until settlement.
- Settlement. The issuer’s agent wallet settles the order. In one transaction Escrow moves the net amount to the issuer, the platform fee to Libertum’s fee wallets, and mints the tokens to the investor. Payment and delivery happen together or not at all.
- Cancel or reject. Before settlement, the investor can cancel their order, or the issuer can reject it. No tokens are minted and no funds move.
The backend checks that an on-chain payment exactly matches the order before it is accepted. Escrow also offers batch operations for the token’s agent — batch settlement, minting, burning, freezing, forced transfers, identity registration, dividend distribution, and redemption with burn.
Other EVM contracts
| Contract | Role |
|---|---|
| Marketplace (P2P) | The on-chain order book for secondary trading between verified holders — live on Base mainnet |
| ERC-20 Factory | Deploys standard ERC-20 tokens for offerings that do not need permissioned transfers |
| ERC-721 Factory | Deploys ERC-721 collections for unique assets |
| Agreement anchor | Optionally records the hash of an executed investment agreement on-chain (Base or Cardano), when enabled for the deployment |
Cardano
Cardano transactions are built and signed by Libertum’s Cardano service.
- CIP-20 (mainnet, live). Native Cardano tokens with transaction metadata. Compliance is enforced off-chain by the platform.
- CIP-113 (preview testnet only). Programmable, regulated tokens whose transfer rules are enforced on-chain. Mainnet support follows the Cardano Foundation’s canonical CIP-113 mainnet release.
XRPL
Status: Infrastructure — not yet selectable
The backend supports XRPL platform accounts, on-ledger credential issuance (XRPL Credentials), trust-line authorisation and reserve management, and XRPL can appear as a Custodian Wallet network where enabled. Issuers cannot yet choose XRPL in the Tokenization Wizard.
Finding contract addresses
You do not need a list of addresses to verify an offering:
- On the offering page. A deployed offering has a Trust Topology section listing This token (the token contract and its deployment transaction) and the Underlying protocol contracts it depends on — factories, registries and compliance modules for that chain and standard. Each row has the address, a copy button and a link to the block explorer.
- On the block explorer. From the token you can follow its Identity Registry, Modular Compliance and bound modules, and read their configuration directly.
- Transactions. Order settlements, transfers and NAV updates are ordinary transactions on the offering’s chain, visible on the explorer.
For reference, the core factories on Base mainnet (chain ID 8453) are:
| Contract | Address |
|---|---|
| TREX Factory | 0x49E08c0272841B60E3aC9203E6A14844DeaF9e70 |
| TREX Gateway | 0x63f6F6Cf13D6e4566CFba2D4d8634E87dA465C17 |
| Identity Factory | 0x182904356AAa2e1DED826F8541145d0c347a2580 |
| Identity Factory Gateway | 0x2CC97d3EF15bF878c487c07A1Db572ab881ebF5a |
| ERC-20 Factory | 0xE16feD3d4E9a6AeA6A7cA783B9CcDD3C491eAE7d |
| ERC-721 Factory | 0x22d503EF004c6E143084Ae876A60555D3fA02630 |
| Fund Factory | 0xB7104f56D355018Ab604E6e66EaDa3F719144161 |
Addresses differ on every chain, and a testnet address never exists on the matching mainnet. Always check an address on the explorer for the chain you are using.