La hoja de ruta no custodial de OrcaRail
20 de abril de 2026: hoy publicamos la hoja de ruta completa para llevar OrcaRail de su actual modelo custodial de barrido (generamos una dirección de depósito por enlace de pago y luego barremos y repartimos los fondos) a un modelo no custodial de smart contracts (los fondos llegan a un contrato por enlace que reparte y liquida de forma atómica, y las suscripciones cobran de un allowance controlado por el pagador).
Este artículo es el índice. Cada fase tiene su propio artículo en profundidad y una página de documentación viva, para que puedas enlazar directamente a la parte que te interesa.
Por qué lo hacemos
El flujo actual funciona, pero tiene un problema estructural sencillo: entre el depósito y la liquidación, OrcaRail retiene los fondos. Es así aunque nunca guardemos los saldos operativos de los comercios: el momento en tránsito entre «el pagador envió» y «el comercio recibió» es custodial. Eliminar ese momento es una mejora en seguridad, cumplimiento y fiabilidad.
En concreto, el camino heredado es así:
El objetivo es:
Los fondos nunca pasan por una wallet que controlemos. Los repartos ocurren on-chain. Las suscripciones cobran de un allowance que el pagador puede revocar en cualquier momento.
Qué cambia, en una página
| Área | Antes | Después |
|---|---|---|
| Direcciones de enlaces de pago | EOA derivada de HD o smart account de Alchemy por enlace | CREATE2 determinista en EVM; PDA en Solana, sin material de claves guardado por OrcaRail |
| Liquidación | Transacción de barrido tras la observación | Reparto atómico dentro del receptor en la transacción de pago |
| Suscripciones | Cobro custodial desde una wallet financiada por el comercio | El pagador firma approve de ERC-20 o delegación SPL; el keeper llama a charge(id) |
| Keeper | Un único programador en NestJS | NestJS principal + Chainlink Automation o Gelato de respaldo (+ EigenLayer opcional) |
| Entre cadenas | Puente de Relay ejecutado por el keeper | La misma ruta de Relay, pero como llamada on-chain desde un receptor no custodial |
| Bitcoin | Hot wallet con xpub guardada en el servidor | Multisig taproot 2 de 2 por enlace (comercio + plataforma) con reembolsos prefirmados |
La hoja de ruta
Cada fase es autónoma y se puede publicar por separado. Las primeras fases eliminan la custodia en los volúmenes más grandes (pagos y suscripciones en EVM) y las últimas abordan las cadenas más difíciles y la descentralización opcional.
- Fase 0: diseñar una pila de pagos no custodial: congelación de la especificación de comisiones y repartos, selección de cadenas, proveedor de auditoría, multisig de despliegue y la matriz de decisión del modelo de suscripciones.
- Fase 1: enlaces de pago basados en contratos en EVM:
PaymentLinkFactory+PaymentLinkReceiver+FeeSplitter, direcciones deterministas e indexador de eventos. - Fase 2: suscripciones por allowance:
SubscriptionHub, nuevo flujo para el pagador y un keeper que sustituye al procesador custodial de cobro automático. - Fase 3: despliegue en varias cadenas EVM y redundancia de keepers: Ethereum, Arbitrum, Optimism y Polygon + respaldo con Chainlink/Gelato.
- Fase 4: Solana no custodial con PDAs de Anchor: programas Anchor
payment_linkysubscription, cobro automático por delegación SPL. - Fase 5: Bitcoin, taproot 2 de 2 y un alcance honesto: custodia reducida, reembolsos prefirmados y Lightning BOLT12 como trabajo futuro.
- Fase 6: programador descentralizado y EigenLayer: cuándo ayuda un AVS y cuándo no.
- Fase 7: retirar la infraestructura de custodia: eliminar
hd_wallet_seed, quitar las rutas de barrido y actualizar los términos del servicio.
Un artículo complementario, Por qué el cobro por allowance supera al escrow y a las session keys, explica cómo elegimos el modelo de suscripciones.
Qué significa en la práctica
Para los comercios: tras la Fase 1, nada cambia en la API; las URLs de los enlaces de pago y los webhooks se comportan igual. Las reglas de retiro pasan de «liquidar tras el barrido» a «emitir al pagar». Obtienes un camino más rápido, barato y auditable sin cambiar código. La Fase 2 añade un nuevo endpoint público para que los pagadores registren su approve on-chain, en línea con el flujo documentado en Cobro automático.
Para los pagadores: los pagos únicos se sienten idénticos. Las suscripciones añaden una firma extra en la configuración (el approve on-chain) y una vía de «revocación» más clara: revoca on-chain y OrcaRail deja de intentarlo. Tus fondos nunca salen de tu wallet hasta que el contrato los cobra, y nunca quedan en una wallet que controlemos.
Para los integradores: la forma de la API se mantiene estable. Los nuevos campos (direcciones de contratos, cadena de despliegue, metadatos del allowance) son aditivos y están detrás de un feature flag por cadena. Las integraciones existentes siguen funcionando durante su ciclo de renovación actual y migran cuando lo eligen.
Qué sigue siendo custodial (por ahora)
Bitcoin. Reduciremos la custodia de forma notable en la Fase 5 moviendo cada enlace a una multisig taproot 2 de 2 con un firmante del comercio, más PSBT de reembolso prefirmadas. Pero la L1 de Bitcoin no tiene hoy la expresividad de contratos necesaria para eliminar la custodia por completo. Las suscripciones en BTC quedan fuera del alcance hasta que los pagos recurrentes de Lightning BOLT12 estén listos.
Calendario y estado
El plan completo se sigue en /docs/non-custodial/roadmap y cada fase tiene una página de estado:
- Planificadas: 0 a 7
- En curso: ninguna todavía
- Publicadas: ninguna todavía
Publicaremos un artículo de actualización con fecha cada vez que se complete una fase.
Lee la documentación de arquitectura
Para la versión de referencia de todo esto (diagramas de arquitectura, superficie de los contratos, guía de migración, modelo de seguridad), empieza en /docs/non-custodial/overview.
App de OrcaRail · Documentación · Documentación no custodial