1. Resumen Ejecutivo

Lumina Protocol es la primera infraestructura de seguro parametrico descentralizado diseñada exclusivamente para agentes de inteligencia artificial que operan en DeFi. El protocolo despliega en Base L2, liquida en USDC real (Circle) y genera yield a traves de Aave V3.

A diferencia del seguro tradicional, que requiere que un humano presente un reclamo, un comite lo revise y semanas de espera para recibir el pago, Lumina utiliza triggers matematicos verificados por oracles. Si la condicion se cumple (por ejemplo, ETH cae un 30%), el pago es instantaneo y automatico. Sin reclamos. Sin disputas. Sin esperar a humanos.

El protocolo ofrece 5 productos de seguro (BTC Catastrophe Shield, ETH Apocalypse Shield, Depeg Shield, IL Index Cover, Exploit Shield), 4 vaults de liquidez (VolatileShort, VolatileLong, StableShort, StableLong) y opera a traves de 13 contratos inteligentes desplegados en produccion. Los contratos Core (CoverRouter, PolicyManager), vaults y shields usan proxies UUPS actualizables bajo TimelockController; los contratos Oracle (LuminaOracleV2, LuminaPhalaVerifier) son NO actualizables (Ownable) y su reemplazo requiere re-despliegue.

Cada flujo de interaccion comienza de la misma forma: el humano, a traves de su agente de IA, instruye la operacion deseada. El agente ejecuta la transaccion on-chain de forma autonoma, interactuando con la API de Lumina y los contratos del protocolo sin intervencion manual.

El modelo de negocio es simple y transparente: una comision del 3% sobre la prima pagada por el asegurado, un 3% sobre el pago de siniestro, y un 3% de performance fee sobre el rendimiento positivo (ganancia) cuando los proveedores de liquidez retiran fondos de los vaults.

2. Introduccion

2.1 El Problema: DeFi sin Proteccion para Agentes Autonomos

La economia agentica crece exponencialmente. Miles de agentes de IA gestionan posiciones DeFi, tesorerias, pools de liquidez y estrategias de yield farming. Sin embargo, estos agentes operan sin ningun tipo de cobertura frente a los riesgos mas criticos del ecosistema: caidas catastroficas del mercado, depegs de stablecoins, impermanent loss severo y exploits de protocolos.

Los protocolos de seguro DeFi existentes fueron diseñados para humanos. Requieren interfaces graficas, procesos de votacion comunitaria para validar reclamos y tiempos de resolucion incompatibles con la velocidad a la que operan los agentes autonomos. Lumina resuelve este problema con un enfoque puramente programatico y parametrico.

2.2 Comparativa con Protocolos Existentes

2.3 Como Funciona Lumina

El humano, a traves de su agente de IA, define los parametros de cobertura deseados: activo a cubrir, monto, duracion y producto. El agente consulta la API de Lumina para obtener una cotizacion precisa, incluyendo la prima calculada segun el modelo kink de utilizacion. Una vez aprobada la cotizacion, el agente ejecuta la transaccion on-chain a traves del CoverRouter.

Flujo simplificado:

El colateral se bloquea 1:1 en el vault correspondiente. Si el trigger se activa durante la vigencia de la poliza, el pago se ejecuta automaticamente. Si la poliza expira sin que el trigger se active, el colateral se libera de vuelta al vault.

3. Arquitectura del Protocolo

3.1 Modelo Kink de Utilizacion

El corazon del pricing de Lumina es un modelo de utilizacion no lineal inspirado en los modelos de tasa de interes de Aave y Compound. La prima se calcula con la siguiente formula completa extraida del codigo Solidity:

Donde:

• Coverage: monto asegurado en USDC
• P_base: tasa base anualizada del producto (ej: 15% para BCS, 20% para EAS, 2.5% para Depeg)
• RiskMult: multiplicador de riesgo por activo
• DurationDiscount: descuento por duracion larga
• M(U): multiplicador de utilizacion (modelo kink)
• Duration: duracion de la poliza en dias

Modelo Kink -- Multiplicador de Utilizacion M(U)

El punto de inflexion (kink) se ubica en U_kink = 80%. Por debajo del kink, el multiplicador crece linealmente. Por encima, crece de forma agresiva para desincentivar la sobreutilizacion.

Tabla de Multiplicadores por Nivel de Utilizacion

