Estándares de Token y Contratos Inteligentes
Estándares de Token y Contratos Inteligentes
Los siete estándares disponibles, de un vistazo
| Estándar | Familia de cadenas | Mainnets | Cumplimiento |
|---|---|---|---|
| ERC-3643 (T-REX) | EVM | Base, Ethereum, Polygon, Arbitrum, BNB Smart Chain | Identidad on-chain y módulos de cumplimiento en cada transferencia |
| ERC-20 | EVM | Base, Ethereum | A nivel de plataforma (KYC en el marketplace); sin verificación de identidad on-chain |
| ERC-721 | EVM | Base | A nivel de plataforma; tokens únicos |
| CIP-20 | Cardano | Cardano | A nivel de plataforma; token nativo con metadatos |
| CIP-113 | Cardano | Cardano (desde el 5 de octubre de 2026) | Reglas programables on-chain y módulos de cumplimiento de Libertum |
| XRPL Issued Currency (XRPL-IC) | XRP Ledger | XRPL | Credenciales, trust lines autorizadas, clawback |
| XRPL MPT (XLS-33) | XRP Ledger | XRPL | Credenciales y titulares autorizados por el emisor; la negociación en el DEX espera a MPTokensV2 |
Los siete pueden elegirse en el Tokenization Wizard. Testnets: seis testnets EVM, Cardano preview y la testnet de XRPL.
1. ERC-3643 (T-REX)
Estado: Disponible en las mainnets de Base, Ethereum, Polygon, Arbitrum y BNB Smart Chain.
Nombre: Token for Regulated EXchanges. Desarrollado originalmente por Tokeny SA, hoy es un ERC.
Por qué lo usamos. ERC-3643 es el estándar de security token más maduro. Integra el cumplimiento directamente en la lógica de transferencia: cada llamada de transferencia comprueba el estado de congelación del remitente, la verificación de identidad del receptor y una cadena de módulos de cumplimiento — antes de mover un solo token. Esto es radicalmente distinto de los enfoques de “cumplimiento como papeleo”, donde un backend registra las transferencias y señala las infracciones a posteriori.
La suite de contratos. Un despliegue T-REX es una suite de seis contratos base más N módulos de cumplimiento:
- Token — el contrato de token compatible con ERC-20, con la función
transfersobrescrita para aplicar el cumplimiento. - Identity Registry — asocia direcciones de wallet con contratos de identidad y hace seguimiento del estado de los claims.
- Identity Registry Storage — la capa de datos de identidad; permite que varios tokens compartan un mismo registro de identidad (ahorro de gas).
- Trusted Issuers Registry — la lista de emisores de claims aprobados (proveedores de KYC, verificadores de acreditación).
- Claim Topics Registry — la lista de claim topics válidos para este token (p. ej. “is-KYC-verified”, “country”, “is-accredited”).
- Modular Compliance — el controlador de reglas; encadena los módulos de cumplimiento que cada transferencia debe superar.
Más los módulos de cumplimiento desplegados: Country Allow, Country Restrict, Supply Limit, Max Balance, Hold Time.
Modelo de permisos.
- Token Owner — puede cambiar la configuración de cumplimiento, cambiar el registro de identidad y transferir la propiedad; debería ser una hardware wallet o un multi-sig en manos del emisor.
- Agents — pueden acuñar, quemar, pausar, reanudar, congelar, descongelar, forzar transferencias y recuperar. Son wallets operativas, a menudo el relayer de la plataforma.
- Inversores — pueden transferir, siempre sujetos a todas las verificaciones de cumplimiento.
¿Por qué una fábrica? Desplegar seis contratos más N módulos por cada oferta es caro y propenso a errores. La TREXFactory despliega la suite completa en una sola transacción, con direcciones deterministas mediante CREATE2. Las implementaciones se comparten entre todas las suites a través de la TREX Implementation Authority; los proxies de cada suite guardan el estado de su oferta.
2. CIP-113
Estado: Disponible en Cardano mainnet desde el 5 de octubre de 2026, y en preview, sobre el núcleo canónico CIP-113 v0.0.1 de la Cardano Foundation.
Nombre: Cardano Improvement Proposal 113 — Tokens Programables.
Por qué lo construimos. El modelo UTXO de Cardano y los validadores Plutus permiten aplicar el cumplimiento con un enfoque apto para métodos formales y con comisiones por transacción sensiblemente menores que en Ethereum. CIP-113 es el análogo de ERC-3643 en Cardano: tokens programables cuyas reglas de transferencia se aplican mediante scripts on-chain.
Estado en detalle. La integración de CIP-113 de Libertum está disponible en Cardano mainnet desde el 5 de octubre de 2026, y también en preview. Funciona sobre el despliegue canónico de CIP-113 de la Cardano Foundation (el núcleo v0.0.1); Libertum no opera un núcleo propio. Los tokens se registran en el registro canónico de CIP-113, que indexan los exploradores y las wallets, y el núcleo canónico está gobernado por la autoridad de actualización de la Cardano Foundation. Use preview para ensayar una oferta antes de llevarla a mainnet.
Herramientas. Validadores Plutus compilados con Aiken. Construcción de transacciones off-chain en TypeScript sobre Node.js, con Mesh SDK para los activos nativos CIP-20. Los datos de la cadena provienen de Blockfrost. Integración de wallets CIP-30 en el frontend (por ejemplo, Eternl y Lace).
Módulos de cumplimiento de Libertum. Sobre el núcleo de CIP-113, Libertum añade sus propios módulos de cumplimiento on-chain: una lista de KYC on-chain con claim topics, listas de países permitidos / restringidos, lock-up, pausa, límites de emisión y por titular, y congelaciones parciales (por importe). El emisor puede congelar, descongelar, incautar (seize) y forzar transferencias, el equivalente en Cardano de setAddressFrozen + forcedTransfer de ERC-3643. Las actualizaciones de NAV quedan ancladas on-chain en los metadatos de transacción de Cardano (etiqueta 674).
3. CIP-20
Estado: Disponible en Cardano mainnet.
Nombre: estándar nativo multiactivo de Cardano (fungible), con metadatos de transacción CIP-20.
Por qué lo usamos. Los tokens CIP-20 usan el formato nativo de token fungible de Cardano — análogo a ERC-20, pero nativo del ledger. Sin cumplimiento programable. Se usa para ofertas cuyo cumplimiento lo aplica la plataforma fuera de la cadena en lugar de on-chain.
Disponibilidad. Operativo en Cardano mainnet y disponible en Cardano preview para pruebas.
4. ERC-20 / ERC-721
Estado: Disponible — ERC-20 en las mainnets de Base y Ethereum; ERC-721 en Base mainnet.
Formatos de token estándar de EVM. Se usan para:
- ERC-20 — tokens fungibles sin comprobación de identidad on-chain, como tokens de utilidad o de gobernanza y ofertas más sencillas.
- ERC-721 — tokenización uno a uno (una parcela inmobiliaria concreta como un único NFT, una obra de arte). La implementación propia de Libertum:
LibertumERC721, desplegada medianteERC721Factory.
Estos no incorporan cumplimiento programable como sí lo hace ERC-3643. Aun así, Libertum los controla a nivel de marketplace — un comprador debe estar verificado por KYC para recibir incluso un ERC-20 —, pero el contrato en sí no realiza ninguna comprobación de identidad on-chain.
5. Guía de selección de estándar
| Si va a emitir… | Elija |
|---|---|
| Inmuebles tokenizados, acciones, deuda o valores de cualquier tipo sobre EVM | ERC-3643 |
| Lo mismo en Cardano, con cumplimiento aplicado on-chain | CIP-113 (Cardano mainnet y preview) |
| Lo mismo en Cardano mainnet, hoy, con control de cumplimiento fuera de la cadena | CIP-20 |
| Token de utilidad / gobernanza sobre EVM | ERC-20 (Base o Ethereum) |
| Coleccionable de pieza única / activo único | ERC-721 (Base) |
| Token en el XRP Ledger, mantenido mediante trust lines | XRPL Issued Currency (XRPL mainnet) |
| Token en el XRP Ledger con el objeto nativo Multi-Purpose Token | XRPL MPT (XLS-33) (XRPL mainnet) |
| Token de liquidez con curva de bonding | Bonding Token — vista previa de B-DEX, no disponible |
Disponibilidad por cadena
| Cadena (mainnet) | ERC-3643 (T-REX) | ERC-20 | ERC-721 |
|---|---|---|---|
| Base | Disponible | Disponible | Disponible |
| Ethereum | Disponible (desde el 21 jul 2026) | Disponible (desde el 8 sep 2026) | — |
| Polygon | Disponible | — | — |
| Arbitrum | Disponible | — | — |
| BNB Smart Chain | Disponible (desde el 15 sep 2026) | — | — |
| Cadena (mainnet) | Estándares de Cardano |
|---|---|
| Cardano | Tokens CIP-20 disponibles; CIP-113 disponible (despliegue canónico de CIP-113 de la Cardano Foundation) |
| Cadena (mainnet) | Estándares de XRPL |
|---|---|
| XRP Ledger | Issued Currency (trust line) disponible; MPT (XLS-33) disponible |
- Testnets. Las seis testnets EVM — Base Sepolia, Ethereum Sepolia, Polygon Amoy, Arbitrum Sepolia, Avalanche Fuji y BNB Smart Chain Testnet — están disponibles para pruebas. Cardano preview está disponible para pruebas de CIP-20 y CIP-113.
- No disponible para tokenización: la mainnet de Avalanche.
- Mercado secundario (libro de órdenes P2P): disponible en Base mainnet; Ethereum y Cardano mainnet son los siguientes.
- Pagos primarios en cripto: en las cadenas EVM, los pagos en USDC y USDT de las órdenes primarias se liquidan al emisor a través del contrato Escrow. En el XRP Ledger, los inversores pagan en RLUSD o USDC, verificados on-ledger (ver la sección 8).
- Stablecoins aceptadas: USDC y USDT en EVM (a través de Escrow); RLUSD y USDC en el XRP Ledger. USDT no se acepta en XRPL (no existe Tether nativo en XRPL).
6. Arquitectura de smart contracts (Base Mainnet)
Todas las direcciones que siguen son públicas en la cadena Base mainnet (chain ID 8453).
Fábricas
| Fábrica | Propósito | Dirección en Mainnet |
|---|---|---|
| IdFactory | Despliega contratos de identidad por inversor | 0x182904356AAa2e1DED826F8541145d0c347a2580 |
| TREXFactory | Despliega la suite T-REX por oferta | 0x49E08c0272841B60E3aC9203E6A14844DeaF9e70 |
Ambas usan CREATE2 para obtener direcciones deterministas.
Stack base de ERC-3643 (infraestructura compartida)
| Contrato | Dirección en Mainnet |
|---|---|
| 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 |
Módulos de cumplimiento
| Módulo | Dirección en Mainnet | Propósito |
|---|---|---|
| Country Allow | 0xB8c8F298E4070594CF1B760989AEB1A110A3b31a | Permitir únicamente los países especificados |
| Country Restrict | 0xECbE2a39958abE721DdBDA3D2979ff6582CfEC72 | Bloquear los países especificados |
| Supply Limit | 0x5ceF54C69b556A8f68ed180ACa54f483aCf5Ebfd | Limitar el suministro total |
| Max Balance | 0x97B81D9943F9838eCF51fcaCD499Cac1C0B303Be | Limitar el saldo de cualquier wallet individual |
| Hold Time | 0xaa837190881da43d5cF0EFaCb04375324f9b646d | Impedir transferencias dentro de los N segundos posteriores a la acuñación |
Marketplace, Escrow y Fund
| Contrato | Proxy | Implementación | Propósito |
|---|---|---|---|
| Marketplace | 0xA1CD2B7125E44e4F68B6D103ec0Cfe7fa44609Cc | 0x80E440d4563151F493B16eD9aE4e929AA3A2CD0c | Libro de órdenes secundario P2P |
| Escrow | 0x8f8aDaD75a3795A952979D85b500baF2364BBC54 | 0xB12F634cbfCE6df8498E3881Ee03F5A36D9a2FfC | Liquida al emisor los pagos en USDC / USDT de las órdenes primarias |
| Fund Factory | 0xB7104f56D355018Ab604E6e66EaDa3F719144161 | 0x407Ed0566fDBF7E3B37ADB2c30c532D386C64646 | Fábrica de contratos de fondos |
Gateways de ERC-3643
| Contrato | Dirección en Mainnet |
|---|---|
| IdFactoryGateway | 0x2CC97d3EF15bF878c487c07A1Db572ab881ebF5a |
| TREXGateway | 0x63f6F6Cf13D6e4566CFba2D4d8634E87dA465C17 |
Los gateways añaden control de despliegue con permisos. Sin ellos, cualquiera podría desplegar una suite TREX a través de la fábrica; con ellos, solo pueden hacerlo los firmantes autorizados.
Fábricas de ERC-20 / ERC-721
| Contrato | Dirección en Mainnet |
|---|---|
| LERC20 Implementation | 0x9506416Fa04e9E2B49b3965c4bb0c2F571B87674 |
| ERC20Factory | 0xE16feD3d4E9a6AeA6A7cA783B9CcDD3C491eAE7d |
| LibertumERC721 Implementation | 0x99358D5F9614C1d85Bd0F3F08aEfEd907a001d77 |
| ERC721Factory | 0x22d503EF004c6E143084Ae876A60555D3fA02630 |
NAV Registry
| Contrato | Dirección en Mainnet |
|---|---|
| NAV Registry | 0x342Ad097C83F08cBEC5f628619FD9C345698605e |
Los emisores pueden publicar actualizaciones de NAV de sus ofertas; en Base se registran en el NAV Registry.
Bonding y Staking
Estado: Vista previa — no disponible
Los contratos de curva de bonding y de staking pertenecen a B-DEX, que es una vista previa sin operaciones reales. Ninguna oferta activa los usa, por lo que sus direcciones no se listan aquí. Consulte B-DEX.
Stablecoins en Base
| Token | Dirección | Decimales |
|---|---|---|
| USDC (nativo de Circle) | 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 | 6 |
| USDT (Tether puenteado) | 0xfde4C96c8593536E31F229EA8f37b2ADa2699bb2 | 6 |
7. Fórmula de la curva de bonding
Estado: Vista previa — no disponible
Las ofertas de Bonding Token forman parte de la vista previa de B-DEX. La pantalla Convert de la aplicación es una vista previa sin operaciones reales, y no hay ninguna oferta con curva de bonding activa. La fórmula siguiente describe el diseño:
- Capitalización de mercado inicial — se fija en el despliegue (p. ej. $100,000)
- Porcentaje de prima — objetivo de prima (p. ej. 20%)
- Capitalización de mercado objetivo =
initialMarketCap × (1 + premium%) - Precio del token =
targetMarketCap / totalTokenSupply - Coste de comprar X tokens =
X × tokenPrice - Comisión =
cost × feePercentage / 10000
Compra: entra stablecoin → sale la comisión hacia el recolector de comisiones → se acuñan tokens para el comprador. Venta: se queman los tokens → sale stablecoin (menos la comisión) hacia el vendedor.
8. XRPL (XRP Ledger)
Estado: Disponible en XRPL mainnet, y seleccionable en el Tokenization Wizard.
Los emisores pueden elegir uno de dos tipos de token en XRPL:
- XRPL Issued Currency — el token clásico basado en trust lines. La trust line de un titular hacia el token debe autorizarse antes de que pueda recibirlo.
- XRPL MPT (XLS-33) — el objeto nativo Multi-Purpose Token del ledger. Las ofertas MPT están disponibles; la negociación de MPT en el DEX espera a la enmienda MPTokensV2 de XRPL.
Pagos y desembolsos.
- Los inversores pagan las ofertas de XRPL en RLUSD o USDC, verificados on-ledger, ya sea desde su propia wallet XRPL (usando el destination tag que se muestra en el checkout) o desde su saldo de custodia. USDT no se acepta en XRPL (no existe Tether nativo en XRPL).
- Algunas ofertas XRPL Issued Currency se liquidan de forma atómica (entrega contra pago): el pago y los tokens se mueven en la misma transacción del ledger.
- Los pagos de reembolsos y las distribuciones en XRPL se abonan en RLUSD o USDC.
- A los inversores nunca se les cobra gas por las transacciones en XRPL.
Infraestructura de soporte.
- Cuentas de plataforma — cuentas XRPL operadas por Libertum que usa la plataforma.
- Credenciales — emisión de credenciales on-ledger mediante XRPL Credentials, de modo que la verificación de un titular pueda representarse en el ledger.
- Incorporación de titulares — cada oferta tiene su propia cuenta emisora, creada de modo que solo los titulares autorizados pueden recibir el token. Antes de la primera unidad de un titular, la plataforma le emite una credencial, el titular abre la trust line (o la tenencia MPT) y el emisor la autoriza. Un Permissioned Domain creado en el despliegue limita la negociación secundaria a los titulares con credencial.
- Token Import — las monedas emitidas y los MPT de XRPL existentes pueden importarse en modo de solo lectura (cap table e historial).
- Gestión de reservas — las cuentas XRPL deben mantener una reserva en XRP, que aumenta con cada objeto (como una trust line) que posee la cuenta; la plataforma gestiona estas reservas.
XRPL también puede aparecer como red de la Custodian Wallet donde esté habilitada para un despliegue.
9. Certificados de contratos inteligentes
Cada oferta desplegada en T-Suite —en EVM (ERC-3643, ERC-20, ERC-721), Cardano (CIP-113) y XRPL (issued currencies y MPT)— se comprueba automáticamente on-chain y recibe un Smart Contract Certificate firmado por Libertum, que cualquier persona puede verificar públicamente. Los tokens importados se certifican “tal como se observan — no desplegados por Libertum”. Consulte Cumplimiento §11 para saber qué cubre el certificado, cómo verificarlo y qué no es.