Token Standards & Smart Contracts
Token Standards & Smart Contracts
The seven live standards at a glance
| Standard | Chain family | Mainnets | Compliance |
|---|---|---|---|
| ERC-3643 (T-REX) | EVM | Base, Ethereum, Polygon, Arbitrum, BNB Smart Chain | On-chain identity and compliance modules on every transfer |
| ERC-20 | EVM | Base, Ethereum | Platform-level (KYC at the marketplace); no on-chain identity check |
| ERC-721 | EVM | Base | Platform-level; one-of-one tokens |
| CIP-20 | Cardano | Cardano | Platform-level; native token with metadata |
| CIP-113 | Cardano | Cardano (since 5 October 2026) | On-chain programmable rules and Libertum compliance modules |
| XRPL Issued Currency (XRPL-IC) | XRP Ledger | XRPL | Credentials, authorised trust lines, clawback |
| XRPL MPT (XLS-33) | XRP Ledger | XRPL | Credentials and issuer-authorised holders; DEX trading waits on MPTokensV2 |
All seven are selectable in the Tokenization Wizard. Testnets: six EVM testnets, Cardano preview and the XRPL testnet.
1. ERC-3643 (T-REX)
Status: Live on Base, Ethereum, Polygon, Arbitrum and BNB Smart Chain mainnets.
Name: Token for Regulated EXchanges. Originally developed by Tokeny SA, now an ERC.
Why we use it. ERC-3643 is the most mature security-token standard. It embeds compliance directly into transfer logic: every transfer call checks the sender’s frozen status, the receiver’s identity verification, and a chain of compliance modules — before moving any tokens. This is fundamentally different from “compliance-as-paperwork” approaches where a backend logs transfers and flags violations after the fact.
The contract suite. A T-REX deployment is a suite of six core contracts plus N compliance modules:
- Token — the ERC-20-compatible token contract with overridden
transferthat enforces compliance. - Identity Registry — maps wallet addresses to identity contracts and tracks claim status.
- Identity Registry Storage — the identity data layer; allows multiple tokens to share one identity registry (gas savings).
- Trusted Issuers Registry — the list of approved claim issuers (KYC providers, accreditation attesters).
- Claim Topics Registry — the list of valid claim topics for this token (e.g. “is-KYC-verified”, “country”, “is-accredited”).
- Modular Compliance — the rule controller; chains together compliance modules each transfer must pass.
Plus deployed compliance modules: Country Allow, Country Restrict, Supply Limit, Max Balance, Hold Time.
Permission model.
- Token Owner — can change compliance config, change identity registry, change ownership; should be a hardware wallet or multi-sig held by the issuer.
- Agents — can mint, burn, pause, unpause, freeze, unfreeze, force-transfer, recover. Operational wallets, often the platform’s relayer.
- Investors — can transfer subject to all compliance checks.
Why a factory? Deploying six contracts plus N modules per offering is expensive and error-prone. The TREXFactory deploys the whole suite in one transaction with deterministic CREATE2 addresses. Implementations are shared across all suites through the TREX Implementation Authority; per-suite proxies hold each offering’s state.
2. CIP-113
Status: Live on Cardano mainnet since 5 October 2026, and on preview, on the Cardano Foundation’s canonical CIP-113 v0.0.1 core.
Name: Cardano Improvement Proposal 113 — Programmable Tokens.
Why we built this. Cardano’s UTXO model and Plutus validators offer formal-methods-friendly compliance enforcement and materially lower per-transaction fees than Ethereum. CIP-113 is the Cardano analogue to ERC-3643: programmable tokens where transfer rules are enforced by on-chain scripts.
Status in detail. Libertum’s CIP-113 integration has been live on Cardano mainnet since 5 October 2026, and is also available on preview. It runs on the Cardano Foundation’s canonical CIP-113 deployment (the v0.0.1 core); Libertum does not operate its own core. Tokens are registered in the canonical CIP-113 registry, which explorers and wallets index, and the canonical core is governed by the Cardano Foundation’s upgrade authority. Use preview to rehearse an offering before taking it to mainnet.
Tooling. Plutus validators compiled with Aiken. Off-chain transaction building in TypeScript on Node.js, with Mesh SDK for CIP-20 native assets. Chain data comes from Blockfrost. CIP-30 wallet integration on the frontend (for example Eternl and Lace).
Libertum compliance modules. On top of the CIP-113 core, Libertum adds its own on-chain compliance modules: an on-chain KYC list with claim topics, country allow / restrict lists, lock-up, pause, supply and per-holder caps, and partial (amount) freezes. Issuers can freeze, unfreeze, seize and force-transfer — the Cardano equivalent of ERC-3643’s setAddressFrozen + forcedTransfer. NAV updates are anchored on-chain in Cardano transaction metadata (label 674).
3. CIP-20
Status: Live on Cardano mainnet.
Name: Cardano native multi-asset standard (fungible), with CIP-20 transaction metadata.
Why we use it. CIP-20 tokens use Cardano’s native fungible-token format — analogous to ERC-20 but native to the ledger. No programmable compliance. Used for offerings where compliance is enforced off-chain by the platform rather than on-chain.
Availability. Live on Cardano mainnet, and available on Cardano preview for testing.
4. ERC-20 / ERC-721
Status: Live — ERC-20 on Base and Ethereum mainnets; ERC-721 on Base mainnet.
Standard EVM token formats. Used for:
- ERC-20 — fungible tokens without on-chain identity checks, such as utility or governance tokens and simpler offerings.
- ERC-721 — one-of-one tokenization (a specific real estate parcel as a single NFT, an artwork). Libertum’s own implementation:
LibertumERC721, deployed viaERC721Factory.
These don’t carry programmable compliance the way ERC-3643 does. Libertum still gates them at the marketplace level — a buyer must be KYC-verified to receive even an ERC-20 — but the contract itself has no on-chain identity check.
5. Standard selection guide
| If you’re issuing… | Pick |
|---|---|
| Tokenized real estate, equity, debt, securities of any kind on EVM | ERC-3643 |
| Same on Cardano, with on-chain compliance enforcement | CIP-113 (Cardano mainnet and preview) |
| Same on Cardano mainnet, today, with off-chain compliance gating | CIP-20 |
| Utility / governance token on EVM | ERC-20 (Base or Ethereum) |
| Single-item collectible / unique asset | ERC-721 (Base) |
| Token on the XRP Ledger, held through trust lines | XRPL Issued Currency (XRPL mainnet) |
| Token on the XRP Ledger using the native Multi-Purpose Token object | XRPL MPT (XLS-33) (XRPL mainnet) |
| Bonding-curve liquidity token | Bonding Token — B-DEX preview, not live |
Chain availability
| Chain (mainnet) | ERC-3643 (T-REX) | ERC-20 | ERC-721 |
|---|---|---|---|
| Base | Live | Live | Live |
| Ethereum | Live (since 21 Jul 2026) | Live (since 8 Sep 2026) | — |
| Polygon | Live | — | — |
| Arbitrum | Live | — | — |
| BNB Smart Chain | Live (since 15 Sep 2026) | — | — |
| Chain (mainnet) | Cardano standards |
|---|---|
| Cardano | CIP-20 tokens live; CIP-113 live (Cardano Foundation’s canonical CIP-113 deployment) |
| Chain (mainnet) | XRPL standards |
|---|---|
| XRP Ledger | Issued Currency (trust-line) live; MPT (XLS-33) live |
- Testnets. All six EVM testnets — Base Sepolia, Ethereum Sepolia, Polygon Amoy, Arbitrum Sepolia, Avalanche Fuji and BNB Smart Chain Testnet — are available for testing. Cardano preview is available for CIP-20 and CIP-113 testing.
- Not live for tokenization: Avalanche mainnet.
- Secondary market (P2P order book): live on Base mainnet; Ethereum and Cardano mainnet are next.
- Primary payments in crypto: on EVM chains, USDC and USDT payments for primary orders settle through the Escrow contract to the issuer. On the XRP Ledger, investors pay in RLUSD or USDC, verified on-ledger (see section 8).
- Stablecoins accepted: USDC and USDT on EVM (via Escrow); RLUSD and USDC on the XRP Ledger. USDT is not accepted on XRPL (there is no native Tether on XRPL).
6. Smart-contract architecture (Base Mainnet)
All addresses below are public on-chain on Base mainnet (chain ID 8453).
Factories
| Factory | Purpose | Mainnet address |
|---|---|---|
| IdFactory | Deploys identity contracts per investor | 0x182904356AAa2e1DED826F8541145d0c347a2580 |
| TREXFactory | Deploys T-REX suite per offering | 0x49E08c0272841B60E3aC9203E6A14844DeaF9e70 |
Both use CREATE2 for deterministic addresses.
Core ERC-3643 stack (shared infrastructure)
| Contract | Mainnet address |
|---|---|
| Token Implementation | 0x9296FA53C087531e9d4980C5ac8Cd2af94867B1F |
| TREX Implementation Authority | 0x620Ea87011e9F1c9a967b85f2f1Cc812A12F80db |
| Trusted Issuers Registry | 0xC0C92d057eeCF625b715F92e03788A13B9955e38 |
| Claim Topics Registry | 0xaa7B87c6401c4c4342D7a23E70FD78f83082ecA7 |
| Identity Registry Storage | 0x6eDb05548a9F7f06d50a92c0F0De708B2ec16740 |
| Identity Registry | 0xAA99F07FA5b438bD33395bB9Fc95e7eeF3a1aD33 |
| Modular Compliance | 0x20fc20d7039A1ED384D69f9019F1B3d10F48BFF5 |
Compliance modules
| Module | Mainnet address | Purpose |
|---|---|---|
| Country Allow | 0xB8c8F298E4070594CF1B760989AEB1A110A3b31a | Allow only specified countries |
| Country Restrict | 0xECbE2a39958abE721DdBDA3D2979ff6582CfEC72 | Block specified countries |
| Supply Limit | 0x5ceF54C69b556A8f68ed180ACa54f483aCf5Ebfd | Cap total supply |
| Max Balance | 0x97B81D9943F9838eCF51fcaCD499Cac1C0B303Be | Cap any single wallet’s balance |
| Hold Time | 0xaa837190881da43d5cF0EFaCb04375324f9b646d | Prevent transfers within N seconds of mint |
Marketplace, Escrow, Fund
| Contract | Proxy | Implementation | Purpose |
|---|---|---|---|
| Marketplace | 0xA1CD2B7125E44e4F68B6D103ec0Cfe7fa44609Cc | 0x80E440d4563151F493B16eD9aE4e929AA3A2CD0c | P2P secondary order book |
| Escrow | 0x8f8aDaD75a3795A952979D85b500baF2364BBC54 | 0xB12F634cbfCE6df8498E3881Ee03F5A36D9a2FfC | Settles USDC / USDT payments for primary orders to the issuer |
| Fund Factory | 0xB7104f56D355018Ab604E6e66EaDa3F719144161 | 0x407Ed0566fDBF7E3B37ADB2c30c532D386C64646 | Factory for fund contracts |
ERC-3643 Gateways
| Contract | Mainnet address |
|---|---|
| IdFactoryGateway | 0x2CC97d3EF15bF878c487c07A1Db572ab881ebF5a |
| TREXGateway | 0x63f6F6Cf13D6e4566CFba2D4d8634E87dA465C17 |
Gateways add permissioned deployment control. Without gateways, anyone could deploy a TREX suite via the factory; with gateways, only authorised signers can.
ERC-20 / ERC-721 factories
| Contract | Mainnet address |
|---|---|
| LERC20 Implementation | 0x9506416Fa04e9E2B49b3965c4bb0c2F571B87674 |
| ERC20Factory | 0xE16feD3d4E9a6AeA6A7cA783B9CcDD3C491eAE7d |
| LibertumERC721 Implementation | 0x99358D5F9614C1d85Bd0F3F08aEfEd907a001d77 |
| ERC721Factory | 0x22d503EF004c6E143084Ae876A60555D3fA02630 |
NAV Registry
| Contract | Mainnet address |
|---|---|
| NAV Registry | 0x342Ad097C83F08cBEC5f628619FD9C345698605e |
Issuers can publish NAV updates for their offerings; on Base they are recorded in the NAV Registry.
Bonding & Staking
Status: Preview — not live
Bonding-curve and staking contracts belong to B-DEX, which is a preview with no live trading. They are not used by any live offering, so their addresses are not listed here. See B-DEX.
Stablecoins on Base
| Token | Address | Decimals |
|---|---|---|
| USDC (Circle native) | 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 | 6 |
| USDT (bridged Tether) | 0xfde4C96c8593536E31F229EA8f37b2ADa2699bb2 | 6 |
7. Bonding curve formula
Status: Preview — not live
Bonding Token offerings belong to the B-DEX preview. The in-app Convert screen is a preview with no live trading, and no bonding-curve offering is live. The formula below describes the design:
- Initial market cap — set at deployment (e.g. $100,000)
- Premium percentage — premium target (e.g. 20%)
- Target market cap =
initialMarketCap × (1 + premium%) - Token price =
targetMarketCap / totalTokenSupply - Cost to buy X tokens =
X × tokenPrice - Fee =
cost × feePercentage / 10000
Buy: stablecoin in → fee out to fee collector → tokens minted to buyer. Sell: tokens burned → stablecoin out (less fee) to seller.
8. XRPL (XRP Ledger)
Status: Live on XRPL mainnet, and selectable in the Tokenization Wizard.
Issuers can choose one of two XRPL token types:
- XRPL Issued Currency — the classic trust-line token. A holder’s trust line to the token must be authorised before the holder can receive it.
- XRPL MPT (XLS-33) — the ledger’s native Multi-Purpose Token object. MPT offerings are live; DEX trading of MPTs waits on the XRPL MPTokensV2 amendment.
Payments and payouts.
- Investors pay XRPL offerings in RLUSD or USDC, verified on-ledger — either from their own XRPL wallet (using the destination tag shown at checkout) or from their custodian balance. USDT is not accepted on XRPL (there is no native Tether on XRPL).
- Some XRPL Issued Currency offerings settle atomically (delivery-versus-payment): payment and tokens move in the same ledger transaction.
- Redemption payouts and distributions on XRPL are paid in RLUSD or USDC.
- Investors are never charged gas for XRPL transactions.
Supporting infrastructure.
- Platform accounts — Libertum-operated XRPL accounts used by the platform.
- Credentials — on-ledger credential issuance using XRPL Credentials, so a holder’s verification can be represented on the ledger.
- Reserve management — XRPL accounts must hold an XRP reserve, which increases with each object (such as a trust line) the account owns; the platform manages these reserves.
- Holder onboarding — each offering has its own issuer account, created so that only authorised holders can receive the token. Before a holder’s first unit, the platform issues a credential to the holder, the holder opens the trust line (or MPT holding) and the issuer authorises it. A Permissioned Domain created at deployment gates secondary trading to credentialed holders.
- Token Import — existing XRPL issued currencies and MPTs can be imported read-only (cap table and history).
XRPL can also appear as a Custodian Wallet network where it is enabled for a deployment.
9. Smart-contract certificates
Every offering deployed on T-Suite — on EVM (ERC-3643, ERC-20, ERC-721), Cardano (CIP-113) and XRPL (issued currencies and MPTs) — is automatically checked on-chain and receives a signed Smart Contract Certificate from Libertum, which anyone can verify publicly. Imported tokens are certified “as observed — not deployed by Libertum”. See Compliance §11 for what the certificate covers, how to verify it, and what it is not.