Este modelo garantiza que cuando la capacidad del vault esta holgada, las primas son competitivas. A medida que la utilizacion se acerca al 80%, las primas suben gradualmente. Por encima del 80%, el crecimiento es exponencial, protegiendo a los LPs de sobreexposicion.

Modelo de Inversion del Vault

Los LPs depositan USDC en los vaults de Lumina. Este USDC se deposita automaticamente en Aave V3 para generar un rendimiento base (3-5% APY). Adicionalmente, las primas de seguro pagadas por los compradores de polizas fluyen hacia el vault, incrementando el valor de las shares de los LPs.

El rendimiento total para los LPs se compone de:

• Yield base de Aave V3: 3-5% APY generado por el deposito de USDC en Aave V3
• Yield de primas de seguro: Las primas pagadas por los compradores de polizas (97% despues del fee del protocolo) se distribuyen al vault
• Total yield = Aave V3 base yield + insurance premium yield

El Modelo Kink tambien protege a los LPs: a mayor utilizacion del vault, mayores son las primas cobradas, lo que se traduce en mayor yield para los proveedores de liquidez. Esto crea un equilibrio natural donde los LPs son compensados proporcionalmente al riesgo que asumen.

3.2 Flujo de Compra de Poliza

El humano, a traves de su agente de IA, inicia la compra de cobertura. El flujo completo on-chain es:

1. Humano instruye a su agente de IA con los parametros deseados
2. Agente IA llama a la API de Lumina para obtener cotizacion
3. API calcula la prima usando el modelo kink y devuelve los parametros
4. Agente aprueba USDC al CoverRouter y ejecuta purchaseCover()
5. CoverRouter (0xd5f8678A0F2149B6342F9014CCe6d743234Ca025) valida parametros y rutea al Shield correcto
6. Shield (BCS/EAS/Depeg/IL/Exploit) valida reglas especificas del producto
7. PolicyManager (0xCCA07e06762222AA27DEd58482DeD3d9a7d0162a) registra la poliza on-chain
8. Vault bloquea colateral 1:1 para respaldar la cobertura
9. USDC se transfiere del agente al vault (prima) y se cobra el 3% de fee

3.3 Flujo del Proveedor de Liquidez (LP)

El humano, a traves de su agente de IA, deposita USDC en uno de los cuatro vaults para ganar yield:

1. Humano decide depositar en un vault y lo comunica a su agente
2. Agente aprueba USDC y llama a deposit() en el vault seleccionado
3. Vault recibe el USDC y lo deposita en Aave V3 (0xA238Dd80C259a72e81d7e4664a9801593F98d1c5)
4. El LP recibe shares soulbound (no transferibles) proporcionales a su deposito
5. Las shares acumulan yield de dos fuentes: tasa base de Aave V3 (3-5% APY) + primas de seguro
6. Para retirar, el LP inicia un periodo de cooldown (37 a 372 dias segun el vault)
7. Tras el cooldown, el LP puede ejecutar withdraw() y recibir sus USDC + yield acumulado
8. Se cobra un 3% de performance fee sobre el rendimiento positivo (ganancia) al retirar

3.4 Tabla de Arquitectura de Contratos

3.5 Colateralizacion Estricta 1:1

Cada poliza emitida en Lumina esta respaldada por colateral bloqueado 1:1 en el vault correspondiente. Esto significa que si un agente compra $50,000 de cobertura BCS, el vault bloquea exactamente $50,000 en USDC (depositados en Aave V3 como aUSDC) para garantizar el pago en caso de siniestro.

Este modelo elimina el riesgo de subcapitalizacion que afecta a otros protocolos de seguro DeFi que operan con modelos de pool compartido. Si la utilizacion del vault alcanza el 95% (U_MAX), no se aceptan nuevas polizas hasta que se libere capacidad.

El colateral bloqueado 1:1 no permanece inactivo. Se deposita automaticamente en Aave V3 donde genera rendimiento base (3-5% APY) mientras permanece disponible para cubrir siniestros. Esto significa que incluso el capital comprometido para polizas activas esta generando yield para los LPs.

4. Productos de Seguro

5. Modelo de Precios Dinamico (Kink Model)

5.1 Fundamentos

El Modelo Kink es un sistema de pricing dinamico inspirado en los modelos de tasa de interes de Aave y Compound, adaptado para seguros parametricos. Su objetivo es doble: garantizar la solvencia permanente de los vaults y crear un mercado autoequilibrado donde la oferta (liquidez de los LPs) y la demanda (compra de polizas por agentes) encuentren su equilibrio naturalmente.

