Token Standards & Smart Contracts
Token Standards & Smart Contracts
1. ERC-3643 (T-REX)
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; per-suite proxies hold each offering’s state. UUPS-upgradeable.
2. CIP-113
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-tx fees than Ethereum. CIP-113 is the Cardano analogue to ERC-3643: programmable tokens where transfer rules are enforced by Plutus scripts at the protocol level.
Status. Live on Cardano Preview testnet today. Not on Cardano Mainnet until a third-party security audit clears (target Q3 2026).
Tooling. Plutus validators compiled with Aiken. Off-chain transaction building via Mesh SDK (TypeScript) and cclib-cardano (Java for the heavier indexer path). CIP-30 wallet integration on the frontend (Eternl, Lace).
Compliance reference module: freeze-and-seize. The first compliance substandard implemented is freeze-and-seize — the Cardano equivalent of ERC-3643’s setAddressFrozen + forcedTransfer. Four further substandards are in the audit-prep pipeline: CountryAllow, CountryRestrict, MaxBalance, HoldTime. Once audited, CIP-113 will reach feature parity with ERC-3643 on Cardano Mainnet.
3. CIP-20
Name: Cardano native multi-asset standard (fungible).
Why we use it. CIP-20 is Cardano’s standard fungible-token format — analogous to ERC-20 but native to the ledger. No programmable compliance. Used for utility tokens, governance tokens, and offerings where compliance is enforced off-chain rather than on-chain.
Status. Live on Cardano Mainnet today, alongside Cardano Preview.
4. ERC-20 / ERC-721
Standard EVM token formats. Used for:
- ERC-20 — utility tokens, governance tokens, staking tokens.
- 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, willing to wait for Mainnet audit clearance | CIP-113 (preview now, mainnet later) |
| Same on Cardano, today, with off-chain compliance gating | CIP-20 |
| Utility / governance / staking token | ERC-20 |
| Single-item collectible / unique asset | ERC-721 |
| Bonding-curve liquidity token | Bonding Token (custom) |
6. Smart-contract architecture (Base Mainnet)
All addresses below are public on-chain.
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. Both use UUPS proxies.
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 | Holds investor stablecoin during primary subscription; releases or refunds |
| Fund Factory | 0xB7104f56D355018Ab604E6e66EaDa3F719144161 | 0x407Ed0566fDBF7E3B37ADB2c30c532D386C64646 | Per-fund accounting wrapper |
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 | 0x747b13BE9cCbd04F96a2952509d3D744FeEc5724 |
| LibertumERC721 Implementation | 0x27DE684DC87D526251FF3F8aDcC6bFd8Af514fE9 |
| ERC721Factory | 0x106E0236Dd14F313462701a60c3caf6490022DF9 |
Bonding & Staking
| Contract | Mainnet address |
|---|---|
| Bonding Factory Proxy | 0x7EF73E4E6e2Bcb4bF38CFE5d14A50441F63809b9 |
| Staking Controller Proxy | 0xc2FC93B1933797548d583E81c3d07833190aC6b2 |
Stablecoins on Base
| Token | Address | Decimals |
|---|---|---|
| USDC (Circle native) | 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 | 6 |
| USDT (bridged Tether) | 0xfde4C96c8593536E31F229EA8f37b2ADa2699bb2 | 6 |
7. Bonding curve formula
For Bonding Token offerings, pricing is mechanically determined:
- Initial market cap — set at deployment (e.g. $100,000)
- LBM percentage — premium target (e.g. 20%)
- Target market cap =
initialMarketCap × (1 + LBM%) - Token price =
targetMarketCap / totalTokenSupply - Cost to buy X tokens =
X × tokenPrice - Fee =
cost × feePercentage / 10000(typically 2–5%)
Buy: stablecoin in → fee out to fee collector → tokens minted to buyer. Sell: tokens burned → stablecoin out (less fee) to seller. Continuous, instant liquidity until target market cap is reached.