Cada oferta tokenizada en T-Suite está respaldada por smart contracts. Para valores con permisos en cadenas EVM eso significa el estándar ERC-3643 (T-REX), en el que las comprobaciones de identidad y de cumplimiento se ejecutan dentro de la propia lógica de transferencia del token. Esta página describe el stack de contratos, cómo se liquidan on-chain las órdenes primarias, qué estándares funcionan en cada cadena y cómo encontrar la dirección de cualquier contrato.
Para saber qué significa cada estándar para un emisor o un inversionista, véase Estándares de token.
| Cadena (mainnet) | ERC-3643 (T-REX) | ERC-20 | ERC-721 |
|---|---|---|---|
| Base | Activo | Activo | Activo |
| Ethereum | Activo (desde el 21 de julio de 2026) | Activo (desde el 8 de septiembre de 2026) | — |
| Polygon | Activo | — | — |
| Arbitrum | Activo | — | — |
| Cardano | Tokens de metadatos CIP-20 activos |
Un token ERC-3643 solo se mueve entre wallets cuyos titulares tienen una identidad on-chain verificada, y solo cuando todas las reglas de cumplimiento lo permiten. El stack tiene cuatro capas.
1. Identidad (ONCHAINID)
| Contrato | Función |
|---|---|
| Identity | Un contrato de identidad on-chain por inversionista, vinculado a su wallet y que contiene claims firmados (por ejemplo, “KYC aprobado”) |
| Identity Factory | Despliega los contratos de identidad de los inversionistas |
| Identity Factory Gateway | Punto de entrada controlado a la Identity Factory, para que solo los desplegadores autorizados puedan crear identidades |
| Claim issuer | La parte de confianza que firma claims sobre las identidades |
2. Registros
| Contrato | Función |
|---|---|
| Identity Registry | Responde “¿está esta wallet verificada para este token?” — vincula wallets con identidades y comprueba los claims exigidos |
| Identity Registry Storage | Guarda la relación wallet → identidad → país; puede compartirse entre tokens |
| Claim Topics Registry | Enumera qué tipos de claim exige un token |
| Trusted Issuers Registry | Enumera en qué claim issuers confía un token, y para qué tipos de claim |
3. Cumplimiento
| Contrato | Función |
|---|---|
| Modular Compliance | El token lo llama en cada emisión y transferencia; consulta a cada módulo vinculado si la acción está permitida |
| Módulo Country Allow | Solo tenedores de los países listados — una whitelist estricta |
| Módulo Country Restrict | Bloquea a tenedores de los países listados |
| Módulo Max Balance | Limita cuántos tokens puede tener un mismo tenedor |
| Módulo Hold Time | Bloquea los tokens durante un periodo mínimo tras su adquisición |
| Módulo Supply Limit | Limita la emisión total del token |
El emisor elige y configura estas reglas en el Tokenization Wizard; los mismos límites también se comprueban off-chain al colocar una orden. Véase Aplicación del cumplimiento.
4. Token y factories
| Contrato | Función |
|---|---|
| Token | El security token ERC-3643 de una oferta. Su agente puede emitir, quemar, congelar y forzar transferencias, como exige el estándar para valores regulados |
| Implementation Authority | Apunta el proxy de cada token a la implementación de token aprobada |
| TREX Factory | Despliega en una sola transacción la suite completa de un token — token, registros y cumplimiento — para una oferta |
| TREX Gateway | Punto de entrada controlado a la TREX Factory, para que solo los desplegadores autorizados puedan crear suites de token |
Junto con su token, cada oferta ERC-3643 recibe un contrato Fund, desplegado mediante la Fund Factory. Contiene parámetros a nivel de oferta que leen otros contratos — el NAV más reciente, un precio opcional del activo off-chain y el estado de las distribuciones de dividendos. La Fund Factory también guarda la configuración de comisiones por oferta que Escrow lee en la liquidación.
Las órdenes primarias pagadas en USDC o USDT se liquidan mediante el contrato Escrow:
El backend comprueba que un pago on-chain coincida exactamente con la orden antes de aceptarlo. Escrow también ofrece operaciones por lotes para el agente del token — liquidación, emisión, quema, congelamiento, transferencias forzadas, registro de identidades, distribución de dividendos y redención con quema.
| Contrato | Función |
|---|---|
| Marketplace (P2P) | El libro de órdenes on-chain para la negociación secundaria entre tenedores verificados — activo en Base mainnet |
| ERC-20 Factory | Despliega tokens ERC-20 estándar para ofertas que no necesitan transferencias con permisos |
| ERC-721 Factory | Despliega colecciones ERC-721 para activos únicos |
| Agreement anchor | Registra opcionalmente on-chain el hash de un acuerdo de inversión ejecutado (en Base o Cardano), cuando está habilitado en el despliegue |
Las transacciones de Cardano las construye y firma el servicio Cardano de Libertum.
Estado: Infraestructura — aún no seleccionable
El backend soporta cuentas de plataforma XRPL, emisión de credenciales en el ledger (XRPL Credentials), autorización de trust lines y gestión de reservas, y XRPL puede aparecer como red de la Custodian Wallet donde esté habilitada. Los emisores aún no pueden elegir XRPL en el Tokenization Wizard.
No hace falta una lista de direcciones para verificar una oferta:
Como referencia, las factories principales en Base mainnet (chain ID 8453) son:
| Contrato | Dirección |
|---|---|
| TREX Factory | 0x49E08c0272841B60E3aC9203E6A14844DeaF9e70 |
| TREX Gateway | 0x63f6F6Cf13D6e4566CFba2D4d8634E87dA465C17 |
| Identity Factory | 0x182904356AAa2e1DED826F8541145d0c347a2580 |
| Identity Factory Gateway | 0x2CC97d3EF15bF878c487c07A1Db572ab881ebF5a |
| ERC-20 Factory | 0xE16feD3d4E9a6AeA6A7cA783B9CcDD3C491eAE7d |
| ERC-721 Factory | 0x22d503EF004c6E143084Ae876A60555D3fA02630 |
| Fund Factory | 0xB7104f56D355018Ab604E6e66EaDa3F719144161 |
Las direcciones son distintas en cada cadena, y una dirección de testnet nunca existe en la mainnet correspondiente. Una dirección siempre debe comprobarse en el explorador de la cadena que se está usando.