Aplicación del Cumplimiento

Libertum aplica las restricciones de cumplimiento en el código, no solo en la documentación. Este capítulo recorre esa cadena de extremo a extremo.

1. El proceso de KYC

El inversor hace clic en "Completar KYC"
    ↓
Frontend → backend → se emite un token de acceso de SumSub (limitado al proyecto, de un solo uso)
    ↓
El iframe de SumSub se carga en el navegador
    ↓
El inversor envía documento + selfie + (documentos de la jurisdicción)
    ↓
SumSub procesa la solicitud (revisión automática + manual)
    ↓
Webhook → backend → kycStatus = IN_PROGRESS
    ↓
Webhook → backend → kycStatus = APPROVED o REJECTED
    ↓
Con APPROVED, la plataforma registra al inversor en el contrato IdentityRegistry

(a través del relayer, contra la infraestructura de identidad de la oferta)

Un KYC aprobado habilita la posibilidad de colocar órdenes en el mercado primario, pero no autoriza por sí solo operaciones en ninguna oferta específica: el siguiente paso es la inclusión de la wallet en la whitelist.

2. Control por whitelist

Incluso con el KYC en estado APPROVED:

1. El inversor conecta una wallet.
2. La plataforma crea una solicitud de whitelist vinculada a {identidad del inversor, dirección de la wallet, oferta}.
3. Se envía un correo al agente de transferencia del emisor: se requiere revisión.
4. El agente de transferencia abre el portal Transfer Agent → Wallet Whitelist → revisa la solicitud.
5. El agente de transferencia aprueba o rechaza.
6. Si aprueba: la plataforma llama al IdentityRegistry de la oferta para registrar la wallet. El inversor ya es elegible para recibir tokens de esa oferta.

3. Validación de transferencias on-chain

Cuando un inversor (o un agente en su nombre) llama a transfer(to, amount) sobre un Token ERC-3643:

1. ¿El emisor de la transferencia está congelado? → revierte si es así.

2. ¿Tiene saldo no congelado suficiente? → se verifica con freezePartialTokens.

3. ¿El receptor está en el IdentityRegistry? → revierte si no lo está.

4. Para cada módulo de cumplimiento habilitado en Modular Compliance:

   • Country Allow: ¿el claim de país del receptor está en la lista permitida?

   • Country Restrict: ¿el claim de país del receptor NO está en la lista bloqueada?

   • Supply Limit: ¿suministro total + (monto acuñado, si es una emisión) ≤ tope?

   • Max Balance: ¿el saldo resultante del receptor ≤ tope?

   • Hold Time: ¿los tokens que se mueven superan el período de retención?

5. Si todo pasa → se ejecuta la transferencia y se emite el evento Transfer.

6. Si algo falla → revierte.

Todo esto ocurre antes de que se mueva token alguno. No existe una verificación de cumplimiento posterior al hecho: la propia blockchain rechaza las transferencias no conformes.

4. La excepción de transferencia forzada

forcedTransfer(from, to, amount) omite el paso 1 (emisor congelado) y el paso 2 (saldo no congelado suficiente), de modo que un agente puede mover tokens desde una wallet congelada o parcialmente congelada en escenarios legítimos de cumplimiento. Los pasos 3 y 4 se siguen aplicando: el receptor debe estar verificado y todos los módulos de cumplimiento deben seguir aprobando la operación. Esa es la salvaguarda crítica: una transferencia forzada nunca puede depositar tokens en una wallet no conforme.

recoveryAddress(lostWallet, newWallet, identity) es similar, pero ejecuta la actualización del IdentityRegistry de forma atómica junto con la transferencia, revinculando la nueva wallet a la misma identidad en una sola operación.

5. Dónde vive el registro de auditoría

Cada acción de cumplimiento genera múltiples registros de auditoría:

• Evento on-chain (inmutable). Ejemplos: Transfer, AddressFrozen, AddressUnfrozen, TokensFrozen, RecoveryAddress.
• Registro off-chain en base de datos con actor, marca de tiempo, decisión y motivo.
• Transfer Journal del emisor — la vista de interfaz que combina ambas fuentes.
• Historial de Transacciones del inversor — el mismo conjunto de datos, en la porción visible para el inversor.
• Log de webhooks de SumSub — cada decisión de KYC queda archivada.

Los auditores externos obtienen el panorama completo combinando las exportaciones off-chain con la indexación de eventos on-chain: ambas vistas coinciden porque el indexador de eventos escribe en la base de datos únicamente cuando el evento on-chain ha sido observado y confirmado.

6. Lo que Libertum NO hace

• Libertum es un proveedor de tecnología, no un broker-dealer. Las obligaciones de derecho de valores (registro, análisis de exenciones, contenido del prospecto, advertencias específicas por jurisdicción) recaen en el emisor y sus asesores legales.
• No brinda asesoría fiscal automatizada. El módulo Statements & Tax genera estados de cuenta de transacciones; la clasificación fiscal y la presentación de declaraciones siguen siendo responsabilidad del inversor.
• No custodia directamente el efectivo de los inversores fuera de los intermediarios de los rieles de pago (Stripe, transferencias bancarias a cuentas del emisor y escrow de stablecoin on-chain).