A diferencia de un precio fijo, el Modelo Kink ajusta el costo de las primas en tiempo real segun la disponibilidad de capital en cada vault. Cuando hay abundante liquidez, las primas son accesibles. Cuando el capital escasea, las primas se encarecen dramaticamente, protegiendo a los LPs y atrayendo nuevo capital.

5.2 Formula de Calculo

La formula completa, extraida del contrato PremiumMath.sol:

Donde M(U) es el multiplicador de utilizacion:

Parametros on-chain (PremiumMath.sol):

Tabla de multiplicadores:

Ejemplo numerico: Un agente compra BTC Catastrophe Shield por $50,000 de cobertura, 14 dias, con U=50%:

• P_base = 1500 bps (15% anualizado)
• RiskMult = 1.0x (ETH base)
• DurationDiscount = 1.0x
• M(U) = 1 + (0.50/0.80) x 0.5 = 1.3125x
• Premium = 50,000 x 0.15 x 1.0 x 1.0 x 1.3125 x (14/365) = $377.57

Mismo escenario con U=85%:

• M(U) = 1 + 0.5 + ((0.85-0.80)/0.20) x 3.0 = 2.25x
• Premium = 50,000 x 0.15 x 1.0 x 1.0 x 2.25 x (14/365) = $647.26

5.3 Utilizacion del Vault

La utilizacion (U) se define como:

• "Capital bloqueado" = USDC reservado 1:1 para cubrir polizas vigentes (allocatedAssets en BaseVault.sol)
• "Activos totales" = aToken balance en Aave V3 + USDC libre en el vault (totalAssets() en BaseVault.sol)

Cuando un agente compra una poliza, el capital correspondiente se bloquea. Cuando la poliza expira o se ejecuta, el capital se libera.

5.4 Mecanismo de Autoequilibrio

El Modelo Kink crea un mercado que se autoequilibra mediante la escasez de capital:

Cuando la demanda de seguros es alta y los vaults tienen poca liquidez disponible:

• Las primas suben, haciendo mas caro asegurar para los agentes
• Los rendimientos de los LPs aumentan, recompensandolos por el mayor riesgo
• Nuevos LPs son atraidos por los rendimientos altos, inyectando mas capital
• La utilizacion baja, las primas se normalizan — el ciclo se repite

Cuando hay mucha liquidez y poca demanda:

• Las primas son bajas, incentivando a los agentes a comprar cobertura
• Los rendimientos LP son menores, lo que naturalmente limita el exceso de capital

5.5 Las Tres Zonas de Operacion

Zona Verde (0% a 60%): Capital abundante. Primas accesibles para agentes. Rendimiento LP moderado (Aave base + primas bajas). Condiciones ideales para comprar seguro.

Zona Amarilla (60% a 80%): Demanda creciente. Las primas comienzan a subir gradualmente. Equilibrio entre cobertura accesible y rendimientos LP crecientes. El mercado se acerca al punto de inflexion.

Zona Roja (80% a 95%): Capital escaso. Las primas se disparan exponencialmente. Alto rendimiento LP atrae nuevos depositantes. Desincentiva nuevas polizas hasta que vuelva la liquidez. El protocolo se protege activamente.

Zona Bloqueada (>95%): No se aceptan nuevas polizas. El vault se protege de insolvencia. Solo se pueden ejecutar polizas existentes y depositar nuevo capital.

5.6 Garantia de Solvencia Matematica

El modelo garantiza solvencia mediante tres mecanismos:

1. Colateralizacion 1:1: Cada poliza tiene su respaldo dedicado en USDC
2. Curva exponencial: Las primas se vuelven prohibitivas antes de alcanzar el limite, desincentivando naturalmente la sobreemision
3. Tope absoluto (95%): Rechazo automatico de nuevas polizas — es imposible que el vault acepte mas de lo que puede cubrir

5.7 Impacto en Cada Producto

Todos los productos comparten el mismo Modelo Kink (misma curva M(U)), pero difieren en su P_base y factores de riesgo. Esto significa que un producto con P_base alto (como IL Index Cover al 8.5%) sera proporcionalmente mas caro que uno con P_base bajo (como Depeg al 2.5%), pero ambos se encarecen en la misma proporcion cuando la utilizacion sube.

5.8 Estructura de Fees del Protocolo

