Fase 6: programador descentralizado y EigenLayer
20 de abril de 2026: la Fase 6 es la fase en la que explícitamente no construimos algo, salvo que un requisito real nos obligue. El restaking de EigenLayer es potente, pero no es un hogar de uso general para «un sistema de pagos». Este artículo explica qué nos daría un AVS, cuándo merece la pena construirlo y por qué Chainlink + NestJS bastan para casi todo lo que necesitamos.
En resumen
- EigenLayer es restaking + atestaciones penalizables de operadores de ETH. No es una cadena, ni una plataforma de contratos, ni una solución de custodia.
- Dos sitios donde podría ayudar a OrcaRail: un AVS de keepers para un
charge()descentralizado y un AVS de atestación de puentes para la liquidación entre cadenas. - Aplazaremos la construcción salvo que un cliente o un requisito de cumplimiento exija una disponibilidad descentralizada más allá de lo que nos dan Chainlink Automation + NestJS.
- Si alguna vez construimos uno, partiremos de las plantillas de Othentic / Eigen Foundation, no desde cero.
Qué te da realmente EigenLayer
Un AVS (Actively Validated Service) es una red de operadores que ejecuta un cálculo off-chain cuyas atestaciones se publican on-chain con seguridad criptoeconómica procedente de ETH en restaking. El mal comportamiento se penaliza (slashing).
Lo que aporta:
- Disponibilidad descentralizada: una tarea se ejecuta aunque una de las partes (OrcaRail) se desconecte.
- Corrección penalizable: una atestación incorrecta hace perder el stake del operador.
- Seguridad económica de ETH: heredas una parte del stake de los validadores de Ethereum en lugar de arrancar con tu propio token.
Lo que no aporta:
- Una plataforma de smart contracts. Los contratos se siguen desplegando en Ethereum / L2.
- Custodia. EigenLayer no te guarda USDC.
- Soporte nativo para Solana o Bitcoin. Existen puentes entre cadenas, y añaden complejidad y confianza.
- Un programador de uso general. Sigues definiendo tú la tarea off-chain y la verificación on-chain.
Dónde podría ayudar un AVS a OrcaRail
1. AVS de keepers (charge() descentralizado)
Hoy y hasta la Fase 3, el panorama de keepers es:
- Programador de NestJS (principal)
- Chainlink Automation o Gelato (respaldo)
Eso nos da redundancia doble. Un AVS de keepers nos daría redundancia N con disponibilidad penalizable: los operadores atestiguan «estos ID vencían y llamé a charge», y saltarse un cobro vencido es una falta penalizable.
Cuándo merece la pena:
- Cuando tengamos un cliente cuyo contrato prohíba depender de una sola parte en nuestra infraestructura.
- Cuando el cumplimiento normativo lo pida explícitamente (algo raro hoy).
Cuándo no merece la pena:
- Cuando la fiabilidad marginal frente a Chainlink es pequeña y el coste de ingeniería son meses.
2. AVS de atestación de puentes (sustituto de Relay)
Nuestra liquidación entre cadenas usa hoy Relay (consulta api/src/withdrawals/services/bridge). Relay requiere confianza. Un AVS podría atestiguar «fondos observados en la cadena X, liberar en la cadena Y» con seguridad penalizable, con una forma parecida a Hyperlane ISM con EigenLayer u Omni.
Cuándo merece la pena:
- Cuando Relay introduzca condiciones o un rendimiento que no podamos aceptar.
- Cuando la plataforma procese suficiente volumen entre cadenas como para que el riesgo del puente sea relevante.
3. Oráculo de fraude / cumplimiento
«¿Está sancionada esta wallet?», «¿se entregó la mercancía?»: las comprobaciones de políticas que hoy están en el camino de webhooks de NestJS podrían convertirse en atestaciones de un AVS. Uso de nicho; solo es útil si la plataforma asume una responsabilidad explícita de políticas on-chain.
Por qué aplazamos la construcción
- Chainlink Automation + NestJS tiene un coste de ingeniería de ~0. Un AVS de keepers son meses.
- Construir un AVS significa operar operadores (o coordinar a otros para que lo hagan) y mantener condiciones de slashing. Es una carga operativa comparable a operar nuestra propia flota de nodos blockchain.
- La mejora de seguridad solo es significativa cuando ya tenemos redundancia doble. Aún no la tenemos (llega en la Fase 3). Es decir: solo cuando la Fase 3 sea estable un AVS de keepers pasa a ser candidato.
- Incluso con un alcance conservador, un AVS tendrá sus propias consideraciones de custodia (ETH en restaking, economía de compensación de operadores).
Registro de decisiones
Mantendremos un registro público de decisiones en /docs/non-custodial/eigenlayer-evaluation con la recomendación actual y los disparadores que la cambiarían. Recomendación actual: aplazar.
Disparadores que reabrirían la discusión:
- Una conversación comercial bloqueada explícitamente por el riesgo de un «keeper de una sola parte».
- Un marco regulatorio que reconozca la disponibilidad respaldada por un AVS como control aceptable.
- Un deterioro significativo del precio o la disponibilidad de Chainlink Automation en nuestras cadenas más usadas.
- Una alianza en la que podamos reutilizar el AVS de keepers de otro con un coste operativo casi nulo.
Si lo construimos
- Partir de una plantilla. Othentic y Eigen Foundation publican plantillas para AVS de atestación de tareas. No implementaremos el slashing a mano.
- Mantener sin cambios el punto de entrada on-chain.
SubscriptionHub.charge(ids[])sigue siendo público y sin permisos. El AVS es simplemente un llamante más junto a NestJS y Chainlink. - No introducir nuevos tokens ni mecánicas de staking para nuestro propio volumen. A los operadores se les paga en ETH con el presupuesto de gas de la plataforma; no hay token de OrcaRail.
- Auditarlo. Incluso un AVS basado en una plantilla necesita una auditoría.
Lista de estado
- Página del registro de decisiones publicada
- Revisión trimestral de los disparadores
- Sandbox de prueba de concepto (no producción) si se activa un disparador
Qué sigue
La fase final elimina los caminos de código de custodia que sustituyeron las Fases 1 a 5: Fase 7.
Documentación de referencia: Estado de la Fase 6 · Evaluación de EigenLayer · Estrategia de keepers