Smart Contracts
Smart Contracts
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 inversor, véase Estándares de token.
Matriz de cadenas
| 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 | — | — |
| BNB Smart Chain | Activo | — | — |
| Cardano | Tokens de metadatos CIP-20 y tokens programables CIP-113 activos | ||
| XRP Ledger | Tokens XRPL Issued Currency (trust line) y MPT (XLS-33) activos |
- Testnets: Base Sepolia, Ethereum Sepolia, Polygon Amoy, Arbitrum Sepolia, Avalanche Fuji y BNB Smart Chain Testnet están disponibles para pruebas. Véase Entornos y redes.
- No activa para tokenización: la mainnet de Avalanche.
- CIP-113 está activo en Cardano mainnet (desde el 5 de octubre de 2026) y preview, sobre el núcleo canónico CIP-113 v0.0.1 de la Cardano Foundation.
- Mercado secundario (P2P): activo en Base mainnet; Ethereum y Cardano mainnet son los siguientes.
El stack ERC-3643
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 inversor, vinculado a su wallet y que contiene claims firmados (por ejemplo, “KYC aprobado”) |
| Identity Factory | Despliega los contratos de identidad de los inversores |
| 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 |
Contrato Fund
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.
Liquidación vía Escrow
Las órdenes primarias pagadas en USDC o USDT se liquidan mediante el contrato Escrow:
- Depósito. La wallet del inversor aprueba la stablecoin y llama a Escrow para registrar la orden — oferta, importe, número de tokens. Escrow comprueba que el inversor esté verificado en el Identity Registry del token, que el token haya sido desplegado por la factory de Libertum y que la stablecoin esté soportada. Los fondos permanecen en la wallet del inversor, bajo la aprobación, hasta la liquidación.
- Liquidación. La wallet agente del emisor liquida la orden. En una sola transacción, Escrow transfiere el importe neto al emisor, la comisión de la plataforma a las wallets de comisiones de Libertum, y emite los tokens al inversor. El pago y la entrega ocurren juntos o no ocurren. Una comisión cobrada on-chain de esta forma se registra como ya pagada y se descuenta en la factura mensual de Libertum del emisor, por lo que nunca se cobra dos veces.
- Cancelación o rechazo. Antes de la liquidación, el inversor puede cancelar su orden, o el emisor puede rechazarla. No se emiten tokens y no se mueven fondos.
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.
Otros contratos EVM
| 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 |
Cardano
Las transacciones de Cardano las construye y firma el servicio Cardano de Libertum.
- CIP-20 (mainnet, activo). Tokens nativos de Cardano con metadatos de transacción. El cumplimiento lo aplica la plataforma off-chain.
- CIP-113 (mainnet y preview, activo). Tokens programables y regulados cuyas reglas de transferencia se aplican on-chain. Los tokens se registran en el registro canónico de CIP-113 de la Cardano Foundation, y el núcleo canónico está gobernado por la autoridad de actualización de la Cardano Foundation.
XRPL
Estado: Activo en XRPL mainnet, y seleccionable en el Tokenization Wizard.
- XRPL Issued Currency — tokens basados en trust lines; la trust line de un tenedor debe autorizarse antes de que pueda recibir el token. Algunas ofertas se liquidan de forma atómica (entrega contra pago).
- XRPL MPT (XLS-33) — Multi-Purpose Tokens nativos. La negociación de MPT en el DEX espera a la enmienda MPTokensV2 de XRPL.
- Los pagos se hacen en RLUSD o USDC, verificados en el ledger (USDT no se acepta en XRPL — allí no existe Tether nativo). A los inversores nunca se les cobra gas por las transacciones en XRPL.
El backend también gestiona las cuentas de plataforma XRPL, la emisión de credenciales en el ledger (XRPL Credentials) y las reservas, y XRPL puede aparecer como red de la Custodian Wallet donde esté habilitada.
Certificados de contratos inteligentes
Cada oferta desplegada en T-Suite —EVM, Cardano CIP-113 y XRPL— se comprueba automáticamente on-chain y recibe un Smart Contract Certificate firmado (Ed25519, con su huella anclada en la propia cadena de la oferta), que cualquier persona puede verificar en https://tsuitenew.libertum.io/verify/NUMERO-DE-CERTIFICADO. Consulte Cumplimiento §11 para saber qué cubre y qué no es.
Cómo encontrar las direcciones de los contratos
No hace falta una lista de direcciones para verificar una oferta:
- En la página de la oferta. Una oferta desplegada tiene una sección Topología de Confianza que enumera Este token (el contrato del token y su transacción de despliegue) y los contratos del Protocolo subyacente de los que depende — factories, registros y módulos de cumplimiento para esa cadena y ese estándar. Cada fila muestra la dirección, un botón para copiarla y un enlace al explorador de bloques.
- En el explorador de bloques. Desde el token se puede seguir su Identity Registry, su Modular Compliance y los módulos vinculados, y leer su configuración directamente.
- Transacciones. Las liquidaciones de órdenes, las transferencias y las actualizaciones de NAV son transacciones normales en la cadena de la oferta, visibles en el explorador.
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.