Ejemplo completo:

1. Agente compra BCS $50,000, prima = $280.82
   • Fee protocolo: $280.82 x 3% = $8.42
   • Vault recibe: $280.82 - $8.42 = $272.40
2. Siniestro se ejecuta, payout = $40,000 (80% coverage)
   • Fee protocolo: $40,000 x 3% = $1,200
   • Agente recibe: $40,000 - $1,200 = $38,800
3. LP deposito $10,000, retira $10,500 (ganancia $500)
   • Performance fee: $500 x 3% = $15
   • LP recibe: $10,500 - $15 = $10,485
   • Si LP retira $9,800 (perdida): fee = $0

Fee receiver: 0x2b4D825417f568231e809E31B9332ED146760337

6. Vaults y Yield

6.1 Los Cuatro Vaults

Lumina opera con cuatro vaults especializados, cada uno con un periodo de cooldown diferente y productos de seguro asignados:

Los vaults con cooldowns mas largos ofrecen mayor APY estimado porque asumen mayor riesgo (polizas de mayor duracion, eventos menos frecuentes pero de mayor impacto).

6.2 Composicion del Yield

El yield que reciben los LPs proviene de dos fuentes:

1. Yield base de Aave V3 (3-5% APY): Los USDC depositados en los vaults se depositan automaticamente en Aave V3 Pool (0xA238Dd80C259a72e81d7e4664a9801593F98d1c5), generando yield pasivo en forma de aUSDC (0x4e65fE4DbA92790696d040ac24Aa414708F5c0AB).
2. Primas de seguro: Cuando un agente compra una poliza, el 97% de la prima (despues del 3% de fee del protocolo) se distribuye al vault correspondiente, incrementando el valor de las shares de los LPs.

6.3 Shares Soulbound (No Transferibles)

Las shares de los vaults de Lumina son soulbound: no pueden transferirse, venderse ni utilizarse como colateral en otros protocolos. Esta decision de diseño previene:

• La creacion de mercados secundarios de shares que podrian desestabilizar los vaults
• El uso de shares como colateral en protocolos de lending, creando riesgo sistemico
• La fragmentacion de la liquidez entre multiples holders

El LP solo puede interactuar con sus shares a traves de deposit() y withdraw() (tras el cooldown).

En futuras versiones del protocolo, se evaluara la implementacion de un mercado secundario exclusivo de Lumina donde los LPs podran negociar sus posiciones. Este mercado operaria bajo reglas controladas por el protocolo, manteniendo la estabilidad de los vaults mientras ofrece mayor flexibilidad a los participantes.

6.4 Colateral Dedicado por Poliza

Gracias a la colateralizacion 1:1, cada poliza tiene su propio respaldo dedicado en el vault. Incluso en el caso de multiples siniestros simultaneos, cada pago esta garantizado por colateral ya bloqueado. El sistema de prioridad por vault solo aplica para la asignacion de nuevas polizas, no para el pago de siniestros existentes.

7. Oracle y Verificacion

7.1 LuminaOracle

El contrato LuminaOracleV2 (0x87B576f688bE0E1d7d23A299f55b475658215105) es el componente central de verificacion de datos del protocolo. Es NO actualizable (Ownable, sin proxy UUPS). Opera con un esquema multisig N-of-M que puede expandirse segun las necesidades de descentralizacion.

Actualmente opera en modo 1-of-1 (expandible a N-of-M). El oracle verifica los feeds de Chainlink, implementa un chequeo de sequencer de 1 hora para Base L2, y valida la frescura de los datos antes de aceptarlos como input para triggers.

7.2 Tabla de Feeds de Chainlink

Los feeds de assets volatiles (ETH, BTC) tienen un staleness de 20 minutos, mientras que los feeds de stablecoins tienen un staleness de 24 horas, reflejando la menor volatilidad esperada.

7.3 Verificacion Multisig: verifyPackedMultisig

El sistema de verificacion de firmas utiliza un esquema de firmas concatenadas ordenadas por address. Cada firmante autorizado produce una firma ECDSA sobre los datos del oracle, y las firmas se concatenan en orden ascendente de address del firmante.

La funcion verifyPackedMultisig deserializa las firmas, verifica que cada una proviene de un firmante autorizado, que estan en orden correcto (para prevenir duplicados), y que se alcanza el umbral N-of-M requerido.

7.4 LuminaPhalaVerifier para Exploit Shield

