Smart Contracts T-REX
Cómo Axia emite y controla activos tokenizados on-chain, los 4 modelos de contrato disponibles y el comportamiento de cada smart contract. Enfoque en smart contracts e integración.
1. Los 4 modelos de tokenización
Cada oferta elige un modelo, definido por dos decisiones: fungible vs NFT y regulado vs estándar.
| Modelo | Contrato | ¿Fungible? | ¿Regulado (KYC on-chain)? | Caso de uso |
|---|---|---|---|---|
| 1. NFT estándar | ERC-721 | No (1 = 1 activo) | No | Coleccionable, certificado simple |
| 2. Token estándar | ERC-20 (whitelabel) | Sí (divisible) | No | Token utilitario, cuota no regulada |
| 3. NFT regulado | AxiaCompliantERC721 | No | Sí | Certificado de inversión (1 NFT/inversor) |
| 4. Token regulado | ERC-3643 (suite T-REX) | Sí | Sí | Cuota negociable / security token |
- Estándar (1 y 2): transferencia libre, sin identidad on-chain. Simple y económico.
- Regulado (3 y 4): cada transferencia es verificada on-chain — solo carteras con identidad/KYC aprobada pueden recibir. Es lo que da exigibilidad regulatoria (ERC-3643 es el estándar reconocido para security tokens).
2. Capa de Identidad compartida (modelos 3 y 4)
Los dos modelos regulados comparten la misma infraestructura de identidad por blockchain — construida una sola vez por red. Es lo que hace posible la tokenización regulada.
Rol de cada contrato:
- ONCHAINID (ERC-734/735): la identidad on-chain del inversor. Un contrato por persona, que guarda los claims (ej.: "KYC aprobado", "país=BR") firmados por un emisor confiable.
- IdentityRegistry (IR): responde "¿está verificada esta cartera?". Vincula
cartera → ONCHAINID. - IdentityRegistryStorage (IRS): el almacenamiento de los vínculos — compartido entre todos los tokens de la chain, por lo que el inversor hace KYC on-chain una única vez y vale para todas las ofertas reguladas.
- TrustedIssuersRegistry (TIR): lista quién puede emitir claims válidos. Aquí = Axia (que aprueba el KYC off-chain y firma on-chain).
- ClaimTopicsRegistry (CTR): qué claims exige el token (ej.: KYC).
- ModularCompliance (MC): reglas conectables de transferencia (lock-up, jurisdicción, límites).
3. Comportamiento de cada smart contract
Modelo 1 — ERC-721 (NFT estándar)
- ERC-721 clásico.
transferlibre entre cualquier cartera. - Sin consulta de identidad. Sin freeze/recover.
- Comportamiento: quien tiene la clave, controla el NFT.
Modelo 2 — ERC-20 (token estándar / whitelabel)
- ERC-20 clásico, con
supplydefinido en la emisión. transfer/negociación libres. Sin KYC, sin compliance on-chain.- Comportamiento: token fungible común.
Modelo 3 — AxiaCompliantERC721 (NFT regulado)
Contrato propietario de Axia (auditable) que añade la capa ERC-3643 sobre un ERC-721. Toda movimentación pasa por un único punto de control (_update):
Funciones y comportamiento:
| Función | Quién | Comportamiento |
|---|---|---|
mint(to, tokenId, uri) | Agente Axia | Emite el NFT; revierte si to no está verificado |
transfer (usuario) | Inversor | Solo a cartera verificada; respeta freeze/pause/compliance |
setAddressFrozen(wallet, bool) | Agente | Congela/descongela una cartera |
setTokenFrozen(tokenId, bool) | Agente | Congela un NFT específico |
forcedTransfer(from, to, tokenId) | Agente | Mueve por orden judicial/corrección; ignora freeze, pero exige destino verificado |
recover(old, new, onchainId, tokenId) | Agente | Recupera NFT de cartera perdida → nueva cartera del mismo ONCHAINID |
pause()/unpause() | Agente | Pausa transferencias de usuario (mint/forced del agente continúan) |
burn(tokenId) | Agente | Quema |
Modelo 4 — ERC-3643 / suite T-REX (token regulado)
Implementación de referencia de Tokeny (open-source, auditada) del estándar ERC-3643. El Token es un ERC-20 cuyas transferencias consultan la misma IR + Compliance:
| Función | Comportamiento (vs modelo 3) |
|---|---|
mint(to, amount) | Fungible (cantidad, no tokenId); revierte si no está verificado |
transfer | Igual: solo entre verificados + compliance |
freezePartialTokens(wallet, amount) | Congela parte del saldo (granularidad que el NFT no tiene) |
setAddressFrozen | Congela la cartera entera |
forcedTransfer(from, to, amount) | Igual semántica |
recoveryAddress(lost, new, onchainId) | Recupera saldo completo a nueva cartera del mismo ONCHAINID |
pause/unpause, batch* | Pausa + operaciones en lote |
Misma capa de identidad de los modelos 3 y 4 → un inversor verificado puede recibir tanto NFT compliant como token fungible regulado, sin rehacer KYC on-chain.
4. Flujo de emisión (deploy del contrato)
La emisión es automática cuando la oferta se activa/cierra, según el modelo configurado.
5. Flujo de aporte → identidad → mint (modelos regulados)
La identidad on-chain se aprovisiona bajo demanda (lazy) en el momento del mint — el inversor no hace nada más allá del KYC normal.
Si el inversor no tiene KYC aprobado, el aprovisionamiento falla y el mint revierte — por construcción, un activo regulado nunca va a una cartera no verificada.
6. Flujo de transferencia (mercado secundario regulado)
El P2P entre inversores y el listado en exchange funcionan siempre que ambos extremos tengan KYC — que es exactamente el requisito de un security token.
7. Matriz de comportamiento (resumen)
| Capacidad | Modelo 1 ERC-721 | Modelo 2 ERC-20 | Modelo 3 NFT regulado | Modelo 4 ERC-3643 |
|---|---|---|---|---|
| Transferencia libre | ✅ | ✅ | ❌ (solo KYC) | ❌ (solo KYC) |
| Identidad on-chain (KYC) | — | — | ✅ | ✅ |
| Compliance on-chain | — | — | ✅ | ✅ |
| Congelar cartera | — | — | ✅ | ✅ |
| Congelar parcial (saldo) | — | — | n/a (NFT) | ✅ |
| Transferencia forzada (agente) | — | — | ✅ | ✅ |
| Recuperar cartera perdida | — | — | ✅ | ✅ |
| Pausar token | — | — | ✅ | ✅ |
| Fungible / divisible | ❌ | ✅ | ❌ | ✅ |
| Reconocido como security token | — | — | parcial¹ | ✅ |
¹ El NFT regulado usa el mismo mecanismo de identidad/compliance del ERC-3643 aplicado a ERC-721; el sello formal "ERC-3643" es del modelo fungible.
8. Acciones administrativas (modelos regulados)
Operadas por Axia (rol Agente en el contrato), bajo permiso + autenticación reforzada:
- Recover solo mueve activos a una cartera del mismo ONCHAINID — no es posible desviarlos a una dirección arbitraria.
- Revoke identity elimina al inversor de la IdentityRegistry de la chain → afecta a todos sus activos regulados en esa red.
9. Por qué este diseño
- Reutilización, no reinvención: el modelo 4 usa la suite T-REX de Tokeny (auditada), estándar de facto para security tokens reconocido por reguladores (ej.: VARA/ADGM). Axia no reescribe el estándar — lo integra.
- Custodia transparente: el inversor solo hace el KYC; Axia (custodial) aprovisiona la identidad on-chain y paga el gas. La experiencia es la misma que la de una app común.
- KYC on-chain único por chain: gracias al IRS compartido, el inversor se verifica una vez y puede participar de cualquier oferta regulada de esa red.
- Exigible: una transferencia irregular no se ejecuta — no depende de que el backend esté correcto/en línea. Es una garantía a nivel del contrato.
Glosario
| Término | Significado |
|---|---|
| ERC-3643 | Estándar de security token regulado (identidad + compliance on-chain) |
| T-REX | "Token for Regulated EXchanges" — implementación de referencia del ERC-3643 (Tokeny) |
| ONCHAINID | Contrato de identidad on-chain del inversor (ERC-734/735) |
| Claim | Atestación firmada (ej.: KYC aprobado) guardada en el ONCHAINID |
| Trusted Issuer | Quien puede emitir claims válidos (Axia) |
| Agente | Rol administrativo en el contrato (mint, freeze, recover…) |
| Compliance | Conjunto de reglas on-chain que validan cada transferencia |