SkyClaim

La industria aérea opera con una asimetría estructural en perjuicio del pasajero. Los derechos del consumidor frente a demoras y cancelaciones existen en marcos regulatorios (Convenio de Montreal, Regulación CE 261/2004 en Europa, normativa DOT en Estados Unidos, entre otros), pero ejercerlos requiere un proceso manual, lento y desgastante: presentación de reclamos, recolección de evidencia, intercambio con call centers, esperas que se extienden por meses, y en muchos casos respuestas negativas que obligan al pasajero a litigar por montos que no justifican el costo del juicio.

Las aseguradoras tradicionales ofrecen pólizas de viaje, pero presentan tres fallas estructurales:

1. Custodia centralizada de los fondos: la aseguradora controla el dinero del pool y decide cuándo paga.
2. Liquidación discrecional: cada siniestro requiere evaluación humana, lo que introduce demoras de semanas o meses y un margen amplio de rechazo.
3. Letra chica y asimetría informativa: las condiciones de pago son complejas y favorables al asegurador, no al asegurado.

El caso más documentado de esta ineficiencia es el de AXA, que en 2017 lanzó Fizzy, un producto de seguro paramétrico de vuelos sobre Ethereum, y lo discontinuó en 2019 por falta de adopción comercial. Sin embargo, el problema que motivó su creación sigue vigente y validado: el proceso manual de reclamos es costoso para el asegurador y frustrante para el asegurado. Protocolos descentralizados como Etherisc continúan operando en este vertical con tracción creciente, demostrando que la demanda existe pero que la solución comercial óptima aún no se ha consolidado.

SkyClaim es un protocolo de seguro paramétrico totalmente descentralizado para vuelos comerciales. La propuesta se sostiene en cuatro principios:

¿Por qué Ethereum y no una base de datos tradicional?

Una base de datos centralizada no resuelve este problema porque el problema mismo es la centralización. Si una empresa mantuviera la base de datos, los fondos y la lógica de pago, el usuario seguiría dependiendo de la voluntad de esa empresa para cobrar. Ethereum aporta exactamente las tres propiedades necesarias:

• Inmutabilidad del código: las reglas de pago no pueden modificarse para perjudicar al asegurado una vez vendida la póliza.
• Custodia trustless de los fondos: el smart contract sostiene el pool de reservas; ninguna persona física o jurídica puede retirarlo arbitrariamente.
• Ejecución automática verificable: el pago se dispara por la lógica del contrato cuando el oráculo confirma la condición, sin discrecionalidad.

El único punto de confianza minimizado es el oráculo de datos de vuelo, que se mitiga mediante el uso de una red descentralizada de nodos (Chainlink) con múltiples fuentes de datos agregadas por consenso.

3.1 Capa de Smart Contracts

El protocolo se compone de dos contratos principales y un set de estructuras de datos auxiliares.

enum EstadoPoliza { Activa, EnVerificacion, Liquidada, Pagada, Expirada }

struct Poliza {
    address asegurado;
    bytes32 codigoVuelo;          // ej. keccak256("AR1306-20260815")
    uint64  fechaProgramada;      // timestamp UTC
    uint128 prima;                // pagada en stablecoin (USDC)
    uint128 cobertura;            // monto a recibir si se cumple condición
    uint32  umbralDemoraMinutos;  // ej. 120
    EstadoPoliza estado;
}

mapping(uint256 => Poliza) public polizas;
mapping(address => uint256[]) public polizasDe;

Funciones principales

• contratarPoliza(codigoVuelo, fechaProgramada, cobertura): el usuario paga la prima en stablecoin. El contrato la calcula en función de la cobertura solicitada y el factor de riesgo del vuelo (puede ser fijo en una primera versión). Solo se aceptan pólizas con un margen mínimo respecto a la fecha de vuelo (anti-fraude).
• solicitarLiquidacion(idPoliza): cualquier dirección puede invocarla una vez vencido el vuelo. Dispara una request a Chainlink.
• fulfillFlightData(requestId, demoraMinutos, cancelado): callback ejecutado por el oráculo. Compara el resultado con el umbral y, si corresponde, transfiere la cobertura desde el pool a la wallet del asegurado.

Modifiers utilizados: soloAsegurado, enEstado(EstadoPoliza), dentroDeVentanaContratacion, nonReentrant. Eventos: PolizaContratada, LiquidacionSolicitada, DemoraVerificada, PolizaPagada, PolizaExpirada.

3.2 Interacción de usuario

3.3 Componentes externos

• Oráculo descentralizado: Chainlink Functions o Any API consultando agregadores de aviación (FlightAware, AviationStack, OpenSky Network). La red de nodos llega a consenso sobre el dato antes de escribirlo on-chain.
• Stablecoin: USDC o DAI para denominar primas y coberturas, evitando la volatilidad de ETH.
• Capa 2 (L2): deploy en Polygon, Base o Arbitrum para reducir costos de transacción a centavos.
• Almacenamiento descentralizado (opcional): IPFS para metadatos extendidos de pólizas, referenciados por hash en el contrato.

Lenguaje de contratos

Solidity 0.8.x

Librerías de seguridad

OpenZeppelin Contracts (ReentrancyGuard, SafeERC20, Pausable como circuit breaker opcional)

Integración con oráculo

@chainlink/contracts (ChainlinkClient, FunctionsClient)

Entorno de desarrollo

Hardhat o Foundry

Tests

Mocha/Chai o Forge, con simulación de respuestas del oráculo

Frontend

React + TypeScript, con Wagmi y RainbowKit

Comunicación con la cadena

Ethers.js v6 o Viem

Red de deploy (testnet)

Sepolia (Ethereum) o Polygon Amoy (L2)