El contrato LuminaPhalaVerifier (0x468b9D2E9043c80467B610bC290b698ae23adb9B) verifica el trigger secundario de Exploit Shield mediante verificacion ECDSA de firmas producidas por workers Phala autorizados sobre una lista curada por admin. Es NO actualizable (Ownable, lista de workers EOA curada por admin). NO verifica atestaciones remotas SGX/TDX on-chain. NO verifica firmas de enclaves de hardware on-chain. Lo que SI hace: ecrecover(dataHash, signature) y verifica que el address recuperado esta en _authorizedWorkers, una lista mantenida por el owner (Gnosis Safe).

Esto es critico para Exploit Shield porque los exploits pueden involucrar manipulacion de oracles. Al usar un verificador independiente, Lumina agrega una segunda capa de confirmacion, aunque la suposicion de confianza es que el admin agrega unicamente workers cuyos keys fueron verificados off-chain como originados en enclaves Phala legitimos.

8. Modelo de Negocio

8.1 Monetizacion

Lumina Protocol genera ingresos a traves de un modelo de comision dual, simple y transparente:

8.2 Fee Receiver

Todos los fees del protocolo se envian a la direccion:

Esta direccion es controlada por el TimelockController con un delay de 48 horas, lo que asegura transparencia y capacidad de auditoria.

8.3 Performance Fee en Retiros de Vault

Se cobra un 3% de performance fee unicamente sobre el rendimiento positivo (ganancia) al retirar fondos de los vaults. El fee se calcula sobre la diferencia entre el monto retirado y el cost basis (deposito original). Si no hay ganancia, no se cobra fee alguno.

Ejemplo: Un LP deposita $10,000 USDC. Tras acumular yield, retira $10,500 USDC. La ganancia es $500 ($10,500 - $10,000). El performance fee es 3% × $500 = $15. El LP recibe neto $10,485.

Esta estructura alinea los incentivos del protocolo con los de los LPs: Lumina solo cobra cuando el LP efectivamente gana dinero.

8.4 Escalabilidad del Modelo

El modelo de negocio de Lumina es inherentemente escalable:

• Mas LPs depositan en los vaults, aumentando la capacidad total de cobertura
• Mas capacidad permite emitir mas polizas y cubrir mas agentes
• Mas polizas generan mas primas, lo que incrementa el yield para los LPs
• Mayor yield atrae a mas LPs, cerrando el ciclo virtuoso

Este flywheel se refuerza con cada nuevo participante, creando un efecto de red positivo.

9. Seguridad

9.1 Smart Contracts

Los 13 contratos del protocolo han sido desarrollados con las mejores practicas de seguridad de Solidity:

• Solidity 0.8.20: Overflow/underflow checking nativo
• Patron CEI (Checks-Effects-Interactions): Todas las funciones criticas siguen este patron
• SafeERC20: Todas las transferencias de USDC utilizan la libreria SafeERC20 de OpenZeppelin
• ReentrancyGuard: Proteccion contra ataques de reentrancia en todas las funciones que manejan fondos
• UUPS Proxies: Contratos upgradeables con patron UUPS de OpenZeppelin, controlados por TimelockController
• 119 tests: Suite completa de tests unitarios y de integracion

9.2 Governance

La gobernanza del protocolo implementa un modelo de seguridad en capas:

• TimelockController (0xd0De5D53dCA2D96cdE7FAf540BA3f3a44fdB747a): Delay de 48 horas para todas las operaciones administrativas. Cualquier cambio en parametros criticos requiere un periodo de espera que permite a los LPs reaccionar.
• Gnosis Safe 1-of-1 (planned 2-of-3) (0xa17e8b7f985022BC3c607e9c4858A1C264b33cFD): Actualmente 1-of-1 signatario. Upgrade planificado para requerir al menos 2 de 3 signatarios autorizados.

9.3 API y Backend

La API que conecta a los agentes de IA con los contratos implementa:

• Rate limiting: Control de frecuencia de requests para prevenir abuso
• CORS: Configuracion estricta de origenes permitidos
• Helmet: Headers de seguridad HTTP
• NonceManager: Gestion de nonces para prevenir replay attacks y garantizar la secuencialidad de transacciones

9.4 Oracle

La seguridad del oracle se basa en tres capas:

