Estándares de Token y Contratos Inteligentes
Estándares de Token y Contratos Inteligentes
1. ERC-3643 (T-REX)
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; los proxies de cada suite guardan el estado de su oferta. Actualizable mediante UUPS.
2. CIP-113
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 Plutus a nivel de protocolo.
Estado. Operativo hoy en la testnet Cardano Preview. No está en Cardano Mainnet hasta que lo apruebe una auditoría de seguridad externa (objetivo: Q3 2026).
Herramientas. Validadores Plutus compilados con Aiken. Construcción de transacciones off-chain con Mesh SDK (TypeScript) y cclib-cardano (Java, para la ruta más pesada del indexador). Integración de wallets CIP-30 en el frontend (Eternl, Lace).
Módulo de cumplimiento de referencia: freeze-and-seize. El primer subestándar de cumplimiento implementado es freeze-and-seize, el equivalente en Cardano de setAddressFrozen + forcedTransfer de ERC-3643. Otros cuatro subestándares están en preparación para auditoría: CountryAllow, CountryRestrict, MaxBalance, HoldTime. Una vez auditados, CIP-113 alcanzará paridad funcional con ERC-3643 en Cardano Mainnet.
3. CIP-20
Nombre: estándar nativo multiactivo de Cardano (fungible).
Por qué lo usamos. CIP-20 es el formato estándar de token fungible de Cardano — análogo a ERC-20, pero nativo del ledger. Sin cumplimiento programable. Se usa para tokens de utilidad, tokens de gobernanza y ofertas cuyo cumplimiento se aplica fuera de la cadena en lugar de on-chain.
Estado. Operativo hoy en Cardano Mainnet, junto con Cardano Preview.
4. ERC-20 / ERC-721
Formatos de token estándar de EVM. Se usan para:
- ERC-20 — tokens de utilidad, de gobernanza y de staking.
- 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 vas a emitir… | Elige |
|---|---|
| Inmuebles tokenizados, acciones, deuda o valores de cualquier tipo sobre EVM | ERC-3643 |
| Lo mismo en Cardano, con disposición a esperar a la auditoría para Mainnet | CIP-113 (preview ahora, mainnet después) |
| Lo mismo en Cardano, hoy, con control de cumplimiento fuera de la cadena | CIP-20 |
| Token de utilidad / gobernanza / staking | ERC-20 |
| Coleccionable de pieza única / activo único | ERC-721 |
| Token de liquidez con curva de bonding | Bonding Token (a medida) |
6. Arquitectura de smart contracts (Base Mainnet)
Todas las direcciones que siguen son públicas en la cadena.
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. Ambas usan proxies UUPS.
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 | Custodia el stablecoin del inversor durante la suscripción primaria; libera o reembolsa |
| Fund Factory | 0xB7104f56D355018Ab604E6e66EaDa3F719144161 | 0x407Ed0566fDBF7E3B37ADB2c30c532D386C64646 | Envoltorio contable por fondo |
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 | 0x747b13BE9cCbd04F96a2952509d3D744FeEc5724 |
| LibertumERC721 Implementation | 0x27DE684DC87D526251FF3F8aDcC6bFd8Af514fE9 |
| ERC721Factory | 0x106E0236Dd14F313462701a60c3caf6490022DF9 |
Bonding y Staking
| Contrato | Dirección en Mainnet |
|---|---|
| Bonding Factory Proxy | 0x7EF73E4E6e2Bcb4bF38CFE5d14A50441F63809b9 |
| Staking Controller Proxy | 0xc2FC93B1933797548d583E81c3d07833190aC6b2 |
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
En las ofertas de Bonding Token, el precio se determina de forma mecánica:
- Capitalización de mercado inicial — se fija en el despliegue (p. ej. $100,000)
- Porcentaje LBM — objetivo de prima (p. ej. 20%)
- Capitalización de mercado objetivo =
initialMarketCap × (1 + LBM%) - Precio del token =
targetMarketCap / totalTokenSupply - Coste de comprar X tokens =
X × tokenPrice - Comisión =
cost × feePercentage / 10000(habitualmente 2–5%)
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. Liquidez continua e instantánea hasta alcanzar la capitalización de mercado objetivo.