• Multisig: Verificacion N-of-M de firmas para datos de oracle
• Precio spot de Chainlink verificado via prueba firmada EIP-712 (LuminaOracleV2): El relayer lee latestRoundData del feed de Chainlink y firma el resultado con signTypedData. NO hay computo de TWAP on-chain
• Sequencer check: Verificacion de que el sequencer de Base L2 ha estado activo durante al menos 1 hora antes de aceptar datos de oracle

9.5 Session Approval

Para compras realizadas a traves de relayers, el protocolo requiere session approval: el comprador (buyer) debe firmar un consentimiento explicito que autoriza al relayer a ejecutar la compra en su nombre. Esto previene que un relayer compre polizas no autorizadas con fondos del usuario.

9.6 Integracion OWS

Lumina integra el estandar OWS (Open Wallet Standard) para facilitar la interaccion segura entre agentes de IA y wallets. Esta integracion permite que los agentes operen con permisos granulares y revocables, sin necesidad de exponer claves privadas.

10. Datos Actuariales

10.1 BTC Catastrophe Shield / ETH Apocalypse Shield -- Expected Value para LPs

El margen del 38% refleja la naturaleza de cola gruesa del riesgo BCS/EAS: los eventos catastroficos son poco frecuentes pero severos. En años sin eventos, el margen es significativamente mayor. En años con multiples eventos, el margen puede ser negativo.

10.2 Depeg Shield -- Expected Value para LPs

Depeg Shield presenta el mayor volumen de primas y un margen saludable del 62%. Los eventos de depeg son raros (1-2 veces por decada para stablecoins mayores) pero cuando ocurren son sistemicos.

10.3 IL Index Cover -- Expected Value para LPs

El modelo de payout proporcional de IL Index Cover y el deducible del 2% crean un margen favorable. La mayoria de las polizas expiran con IL inferior al 2%, generando primas sin siniestro.

10.4 Exploit Shield -- Expected Value para LPs

Exploit Shield tiene el menor volumen absoluto pero el mayor margen porcentual. El dual trigger, el waiting period de 14 dias y el cap de $50,000 por wallet limitan significativamente la exposicion.

10.5 Peor Escenario Sistemico

Un escenario sistemico (crash de mercado + depeg + exploit simultaneos) podria generar una perdida del 21.9% del TVL. La recuperacion se proyecta en 10-12 meses a traves de la acumulacion de primas. Este escenario es extremadamente improbable dado los grupos de correlacion independientes entre productos.

11. Riesgos

12. Roadmap

13. Marco Legal

13.1 Estructura del Protocolo

Lumina Protocol opera como un protocolo descentralizado desplegado en Base L2 (Chain 8453). Los contratos inteligentes son inmutables en su logica core, con capacidad de upgrade a traves de proxies UUPS (para contratos core, vaults y shields) controlados por un TimelockController con delay de 48 horas y una Gnosis Safe 1-of-1 (planned 2-of-3). Los contratos Oracle (LuminaOracleV2, LuminaPhalaVerifier) son NO actualizables (Ownable).

El protocolo no custodia fondos de usuarios. Los depositos de LPs se mantienen en Aave V3, y los pagos de siniestros se ejecutan directamente desde los vaults a las wallets de los agentes. El protocolo solo cobra fees como intermediario.

13.2 Naturaleza del Producto

Lumina ofrece productos de proteccion parametrica basados en triggers matematicos verificables on-chain. Los productos de Lumina no constituyen seguros en el sentido regulatorio tradicional: no requieren licencia de aseguradora, no involucran evaluacion subjetiva de reclamos y no dependen de procesos judiciales para la resolucion de disputas.

Los pagos son automaticos, deterministas y verificables por cualquier tercero que inspeccione la blockchain.

13.3 Riesgos Regulatorios

El panorama regulatorio de DeFi continua evolucionando. Existen riesgos de que jurisdicciones futuras clasifiquen los productos parametricos on-chain como productos de seguros regulados, lo que podria requerir licencias, cumplimiento normativo adicional o restricciones geograficas.

El equipo monitorea activamente los desarrollos regulatorios en las principales jurisdicciones (EE.UU., UE, Reino Unido, Singapur) y esta preparado para adaptar la estructura del protocolo segun sea necesario.

13.4 Disclaimer

14. Direcciones de Produccion

Red: Base L2 (Chain 8453)  |  Fecha de despliegue: 29 de marzo de 2026

Governance

Core

Vaults

Shields (Productos)

Contratos Externos

Claves Operativas

Chainlink Feeds

15. Grupos de Correlacion

Los productos de Lumina estan diseñados para cubrir riesgos con baja correlacion entre si, limitando la posibilidad de siniestros simultaneos:

Analisis de correlacion

• BCS, EAS e IL Index Cover tienen correlacion alta: un crash de mercado activa BCS/EAS y simultaneamente genera IL significativo. Por esta razon, comparten el vault VolatileShort.
• Depeg Shield tiene correlacion baja con los productos de volatilidad. Un depeg de stablecoin puede ocurrir independientemente de la direccion del mercado (ej: crisis bancaria, riesgo regulatorio de Tether).
• Exploit Shield tiene correlacion baja con todos los demas productos. Los hacks de protocolos son eventos idiosincraticos que no dependen de condiciones de mercado.
• Evento sistemico (todos los triggers simultaneos) es el escenario de peor caso. La segregacion de vaults por tipo de riesgo y el sistema de waterfall mitigan parcialmente este riesgo. La perdida maxima estimada es de -21.9% del TVL ($438K de $2M).

16. API y Agentes

16.1 Descripcion General

El humano, a traves de su agente de IA, interactua con Lumina Protocol a traves de una API REST que expone las funcionalidades core del protocolo. La API permite cotizar, comprar polizas, consultar estado y verificar triggers sin necesidad de interactuar directamente con los contratos.

Endpoints principales:

16.2 Referencia SKILL

La documentacion completa de la API y las instrucciones para configurar agentes se encuentran en el archivo SKILL del protocolo: LUMINA-SKILL.txt (Version 3.0, Marzo 2026).

El archivo SKILL contiene:

• Descripcion detallada de cada producto con parametros, ejemplos y tablas de pricing
• Instrucciones paso a paso para que un agente compre cobertura
• Instrucciones para depositar y retirar como LP
• Parametros de cada vault y sus APYs estimados
• Informacion de fees y como planificar coberturas considerando el fee del 3%

16.3 Flujo de Setup de un Agente

1. El humano configura su agente con la URL de la API de Lumina y las credenciales de su wallet
2. El agente consulta /quote con los parametros deseados (producto, activo, monto, duracion)
3. El agente evalua la cotizacion y decide si procede
4. El agente aprueba USDC al CoverRouter via approve()
5. El agente ejecuta /purchase o llama directamente a CoverRouter.purchaseCover()
6. La poliza queda registrada on-chain en el PolicyManager
7. El agente puede monitorear el estado de su poliza via /policy/:id

17. Conclusion

Lumina Protocol representa la primera infraestructura de seguro parametrico diseñada exclusivamente para la economia agentica. Al combinar triggers matematicos verificables, oracles descentralizados, colateralizacion estricta 1:1 y yield generado a traves de Aave V3, el protocolo ofrece una solucion completa para los riesgos criticos que enfrentan los agentes de IA en DeFi.

Fortalezas principales del protocolo

• Parametrico puro: Sin reclamos subjetivos, sin votaciones, sin esperas. El trigger se activa y el pago es inmediato.
• Diseñado para agentes: API programatica, session approval para relayers, integracion OWS, documentacion SKILL.
• Colateral 1:1: Cada poliza esta respaldada al 100% por USDC real bloqueado en el vault. Sin riesgo de subcapitalizacion.
• Yield real: Los LPs ganan yield compuesto de Aave V3 + primas de seguro, con APYs estimados del 3-21%.
• Seguridad en capas: Solidity 0.8.20, ReentrancyGuard, CEI, TimelockController 48h, Gnosis Safe 1-of-1 (planned 2-of-3), pruebas EIP-712, sequencer check.
• Modelo de negocio transparente: 3% premium + 3% payout. Sin fees ocultos. Performance fee del 3% sobre rendimiento positivo en retiros de vault.

Vision

Lumina aspira a convertirse en la infraestructura de seguro estandar para la economia agentica. A medida que millones de agentes de IA gestionen billones de dolares en activos DeFi, la necesidad de cobertura programatica, instantanea y confiable sera tan fundamental como lo es hoy la infraestructura de lending y trading.

Con el roadmap hacia productos adicionales (Gas Spike, Slippage, Bridge Shield), un marketplace de polizas NFT, token nativo y gobernanza DAO, Lumina se posiciona como el protocolo de referencia en seguro descentralizado para la nueva generacion de participantes autonomos del ecosistema DeFi.