Aviso: OrcaRail publica este blog y es una de las pasarelas de la lista. Todas las cifras de la competencia proceden de la página de precios o la documentación de cada proveedor, revisadas el 13 de octubre de 2026, con enlace a la fuente. Los precios cambian, así que confírmalos con el proveedor antes de decidir.

Comparación rápida​

Las comisiones de red (gas) son aparte en todas las pasarelas, y quién las paga depende del proveedor y de tu configuración.

Cómo elegir una pasarela de pago cripto​

• ¿Vendes suscripciones? Elige entre pasarelas que envían una factura en cada ciclo, que el cliente paga a mano, y pasarelas que cobran automáticamente a partir de una aprobación que el cliente firma una vez. El cobro automático reduce la cancelación. On-chain, funciona mediante un allowance ERC-20 en cadenas EVM o una delegación de token SPL en Solana. Por qué elegimos los cobros por allowance.
• Comisión según tu volumen. Un porcentaje fijo es fácil de calcular. Las comisiones fijas por factura, como los 0,25 $ de BitPay, pesan mucho en pagos pequeños.
• Custodia y liquidación. Algunas pasarelas guardan tus fondos y te pagan en fiat. Otras envían las stablecoins directamente a una wallet que controlas tú.
• Stablecoins y redes. Comprueba que los tokens que tienen tus clientes (USDC, USDT) se aceptan en las redes que usan.
• Pruebas. Un sandbox en testnet te permite probar todo el flujo, incluidos webhooks y renovaciones, sin dinero real.

OrcaRail​

OrcaRail es una API pensada para desarrolladores para checkout y suscripciones con stablecoins en cadenas EVM y Solana.

• Comisión: 0,5 % por transacción completada en la plataforma alojada, y las primeras 1.000 transacciones son gratis. OrcaRail autoalojado no tiene comisión de OrcaRail. Consulta los precios.
• Pagos recurrentes: dos métodos de cobro. Un enlace de pago por ciclo, o el cobro automático on-chain que cobra cada renovación de un allowance ERC-20 (EVM) o una delegación SPL (Solana). Consulta suscripciones.
• Custodia: no custodial por defecto. Los pagos se liquidan en direcciones de retiro que controlas tú.
• Herramientas para desarrolladores: API REST, webhooks firmados, SDK de Node y PHP, un paquete de Laravel Cashier, un plugin de WooCommerce y un servidor MCP para agentes de programación con IA.
• Pruebas: organizaciones sandbox gratuitas en testnets con claves ak_test_.

Coinbase Commerce​

Coinbase Commerce es el checkout para comercios de Coinbase.

• Comisión: 1 % por transacción, según la página de Commerce.
• Pagos recurrentes: Coinbase Commerce no documenta una función nativa de suscripciones.
• Nota: Coinbase ha anunciado que integrará Commerce en Coinbase Business. Comprueba si el alta está abierta en tu país.

BitPay​

BitPay es uno de los procesadores cripto más antiguos. Liquida en cuenta bancaria o en cripto.

• Comisión: escalonada según el volumen mensual. 2 % + 0,25 $ por factura pagada por debajo de 500.000 $ al mes, 1,5 % + 0,25 $ hasta 1 M$, y 1 % + 0,25 $ por encima. Consulta el soporte de BitPay.
• Pagos recurrentes: basados en facturas. El cliente paga cada factura.

NOWPayments​

NOWPayments admite una larga lista de criptomonedas.

• Comisión: desde 0,5 % para pagos sin conversión de moneda. Los pagos con conversión cuestan 1 %. Consulta los precios.
• Pagos recurrentes: una Recurring Payments API que envía facturas o solicitudes de pago en cada periodo.

CoinGate​

CoinGate es un procesador alojado con sede en la UE.

• Comisión: 1 % por transacción en el plan Standard, sin cuota mensual. Las tarifas Enterprise son personalizadas. Consulta los precios.
• Pagos recurrentes: el producto Billing envía «facturas puntuales o programadas».

CoinPayments​

CoinPayments admite muchas monedas y tokens.

• Comisión: 3 % por pago más comisiones de red, según su página de comisiones. La página también menciona un plan gratuito, pero solo se aplica a depósitos en wallets personales, no a pagos de comercios.
• Pagos recurrentes: no documentados en la página de comisiones.

Cryptomus​

Cryptomus ofrece pagos, envíos y cambio en una sola cuenta.

• Comisión: las cuentas nuevas pagan 2 % por transacción. Según el tipo de negocio, el volumen y la integración, la tarifa puede bajar a 0,4 %. Consulta las comisiones de pago.
• Pagos recurrentes: se ofrecen como servicio de pagos recurrentes.

Pagos con stablecoins de Stripe​

Stripe acepta stablecoins y las liquida en tu saldo de Stripe en moneda fiat local.

• Comisión: 1,5 % del importe de la transacción en USD. Consulta la documentación de Stripe.
• Tokens: USDC en Tempo, Ethereum, Solana, Polygon y Base. USDP y USDG se aceptan en algunas cadenas, solo en EE. UU.
• Pagos recurrentes: sí, mediante suscripciones de Stripe Billing.
• Límites: la empresa debe estar en un país admitido. EE. UU. tiene disponibilidad general, y la UE, Hong Kong, México y Suiza están en vista previa privada. Los clientes pueden pagar hasta 10.000 $ por transacción, y los pagos con stablecoins no admiten disputas.

MoonPay Commerce (antes Helio)​

MoonPay Commerce es el antiguo producto Helio, nacido en el ecosistema de Solana.

• Comisión: 1 % o 2 % por transacción, según el plan y la categoría de riesgo. Los swaps cuestan un 0,25 % extra y el off-ramp automático un 0,5 %. Consulta los precios.
• Pagos recurrentes: admite suscripciones.

BTCPay Server​

BTCPay Server es software gratuito, de código abierto y autoalojado, centrado en Bitcoin y Lightning.

• Comisión: sin comisión de procesamiento. Pagas el hosting y gestionas el servidor tú mismo.
• Pagos recurrentes: no es una función principal.
• Custodia: totalmente no custodial. Los pagos van a tu propia wallet.

Resumen​

• Comisión publicada más baja en una plataforma alojada: OrcaRail (0,5 %, las primeras 1.000 gratis) y NOWPayments (desde 0,5 % sin conversión). Cryptomus llega al 0,4 % solo tras negociar.
• Gratis y autoalojado: BTCPay Server para Bitcoin, u OrcaRail autoalojado para stablecoins en EVM y Solana.
• Suscripciones automáticas on-chain sin facturas por ciclo: el cobro automático de OrcaRail. Stripe Billing también admite suscripciones con stablecoins, al 1,5 % y con liquidación en fiat.
• Liquidar en un banco en fiat: Stripe o BitPay.

Para probar OrcaRail, abre un sandbox gratuito y sigue la guía de primeros pasos.

No necesitas ningún token si solo quieres ver el flujo: haz clic en Simular pago en una página de pago del sandbox o llama a POST /payment_intents/:id/simulate. Consulta Simular pagos.

Qué necesitas​

• El token con el que pagas: USDC en cadenas EVM y Solana, o BTC en Bitcoin.
• Gas para la transacción: ETH en cadenas EVM o SOL en Solana. Bitcoin paga su comisión en BTC.

Usa la wallet del pagador que vayas a conectar en la página de pago de OrcaRail.

USDC para todas las cadenas: faucet de Circle​

El faucet de USDC de Circle envía USDC de prueba gratis en cada una de las testnets EVM de abajo y en Solana Devnet. Elige la red, pega la dirección de tu wallet y solicita los tokens.

Testnets EVM​

La documentación de cada cadena también incluye faucets: Arbitrum y Base.

Solana Devnet​

Bitcoin testnet4​

OrcaRail usa Bitcoin testnet4 (explorador: mempool.space testnet4). Usa una wallet que admita direcciones de testnet4.

Consejos​

• Los faucets limitan las solicitudes, a menudo a una por dirección y día. Pídelos con antelación.
• Algunos faucets de gas piden iniciar sesión o tener un pequeño saldo en mainnet.
• Tu sandbox muestra exactamente qué testnets están activas. Consulta Testnets y faucets para conocer las reglas: las organizaciones live no pueden usar testnets y los sandboxes no pueden usar mainnets.

Qué es de código abierto​

Estos paquetes son públicos en GitHub y tienen licencia MIT:

Instálalos desde npm o Composer como siempre; la fuente de verdad de cada paquete es su repositorio indicado arriba.

Úsalos, informa, contribuye​

Usa los paquetes en tus apps. Dirige a agentes y personas a los repositorios y a docs.orcarail.com para ver APIs y ejemplos.

Informa de bugs y solicitudes de funcionalidades en los GitHub Issues del paquete que te interese:

• Issues del SDK de Node
• Issues del SDK de PHP
• Issues de Laravel Cashier
• Issues del MCP
• Issues del plugin de WooCommerce
• Issues de la app de demostración

Contribuye cuando puedas: haz un fork, abre un pull request y mantén los cambios acotados. Las correcciones de documentación, los tests y las pequeñas mejoras de los SDK son especialmente bienvenidos. Si no sabes bien dónde encaja algo, abre primero un issue.

Por qué importa​

Tener SDK y plugins abiertos significa que puedes inspeccionar cómo se comunica OrcaRail con tu stack, corregir carencias sin esperar a un proveedor cerrado y compartir mejoras con todos los que integran los mismos rieles.

OrcaRail alojado sigue siendo la superficie del producto para pagos, paneles e infraestructura de producción. Este anuncio trata de los paquetes para desarrolladores con los que te integras, no afirma que toda la plataforma sea de código abierto.

Resumen​

Gracias por construir sobre OrcaRail. Si publicas algo útil, abre un PR, o un issue si necesitas ayuda.

App de OrcaRail · Documentación · GitHub

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​

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_link y subscription, 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

Amplía, y no sustituye, la hoja de ruta no custodial y el debate sobre el protocolo. La hoja de ruta no custodial (Línea N, Fases 0-7) elimina la custodia. Este whitepaper añade una Línea P paralela que descentraliza el resto: indexadores, frontends, estándares, keepers y gobernanza.

Resumen​

El Protocolo OrcaRail es un conjunto de primitivas on-chain (factorías y receptores de enlaces de pago, hubs de suscripción por allowance, divisores de comisiones, programas Anchor en Solana y descriptores multisig taproot en Bitcoin) junto con especificaciones públicas para indexadores, keepers, frontends y SDK que operan sobre esas primitivas. El protocolo cumple cuatro invariantes: no custodial (ninguna parte retiene fondos en tránsito), ininterrumpido (la liquidación legítima continúa sin OrcaRail), creíblemente neutral (ninguna parte puede censurar una transacción pagada y bien formada) y compatible con Web2 (los comercios conservan claves de API, webhooks y paneles). El despliegue sigue dos líneas paralelas: la Línea N elimina la custodia en siete fases; la Línea P descentraliza la indexación, los frontends, los estándares y el enrutamiento de la liquidación en cinco fases. No existe ningún token en el lanzamiento y este whitepaper no planea ninguno; un futuro token de gobernanza queda explícitamente reservado como opción tras la descentralización y, si llegara a introducirse, se publicaría con su propio whitepaper.

1. Introducción: por qué un protocolo y no solo un producto​

Hoy OrcaRail es un producto de pagos alojado, con opciones autoalojadas en camino. Eso es un producto, no un protocolo. Los productos se pueden mejorar; en los protocolos se puede confiar en ausencia de quien los creó.

La hoja de ruta no custodial saca la custodia del camino. Es necesario, pero no suficiente. Incluso sin custodia, un riel de pagos puede romperse si la empresa que lo opera deja de pagar las facturas de AWS, recibe sanciones o simplemente cambia de rumbo. Un protocolo tiene que seguir funcionando cuando pasan esas cosas.

El debate sobre el protocolo repasó cinco arquitecturas. La síntesis fue: publicar el camino del Pragmático, mantener la presión del Maximalista sobre él, adoptar intents para la experiencia del pagador, redactar estándares por el camino y mantener la cadena propia como un futuro opcional. Este whitepaper es esa síntesis escrita como compromisos.

2. Objetivos de diseño​

Cada objetivo se enuncia con una definición precisa y comprobable. La pregunta «¿cumple el diseño esto?» debe tener respuesta sí o no.

1. No custodial: en ningún momento de un pago o de un cobro de suscripción una wallet o cuenta controlada por OrcaRail, por el procesador de un comercio o por cualquier intermediario retiene los fondos del pagador. Prueba: ¿puede un regulador congelar fondos en tránsito notificando solo a OrcaRail? No.
2. Ininterrumpido: si los servidores de OrcaRail se apagan indefinidamente, un cobro de suscripción legítimo y vencido sigue liquidándose on-chain, y un pagador puede seguir completando un pago único. Prueba: tras una caída de OrcaRail de 30 días, ¿alguna suscripción bien configurada se ha saltado un cobro? No.
3. Creíblemente neutral: las reglas on-chain son públicas, inmutables por enlace y se aplican por igual. OrcaRail no puede denegar servicio de forma selectiva en la capa de liquidación (solo en su propio frontend). Prueba: ¿puede un comercio no deseado seguir cobrando mediante un frontend de terceros? Sí.
4. Compatible con Web2: los comercios conservan la ergonomía que ya tienen (endpoints REST, webhooks, claves de API, paneles, email). Convertirse en protocolo no exige que un comercio ejecute herramientas de Ethereum para aceptar un pago. Prueba: ¿puede un comercio que no viene del mundo cripto integrarse en menos de una hora? Sí.
5. P2P real: se define con precisión en la siguiente sección.

Un diseño que falle en cualquiera de los objetivos está incompleto.

3. Qué significa aquí «P2P real»​

«Peer-to-peer» es un término sobrecargado. En este protocolo tiene tres capas concretas.

• P2P en la liquidación: el pagador firma; los fondos fluyen del pagador al contrato on-chain (EVM), a una PDA propiedad del programa (Solana) o a una multisig 2 de 2 (Bitcoin), y de ahí al comercio y a los receptores de comisiones, de forma atómica. Ninguna wallet de OrcaRail está en el camino. Lo garantiza la Línea N.
• P2P en el descubrimiento: un enlace de pago o una suscripción se puede resolver por completo a partir de sus datos on-chain y (opcionalmente) de metadatos fijados en IPFS. Cualquier wallet, frontend o procesador de terceros puede mostrarlo y completarlo. El panel alojado de OrcaRail es una implementación de la capa de presentación, no el registro.
• P2P en la disponibilidad: SubscriptionHub.charge(id) y la instrucción charge de Anchor son públicas. Cualquier EOA o solver puede llamarlas. El programador de OrcaRail es un participante entre varios (Chainlink, Gelato, operados por comercios, operados por solvers).

Lo que «P2P real» no significa aquí: no somos Lightning; no somos una capa de canales directos de wallet a wallet; no estamos sustituyendo una app de pagos por una DHT. OrcaRail es un protocolo on-chain con experiencia de usuario off-chain. La propiedad P2P viene de que es imposible que un intermediario se interponga en la liquidación, el descubrimiento o la disponibilidad, no de evitar los rieles on-chain.

4. Arquitectura del sistema​

Al nivel más alto, el protocolo tiene cinco capas.

La capa de liquidación es inmutable por enlace en EVM y Solana, y derivada de descriptores por enlace en Bitcoin. Las otras cuatro capas son intercambiables. Si quieres el diagrama técnico completo, consulta /docs/non-custodial/architecture.

5. Primitivas de liquidación​

Referencia completa: /docs/non-custodial/contract-reference. Resumen:

• EVM: PaymentLinkFactory (direcciones deterministas con CREATE2), PaymentLinkReceiver (clon mínimo EIP-1167, inmutable por enlace), FeeSplitter (reparto atómico en puntos básicos), SubscriptionHub (cobro por allowance con lastChargedAt monótono).
• Solana: programa Anchor payment_link (una PDA por enlace, repartos por CPI) y programa Anchor subscription (autoridad delegada SPL, con la misma semántica de charge que el hub de EVM).
• Bitcoin: multisig taproot 2 de 2 por enlace (firmante del comercio + firmante de la plataforma desde HSM/MPC) con PSBT de reembolso prefirmadas. Sin BTC recurrente hasta que madure la recurrencia de Lightning BOLT12.

Cada primitiva está diseñada para que el mismo linkId o subscriptionId resuelva siempre a la misma dirección determinista en la misma cadena: sin rotación de direcciones, sin reemisión y sin un mapeo guardado en un servidor.

6. Entre cadenas como intents​

Un protocolo que trata lo cross-chain como «nuestro backend llama a Relay» sigue siendo un producto. Un protocolo trata lo cross-chain como un intent del pagador:

• El pagador firma: «paga al comercio X 50 $ en USDC, desde cualquiera de mis wallets en cualquier cadena compatible, en menos de 1 hora, con comisiones de hasta Y».
• Las redes de solvers existentes (Across, Relay, deBridge, al estilo CoW) compiten por cumplir el intent. Los solvers cobran una recompensa incluida en el intent.
• Para rutas de cola larga poco rentables (importes pequeños, cadenas poco conocidas), OrcaRail opera un solver de respaldo a coste para que esa cola también se liquide. El respaldo es público y cualquiera puede operar otro.

La firma del pagador está acotada por importe, destinatario, plazo y comisión máxima. En el peor caso, un solver malicioso es lento; no puede desviar los fondos. Es la síntesis del «Creyente en los intents» del debate sobre el protocolo, escrita como compromiso.

7. Estándares e interoperabilidad​

Las primitivas de enlaces de pago y suscripciones de OrcaRail son un riel genérico. Su valor solo se multiplica si otros procesadores, wallets e indexadores las implementan de forma nativa.

Compromisos:

• Redactar un EIP para enlaces de pago no custodiales usando PaymentLinkFactory y PaymentLinkReceiver como superficie de referencia. Coescribirlo con al menos otro equipo de procesador o de wallet para evitar el patrón «EIP de un solo proveedor».
• Redactar un EIP para suscripciones por allowance usando SubscriptionHub como referencia. El lastChargedAt monótono y el conjunto de motivos de ChargeSkipped(reason) son objetivos de estandarización.
• Publicar un equivalente para Solana mediante el IDL de Anchor y una especificación escrita, para que cualquier wallet o indexador de Solana pueda mostrar un enlace de pago desde cero.
• Publicar el esquema canónico del subgraph para que cualquier indexador (The Graph, Goldsky, Envio, autoalojado) sea compatible sin cambios.

Escribir el EIP no reduce nuestra ventaja competitiva. Como se argumentó en el debate, esa ventaja está en las integraciones, el cumplimiento, los SLA y la confianza de los comercios, y nada de eso se copia con un EIP.

8. Gobernanza​

La gobernanza tiene dos horizontes.

Hoy y a corto plazo​

• EVM: multisig Safe 3 de 5 en cada cadena desplegada. Firmantes con hardware wallet. Rotación anual. Timelock de 48 horas en las actualizaciones de proxies. Las instancias PaymentLinkReceiver por enlace son inmutables.
• Solana: multisig Squads 3 de 5 con el mismo conjunto de firmantes y la misma política de rotación.
• Alcance de las actualizaciones: las factorías y los hubs están detrás de proxies UUPS; los receptores por enlace y los registros por suscripción no cambian con las actualizaciones.
• Auditable públicamente: cada despliegue y actualización se realiza como una ceremonia multisig anunciada, con las transacciones firmadas registradas.

Es la gobernanza descrita en /docs/non-custodial/security-model.

Tras la descentralización​

Con el tiempo, el conjunto de firmantes deja de estar formado solo por empleados de OrcaRail y pasa a ser un consejo público formado por integradores, empresas de auditoría, operadores de keepers y colaboradores independientes. La autoridad de actualización pasa al consejo. En ese momento la gobernanza on-chain se convierte en una opción real, pero solo como mecanismo de gobernanza, no como vehículo de especulación.

El umbral de la «descentralización» es explícito: al menos tres frontends de producción independientes que alojen el riel, al menos tres keepers independientes ejecutando cobros y al menos un procesador ajeno a OrcaRail publicando integraciones. Hasta que eso sea real, el protocolo no está descentralizado, sea cual sea el mecanismo de gobernanza que tenga encima.

9. Futuro token de gobernanza (reserva explícita)​

Esta sección es corta y específica a propósito.

• Sin token en el lanzamiento. Sin preventa. Sin asignaciones. Sin puntos. Sin reclamaciones retroactivas.
• Un futuro token de gobernanza queda reservado como opción, no como compromiso. Solo es apropiado después de alcanzar el umbral de descentralización de la sección 8 y cuando exista una base activa de integradores, keepers y frontends que se beneficie de derechos formales de señalización.
• Si alguna vez introducimos uno, se publicará con su propio whitepaper, con total transparencia sobre distribución, bloqueos, suministro y superficie de gobernanza. Ese whitepaper del token se debatiría públicamente antes de la emisión.
• El token sería primero de gobernanza, no de especulación. Mecanismos que tienen sentido: votaciones de señalización sobre actualizaciones, ajuste de parámetros dentro de límites seguros, reputación de los operadores de keepers. Mecanismos que no: descuentos en comisiones ligados a las tenencias, pagar por pagar, yield farming.
• No diremos que el protocolo está descentralizado porque exista un token. La descentralización se mide con lo descrito en la sección 8. Un token es un instrumento que puede formalizar una descentralización ya conseguida; no puede fabricarla.

Esta reserva consta en el whitepaper del protocolo, este documento, y en ningún otro sitio. Cualquier cambio futuro de esta postura es un cambio de este whitepaper, publicado abiertamente, no un anuncio unilateral.

10. Economía y comisiones: cómo se sostiene el protocolo sin token​

El modelo de ingresos del protocolo es el mismo que el del producto, solo que codificado on-chain.

• El reparto de comisiones vive en la configuración en puntos básicos de FeeSplitter para cada pago. Son los mismos conceptos que describe hoy la página de retiros: comercio, plataforma (la parte alojada de OrcaRail), referido/afiliado y comisión de puente.
• La superficie alojada por OrcaRail (panel, email, gas del paymaster, atención al cliente) se paga con la parte de OrcaRail en el reparto.
• Los alojamientos alternativos (procesadores de terceros, operadores autoalojados, frontends fijados en IPFS) pueden funcionar con un reparto de cero puntos básicos para la plataforma o configurar su propio receptor de comisiones. El protocolo no privilegia la comisión de OrcaRail sobre la de nadie.
• Sin emisión, sin subsidios, sin rendimiento por staking. Los costes son costes en efectivo y los ingresos son ingresos en efectivo. El protocolo solo se abarata si baja el gas o si un alojamiento acepta un margen menor, no emitiendo tokens para tapar los costes operativos.

11. Modelo de seguridad​

Declaración completa: /docs/non-custodial/security-model. Postura básica:

• Los receptores por enlace y los registros por suscripción son inmutables.
• Las factorías y los hubs solo se actualizan mediante multisig + timelock.
• Los keepers son EOA que solo pagan gas, sin autoridad para mover fondos.
• La firma en BTC usa un servicio HSM o MPC del lado de la plataforma, más una clave del comercio; ningún servidor tiene autoridad unilateral de gasto.

Un añadido específico de la conversión en protocolo: los alojamientos de frontend independientes deben verificar las direcciones de los contratos contra un registro on-chain (o un manifiesto de versión firmado) antes de mostrar un enlace de pago. Un frontend clonado y malicioso que dirija los pagos a un contrato parecido es el vector de phishing más probable cuando el ecosistema tenga varios alojamientos. El registro canónico vive on-chain y el flujo de verificación se documenta como parte de P2.

12. Hoja de ruta: dos líneas paralelas​

El despliegue del protocolo avanza en dos líneas a la vez.

La Línea N es la hoja de ruta existente, sin cambios. La Línea P formaliza como fases los compromisos M1-M5 del artículo del debate. Ambas líneas apuntan al mismo estado final: un riel que sigue funcionando si OrcaRail se aparta.

La Línea P nunca bloquea a la Línea N, y la Línea N nunca bloquea a la Línea P. Cualquiera de las dos puede publicar una fase antes que la otra.

13. Fases de la Línea P​

Cinco fases, cada una extensión natural de un compromiso M del artículo del debate.

P1: subgraph público e indexador abierto​

Alcance: un subgraph canónico (The Graph, Envio o equivalente) que indexe todos los eventos Paid, SubscriptionCreated, Charged, ChargeSkipped, Canceled y Refunded de PaymentLinkReceiver y SubscriptionHub en todas las cadenas desplegadas. Esquema publicado. Instrucciones de autoalojamiento publicadas para que cualquiera pueda ejecutar el mismo índice.

Lista de estado

• Manifiesto + mappings del subgraph para las cadenas EVM activas en la Fase 1 y la Fase 3
• Equivalente en Solana (webhooks de Helius o stream de Triton) con las mismas formas de evento
• Esquema documentado y con versionado estable
• Un indexador externo demostrado ejecutando el mismo esquema contra eventos reales

P2: frontends descentralizados (IPFS / ENS)​

Alcance: fijar la app de pago y el panel del comercio de OrcaRail en IPFS con paquetes de versión direccionados por contenido. Resolverlos mediante ENS (pay.orcarail.eth, app.orcarail.eth). Builds reproducibles para que cualquiera pueda verificar que el paquete coincide con el código fuente. Un clon malicioso tendría que suplantar tanto las direcciones de los contratos como el registro ENS, no solo el nombre de host.

Lista de estado

• La app de pago se compila de forma reproducible
• El panel se compila de forma reproducible
• Registros ENS apuntando a CIDs de IPFS
• Ceremonia de firma de versiones desde la multisig Safe
• Registro on-chain de direcciones de contratos que los frontends verifican antes de mostrar

P3: estándares (borrador de EIP)​

Alcance: redactar y enviar un EIP para enlaces de pago no custodiales y un EIP complementario para suscripciones por allowance. Coescribirlos con al menos otro equipo de procesador o de wallet. La implementación de referencia son los contratos de OrcaRail. La especificación equivalente para Solana se publica junto a los EIP.

Lista de estado

• Coautor confirmado
• Borrador del EIP de enlaces de pago en fase de hilo de discusión
• Borrador del EIP de suscripciones en fase de hilo de discusión
• Especificación de Solana publicada junto a los IDL de Anchor
• Comentarios de los editores de EIP incorporados hasta Last Call

P4: SDK de pagador basado en intents​

Alcance: una superficie de SDK (orcarail.pay(intent)) que acepte un intent firmado por el pagador y lo enrute por las redes de solvers existentes (Across, Relay, deBridge), con un solver de respaldo operado por OrcaRail para las rutas de cola larga. El esquema de intents se estandariza en sincronía con P3.

Lista de estado

• Esquema de intents finalizado
• Adaptador del SDK para al menos dos redes de solvers
• Solver de respaldo desplegado y medido
• La experiencia del pagador en la app de pago admite el mismo intent + cross-chain
• Especificación publicada como parte de la referencia del SDK de Node

P5: kit de autoalojamiento / implementación de referencia​

Alcance: un Docker Compose (y un chart de Helm) que permita a cualquiera ejecutar de extremo a extremo un procesador compatible con OrcaRail a partir de los contratos públicos. Incluye subgraph, keeper, indexador, panel opcional y una especificación OpenAPI de la API del procesador a la que otros puedan ajustarse.

Lista de estado

• Docker Compose que arranca contra una cadena real y da servicio a un comercio de prueba
• Especificación OpenAPI de la API del procesador
• Chart de Helm para operadores de Kubernetes
• Prueba de extremo a extremo de que un operador autoalojado procesa pagos idénticos a la versión alojada
• Documentación en /docs/non-custodial/ (se añadirá en un cambio futuro solo de documentación; fuera del alcance de este whitepaper)

14. P6 opcional: evaluación de una cadena propia​

P6 replica el patrón de la evaluación de EigenLayer. No es un compromiso. Es una revisión trimestral con disparadores concretos.

Recomendación actual: aplazar.

Disparadores que abrirían un documento de diseño para construir una Fase P6:

1. El volumen de pagos en una sola cadena supera un umbral en el que el gas pasa a ser una partida relevante de la comisión de la plataforma.
2. Una cadena de herramientas L2/L3 canónica ofrece precompilados especializados para la semántica de repartos de pagos a un coste casi nulo.
3. Demanda de los comercios de una latencia de liquidación de fracciones de céntimo que mainnet / L2 no puede cumplir de forma constante.
4. Un socio de rollup-as-a-service permite a OrcaRail lanzar con secuenciación compartida desde el primer día.

Si se activara, la construcción preferiría OP Stack con secuenciación compartida (Espresso, Astria) y un puente de salida creíble hacia las cadenas canónicas que ya admitimos. Aun así, las Fases N0-N7 y P1-P5 deben estar lo bastante maduras para que una cadena propia sea una optimización, no una dependencia.

15. Qué es OrcaRail hoy y en qué se convierte​

Un antes y después a nivel de riel.

La superficie de cara a Web2 se mantiene estable a propósito. Los comercios que se integraron con la API REST en 2026 no se rompen en 2028.

16. Modelo de amenazas​

Las amenazas que contemplamos explícitamente, con sus mitigaciones:

• Bug en un contrato → varias auditorías por contrato; receptores por enlace inmutables; actualizaciones UUPS con timelock de 48 horas en factorías y hubs; programa público de recompensas por bugs.
• Caída del keeper → redundancia de keepers de la Fase 3 de la Línea N (Chainlink/Gelato) + red de solvers de P4 de la Línea P + charge() manual público como respaldo.
• Phishing de frontends → registro on-chain de contratos de P2 de la Línea P + direccionamiento por contenido con ENS + ceremonia de firma de versiones desde la multisig Safe.
• Captura de la gobernanza → rotación de firmantes de la multisig; umbral 3 de 5; consejo tras la descentralización formado por operadores independientes; ceremonias públicas.
• Acción regulatoria contra un alojamiento → kit de autoalojamiento de P5 de la Línea P + varios frontends independientes para que los comercios tengan rieles alternativos.
• Desviación del subgraph o del indexador → esquema canónico + pruebas de reproducibilidad; varios indexadores independientes.
• Mercado de solvers poco profundo → solver de respaldo de OrcaRail a coste; entrada sin permisos para nuevos solvers.
• Pérdida de claves de BTC → xpub de respaldo en el alta del comercio; failover del HSM; las PSBT de reembolso prefirmadas mantienen posible la recuperación por parte del pagador.
• Reorganizaciones en EVM → lastChargedAt monótono en SubscriptionHub; equivalente en Solana con last_charged_at.
• Distorsión inducida por un token → sin token en el lanzamiento; reserva explícita; cualquier token futuro queda condicionado a umbrales de operadores independientes antes de poder reclamar un papel de gobernanza.

17. Preguntas abiertas que reconocemos​

Escribir este documento no resuelve todas las preguntas que plantea.

• ¿Cuándo empieza exactamente la «descentralización»? La sección 8 da un umbral (tres frontends independientes, tres keepers independientes, un procesador ajeno a OrcaRail). Si ese umbral es el adecuado es un debate abierto.
• ¿Quién paga el subgraph público a escala? The Graph tiene un mercado; el autoalojado es gratis pero pesado de operar. La economía aún no está resuelta.
• ¿Cuál es la salida para un comercio cuyo alojamiento de frontend principal desaparece? P5 hace posible el autoalojamiento, pero no lo hace automático. Un flujo de «migrar mi tienda a otro alojamiento» es trabajo futuro.
• ¿Qué decide realmente la gobernanza en un protocolo con contratos inmutables por enlace? Actualizaciones de las factorías, ajuste de parámetros en los hubs (listas de tokens pausados, despliegues en nuevas cadenas) y valores por defecto del reparto de comisiones para el tráfico alojado por OrcaRail, pero no mucho más. Si ese alcance basta para justificar una gobernanza on-chain forma parte de la conversación sobre la descentralización.
• ¿Qué pasa con el protocolo si OrcaRail, la empresa, cambia de opinión sobre la reserva de la sección 9? Cualquier cambio es un cambio publicado de este whitepaper. Nada de giros unilaterales y silenciosos.

18. Conclusión: una llamada a quienes construyen​

La hoja de ruta no custodial saca el riel de la custodia. Este whitepaper saca el riel de OrcaRail. Ambos tienen que publicarse para que cualquiera de los dos importe.

Si estás construyendo una wallet, un panel, un indexador, un solver, una herramienta de cumplimiento o un procesador rival, el protocolo está diseñado para aceptar tu contribución sin pedir permiso. Coescribe el EIP. Ejecuta el subgraph. Fija tu propio frontend. Opera un keeper o un solver. Abre issues contra la implementación de referencia. Cuanto más de la Línea P lo haga gente que no trabaja en OrcaRail, más se ganará el protocolo la palabra protocolo.

Los comercios Web2 con los que trabajamos hoy no notarán nada de esto: sus claves de API, webhooks y paneles siguen funcionando. Esa estabilidad es justo lo que buscamos. Estamos cambiando los cimientos del riel, no la superficie que los comercios tocaron al registrarse.

Referencias

• La hoja de ruta no custodial de OrcaRail: Línea N
• El debate sobre el protocolo: cinco visiones para un OrcaRail totalmente no custodial: origen de la Línea P
• Por qué el cobro por allowance supera al escrow y a las session keys: decisión sobre el modelo de suscripciones
• Arquitectura: arquitectura técnica completa
• Referencia de contratos: ABIs, eventos y direcciones
• Modelo de seguridad: supuestos de confianza y custodia de claves
• Hoja de ruta: estado de las fases de la Línea N
• Evaluación de EigenLayer: patrón reutilizado para P6

En resumen​

• El reparto de comisiones queda congelado en cuatro conceptos: comercio, plataforma, referido/afiliado y comisión de puente. Todo lo que hace el divisor on-chain se expresa en puntos básicos; sin ajustes off-chain.
• Base es la cadena de lanzamiento de la Fase 1. Barata, rápida, ya incluida en la lista de cadenas del servicio de wallets y con USDC nativo.
• Las suscripciones adoptan approve + pull de ERC-20 (EVM) y delegación SPL (Solana). Se descartaron los diseños de escrow y de session keys; consulta la matriz de decisión más abajo.
• Los contratos los despliega una multisig Safe 3 de 5 (EVM) y una multisig Squads 3 de 5 (Solana). Los receptores por enlace son inmutables. Las factorías y SubscriptionHub están detrás de un pequeño proxy con un timelock de 48 horas.

Qué cambia en esta fase​

Nada en producción. La Fase 0 es una especificación escrita, tres propuestas de auditoría, una ceremonia de claves de despliegue y un par de ADR fusionados.

La especificación del reparto de comisiones (congelada)​

Hoy, SmartAccountWalletService.drainSmartAccountWallet en api/src/withdrawals/services/smart-account-wallet.service.ts compone transferencias en una UserOperation con tres destinatarios: el comercio (toAddress), la wallet de soporte (supportWalletAddress) y la wallet de comisiones. La versión en contrato replica esto exactamente:

struct Split {
    address merchant;   // main receiver
    address platform;   // support / platform fee
    address referral;   // commission / affiliate (optional, zero = skip)
    address bridgeFee;  // Relay bridge fee carrier (optional, zero = skip)
    uint16 platformBps;
    uint16 referralBps;
    uint16 bridgeFeeBps;
}

Todo lo que el keeper hace hoy en TypeScript se puede calcular a partir de esta struct y del importe del pago. Lo que el keeper actual no puede expresar (por ejemplo, impuestos dinámicos o retenciones a nivel de comercio) queda fuera del alcance de la Fase 1; lo añadiremos en una fase posterior si hace falta.

Selección de cadena​

La cadena de lanzamiento de la Fase 1 es Base:

• Ya está en nuestro mapa de chainId (8453 → base, 84532 → baseSepolia) en api/src/payments/wallet.service.ts.
• El gas es lo bastante barato como para que desplegar PaymentLinkReceiver + repartir en el primer pago cueste céntimos por transacción.
• La política de paymaster de Alchemy ya la admite, lo que nos da una vía de escape si queremos patrocinar el keeper en SubscriptionHub.charge().
• USDC nativo (no puenteado), algo importante para los allowances de las suscripciones.

Ethereum mainnet, Arbitrum, Optimism y Polygon llegan en la Fase 3. Solana es un programa aparte, que se sigue en la Fase 4.

Modelo de suscripciones: la matriz de decisión​

Evaluamos tres diseños. Solo uno nos sirve.

Approve + pull es el único que funciona con las wallets que los pagadores ya usan (MetaMask, Phantom, hardware wallets, Safes). También es el diseño que ya publicamos en Cobro automático, que documenta approve(spender, amount) y la delegación SPL. La Fase 2 sustituye el lado del cobro por un smart contract y deja sin cambios el lado del pagador.

El argumento completo está en Por qué el cobro por allowance supera al escrow y a las session keys.

Custodia de las claves de despliegue​

• EVM: Safe (antes Gnosis Safe) en Base con umbral 3 de 5. Firmantes: dos fundadores, un responsable de operaciones, un asesor y una copia de seguridad en frío. Cada firmante usa una hardware wallet; ninguna clave en un servidor.
• Solana: multisig Squads con la misma configuración 3 de 5 y los mismos firmantes.
• Rotación: cada firmante rota anualmente o al marcharse; cualquier rotación individual es una transacción de Safe/Squads.
• Ningún keeper en caliente puede desplegar. La EOA del keeper en NestJS (usada para llamar a charge() en la Fase 2) no tiene autoridad de despliegue, ni de actualización, ni dirección de comisiones.

Política de actualizaciones​

• PaymentLinkReceiver por enlace: inmutable. Sin actualizaciones. Es una ganancia de confianza para los pagadores: el código al que pagan no puede cambiar después.
• PaymentLinkFactory: pequeño proxy UUPS propiedad de la multisig, con timelock de 48 horas en upgradeTo. Las actualizaciones no pueden cambiar los receptores ya desplegados.
• SubscriptionHub: el mismo patrón. La semántica de charge() y cancel() es estable entre versiones; si alguna vez necesitamos un cambio incompatible, desplegamos SubscriptionHubV2 y migramos en lugar de actualizar.
• Semántica de reembolsos y disputas: refund(txId) on-chain, invocable por el firmante del comercio (mediante su clave de API → EOA del keeper) o por la multisig de despliegue. El pagador no puede reembolsarse a sí mismo (igual que en el producto actual).

Estrategia de proveedores de auditoría​

Preseleccionaremos tres empresas y haremos una auditoría principal + una revisión competitiva:

• Candidatos principales (EVM): Spearbit, Trail of Bits, Zellic.
• Candidatos secundarios (Solana): OtterSec, Neodyme.
• Alcance: PaymentLinkFactory, PaymentLinkReceiver, FeeSplitter, SubscriptionHub. Los programas Anchor tienen su propia auditoría en la Fase 4.
• Presupuesto: la auditoría es un requisito previo obligatorio para el lanzamiento en Base mainnet. Nada de mainnet antes del informe con todo corregido.
• Divulgación pública: los informes de auditoría se suben al repositorio y se enlazan desde /docs/non-custodial/security-model.

Riesgos y mitigaciones​

• Ampliación descontrolada de la especificación. Mitigación: todo lo que no se pueda expresar como reparto en puntos básicos se aplaza a una fase posterior. La Fase 1 no se bloquea por impuestos dinámicos ni por ajustes por comercio.
• Disponibilidad de los firmantes de la multisig. Mitigación: 3 de 5, no 2 de 3, para que dos firmantes cualesquiera puedan no estar disponibles sin congelar los despliegues.
• Plazos de la auditoría. Mitigación: empezar ya las conversaciones con proveedores; publicar los contratos en testnet durante la auditoría; el despliegue en mainnet queda condicionado.
• Un caso de comisión olvidado. Mitigación: reproducir cada camino actual de drainSmartAccountWallet (nativo + ERC-20, con/sin soporte, con/sin comisión) como test de invariantes de Foundry antes de la auditoría.

Lista de estado​

• Struct del reparto de comisiones aprobada y etiquetada
• Base seleccionada como cadena de lanzamiento de la Fase 1
• Tres proveedores de auditoría preseleccionados
• Multisigs de despliegue Safe (Base) y Squads (Solana) creadas y probadas
• ADR fusionado sobre la política de actualizaciones y el timelock
• ADR fusionado sobre la decisión del modelo de suscripciones
• Semántica de reembolsos / disputas documentada

Qué sigue​

La Fase 1 implementa la especificación: Enlaces de pago basados en contratos en EVM.

Documentación de referencia: Estado de la Fase 0 · Modelo de seguridad · Arquitectura

En resumen​

• PaymentLinkFactory.computeAddress(linkId) devuelve una dirección CREATE2 determinista. Mostramos esa dirección al pagador antes de que se despliegue nada.
• PaymentLinkReceiver es un clon mínimo EIP-1167. Acepta token nativo o ERC-20, emite Paid y llama a FeeSplitter.split() en la misma transacción.
• api/src/payments/wallet.service.ts deja de generar HD wallets para los enlaces EVM; en su lugar llama a la vista de la factoría.
• El camino de barrido (drainSmartAccountWallet, getSmartAccountClientForDepositWallet) se omite para los enlaces creados con el flag useOnChainReceiver.

Qué cambia en esta fase​

En el lado del «después» no hay ninguna caja que controlemos reteniendo los fondos.

Contratos introducidos​

Todos en un nuevo paquete contracts/evm/.

PaymentLinkFactory​

• computeAddress(bytes32 linkId) view returns (address): dirección CREATE2 determinista derivada de linkId (el UUID actual del enlace de pago, con hash a bytes32).
• deployAndPay(bytes32 linkId, Split split, address token, uint256 amount): despliegue diferido + pago en una sola transacción. La factoría clona la implementación de PaymentLinkReceiver, la inicializa con el Split y reenvía los fondos.
• isDeployed(bytes32 linkId) view returns (bool): auxiliar que usan el indexador y la interfaz.
• Actualizable detrás de un proxy UUPS, propiedad de la multisig de despliegue (Safe 3 de 5), con timelock de 48 horas en upgradeTo.

PaymentLinkReceiver (clon)​

• Inmutable tras la inicialización. Guarda la struct Split y la dirección de FeeSplitter.
• pay(address token, uint256 amount): gestiona token nativo y ERC-20 en un único punto de entrada. Usa SafeERC20 para que funcionen tokens no estándar (USDT). Emite Paid(linkId, payer, token, amount).
• Llama a FeeSplitter.split() de forma atómica. Si el reparto revierte, el pago revierte.
• refund(bytes32 txId) explícito, invocable solo por la EOA del keeper del comercio o por la multisig de despliegue.

FeeSplitter​

• split(Split s, address token, uint256 amount): reparte por puntos básicos. El wei restante va al comercio (sin pérdida de polvo).
• Emite Split(txId, merchant, platform, referral, bridgeFee) para que el indexador mantenga paridad con los payloads de webhook heredados.

Cambios en la API​

El mayor cambio de código está en api/src/payments/wallet.service.ts. Hoy, getOrCreateAddressForPaymentLink deriva desde hd_wallet_seed, calcula la dirección contrafactual de Alchemy y la guarda en wallet_address. Tras la Fase 1, para las cadenas EVM con el feature flag, esa función pasa a ser:

async function getOrCreateAddressForPaymentLink(paymentLinkId, network) {
  if (isEvm(network) && featureFlags.useOnChainReceiver(network.chainId)) {
    const address = await factory.computeAddress(hashLinkId(paymentLinkId))
    return { address, walletAddressId: null, derivationPath: null }
  }
  // legacy path unchanged
}

Sin derivación HD. Sin material privado en la base de datos para los enlaces nuevos.

Un nuevo servicio, payments/indexer/evm-paid-event.service.ts, se suscribe a los eventos Paid de cada cadena habilitada mediante viem.watchContractEvent. Cuando hay coincidencia:

1. Obtiene el paymentLinkId del evento (indexado en bytes32).
2. Inserta o actualiza una fila PaymentTransaction, con la misma forma que hoy.
3. Emite los mismos webhooks que emite hoy el camino de finalización del barrido (api/src/webhooks/webhooks.service.ts).

El feature flag useOnChainReceiver se define por chain id. Un enlace creado con el flag desactivado se queda para siempre en el camino de barrido heredado; no migramos enlaces en curso.

Obsolescencias​

En esta fase omitimos, pero no eliminamos:

• SmartAccountWalletService.drainSmartAccountWallet: ya no se llama en las cadenas con el flag.
• SmartAccountWalletService.getSmartAccountClientForDepositWallet: no hace falta cuando las direcciones vienen de la factoría.
• Filas de wallet_address: no se escriben en las cadenas EVM con el flag.

La eliminación real ocurre en la Fase 7, cuando todos los enlaces heredados de la cadena estén liquidados.

Plan de migración​

• Enlaces nuevos en Base: reciben una dirección CREATE2 calculada por la factoría. La interfaz la muestra igual que hoy.
• Enlaces abiertos existentes en Base: se quedan en el camino de barrido heredado hasta que caduquen o se liquiden. Sin migración forzada.
• Otras cadenas EVM: en el camino heredado hasta que la Fase 3 active su flag.

Riesgos y mitigaciones​

• Se muestra una dirección CREATE2 antes de que exista código. Mitigación: documentar que la recuperabilidad depende del desplegador de la factoría. Limitar maxLinkValue en la factoría durante los primeros 30 días.
• USDT y otros ERC-20 no estándar. Mitigación: SafeERC20 tanto en PaymentLinkReceiver como en FeeSplitter; tests de fuzzing de Foundry contra un fork de mainnet con USDT.
• Tokens con comisión por transferencia. Mitigación: lista de tokens permitidos; los que no estén en ella vuelven al camino heredado.
• Retraso del indexador de la cadena. Mitigación: doble suscripción (Alchemy + RPC pública de respaldo); trabajos de conciliación cada hora; inserción/actualización idempotente.
• Hallazgo de auditoría durante el desarrollo. Mitigación: auditoría como requisito; sin despliegue en mainnet antes del informe con todo corregido.

Lista de estado​

• Proyecto Foundry creado en contracts/evm/
• PaymentLinkFactory + PaymentLinkReceiver + FeeSplitter implementados
• Tests de fuzzing + invariantes para la aritmética del reparto (el comercio siempre recibe ≥ lo esperado menos comisiones)
• Tests en fork de USDT / ERC-20 no estándar pasando
• Feature flag useOnChainReceiver conectado en api/src/payments
• Indexador evm-paid-event.service.ts publicado y emitiendo los webhooks existentes
• Auditoría iniciada y correcciones integradas
• Despliegue en Base mainnet desde la multisig
• Grupo canario de comercios con el flag activado

Qué sigue​

Con los comercios de Base usando receptores en contrato, la Fase 2 hace lo mismo con las suscripciones: Suscripciones por allowance.

Documentación de referencia: Estado de la Fase 1 · Referencia de contratos · Arquitectura

En resumen​

• SubscriptionHub.createSubscription(...) registra el calendario on-chain.
• El pagador firma approve(USDC, hub, cap) una vez en su wallet de siempre. Es el mismo paso que ya documentamos en Cobro automático.
• Cualquier EOA puede llamar a charge(id). Nuestro programador en NestJS lo hace por defecto; Chainlink/Gelato lo respaldarán a partir de la Fase 3.
• Protección frente a reorganizaciones mediante un lastChargedAt monótono. Sin cobros dobles.
• Los suscriptores existentes migran de forma voluntaria, en la renovación.

Qué cambia en esta fase​

Hoy, api/src/scheduler/processors/subscription-auto-charge.processor.ts usa una smart account controlada por OrcaRail para cobrar al pagador mediante el approve existente. Funciona, pero la smart account es nuestra: la confianza pasa por nosotros.

Tras la Fase 2:

El allowance sigue yendo del pagador a un contrato, pero el contrato es auditable e inmutable, y cualquiera, no solo nosotros, puede ser el keeper.

Contratos introducidos​

SubscriptionHub​

Una instancia por cadena. Superficie mínima:

function createSubscription(
    bytes32 id,
    address payer,
    IERC20 token,
    uint256 amount,
    uint64 interval,
    uint256 cap,
    Split calldata split
) external;

function charge(bytes32 id) external;        // any caller
function cancel(bytes32 id) external;        // payer only
function subscription(bytes32 id) view returns (Subscription memory);

event SubscriptionCreated(bytes32 indexed id, address indexed payer, ...);
event Charged(bytes32 indexed id, uint256 amount, uint64 nextChargeAt);
event ChargeSkipped(bytes32 indexed id, bytes32 reason);
event Canceled(bytes32 indexed id);

Invariantes que impone charge()​

• block.timestamp >= nextChargeAt: no se puede cobrar antes de tiempo.
• block.timestamp > lastChargedAt: monótono, así las reorganizaciones no pueden cobrar dos veces.
• amountCharged + amount <= cap: impone el límite de la aprobación además del allowance de ERC-20.
• token.allowance(payer, hub) >= amount: revert explícito con InsufficientAllowance para un texto de webhook claro.
• token.balanceOf(payer) >= amount: igual, con InsufficientBalance.

El Split se reutiliza de la Fase 1: el mismo FeeSplitter, la misma semántica de puntos básicos.

Cambios en la API​

El gran cambio es que api/src/scheduler/processors/subscription-auto-charge.processor.ts deja de cobrar desde nuestra smart account y pasa a llamar a SubscriptionHub.charge(id) con una EOA de keeper.

En concreto:

• La EOA del keeper es una hot wallet por cadena que solo tiene gas. No tiene ninguna autoridad sobre los fondos de los comercios.
• Si la cadena tiene una política de paymaster de Alchemy (consulta api/src/withdrawals/services/gas-strategy), el keeper usa el camino patrocinado; si no, paga con su propio saldo de gas.
• Si hay un revert, el procesador interpreta el selector del error y actualiza los mismos estados de SubscriptionAutoChargeEntity que usamos hoy (past_due, insufficient_balance, etc.).
• Los webhooks y los emails de api/src/mail/mail-templates/subscription-*.hbs se envían sin cambios.

La experiencia del pagador en pay recibe dos ajustes, ambos menores:

1. El paso approve() ahora apunta el spender a la dirección de SubscriptionHub en lugar de a nuestra hot wallet. Es un cambio de texto y un valor de configuración; el flujo que ve el pagador es idéntico.
2. Un botón de «revocar» que llama a SubscriptionHub.cancel(id) y luego pide un approve(hub, 0) on-chain para una limpieza completa. La documentación actual de revocación del cobro automático sigue siendo correcta.

Obsolescencias​

• El camino de cobro custodial en subscription-auto-charge.processor.ts: con el flag, solo se ejecuta la rama SubscriptionHub.charge.
• La smart account de OrcaRail como approval_spender_address: las suscripciones nuevas guardan en su lugar la dirección del hub.
• El campo approval_spender_address sigue en la respuesta de la API; simplemente apunta a un sitio nuevo y auditable.

Plan de migración​

Los suscriptores existentes nunca se migran a la fuerza. Ofrecemos dos caminos:

1. Al renovar: en el siguiente ciclo, un banner del panel pide al pagador que vuelva a firmar approve(hub, cap) en el nuevo SubscriptionHub. Un clic. El allowance antiguo a la hot wallet heredada se puede dejar o revocar; ya no importa.
2. Por iniciativa del usuario: un botón «Pasar a no custodial» en la página de detalle de la suscripción hace lo mismo de inmediato.

Las suscripciones que nunca migren se quedan en el camino custodial hasta su cancelación. Ese camino se desactiva en la Fase 7, con mucha antelación.

Riesgos y mitigaciones​

• Confusión del pagador en la migración. Mitigación: la plantilla de email reproduce el lenguaje del subscription-auto-charge-approved.hbs existente; banner en el panel; entrada de preguntas frecuentes en /docs/non-custodial/migration-guide.
• Una caída del keeper se salta un cobro. Mitigación: charge() no requiere permisos; cualquier instancia de Chainlink Automation o Gelato puede ser el respaldo, y también es posible un charge() manual iniciado por el comercio. Plan completo en la Fase 3.
• Cobro doble por reorganización. Mitigación: invariante monótono de lastChargedAt; test unitario con reorganizaciones en fork.
• El pagador revoca entre ciclos. Mitigación: charge() emite ChargeSkipped(AllowanceRevoked); se envía la plantilla de email existente subscription-insufficient-allowance.hbs; la suscripción pasa a past_due.
• Desviación de la lista de tokens permitidos. Mitigación: el hub solo acepta tokens con SubscriptionHub.isAllowed(token); los cambios requieren la multisig.

Lista de estado​

• SubscriptionHub implementado con todos los invariantes
• Tests de fuzzing para casos de límite, allowance, reorganización y omisión
• Auditoría incremental de SubscriptionHub completada
• EOA de keeper aprovisionada por cadena, con gas monitorizado mediante Sentry + Datadog
• La app de pago apunta el approve a SubscriptionHub
• Endpoint approve-auto-charge actualizado para aceptar allowances con el hub como spender
• Banner del panel para las suscripciones existentes
• Grupo canario migrado y estable durante 14 días

Qué sigue​

Despliegue en varias cadenas y un segundo keeper: Fase 3.

Documentación de referencia: Estado de la Fase 2 · Guía de migración · Referencia de contratos · Por qué el cobro por allowance

En resumen​

• Desplegar PaymentLinkFactory, la implementación de PaymentLinkReceiver, FeeSplitter y SubscriptionHub en Ethereum mainnet, Arbitrum, Optimism y Polygon.
• El mismo esquema de salt de CREATE2 en todas partes: la dirección de la factoría es la misma en todas las cadenas (limpio para la documentación, para las integraciones y para computeAddress desde el cliente).
• Registrar Chainlink Automation (preferido) y/o Gelato Web3 Functions como segundo keeper que llama al mismo charge(ids[]).
• Publicar SLO: 99,5 % de los cobros en los 10 minutos siguientes al vencimiento, medido.

Qué cambia en esta fase​

Varios keepers llamando al mismo charge() público es la garantía de disponibilidad. Ninguno tiene custodia; cualquiera de ellos puede salvar un cobro vencido.

Plan de despliegue​

Orden de despliegue (una cadena por semana, con canario por cadena):

1. Ethereum mainnet (chainId 1)
2. Arbitrum One (42161)
3. Optimism (10)
4. Polygon PoS (137)

Las direcciones de cada cadena se publican en /docs/non-custodial/contract-reference. La clave de despliegue es la misma multisig Safe 3 de 5 definida en la Fase 0, redesplegada en cada cadena desde la misma ceremonia.

Las cuatro cadenas comparten el mismo feature flag useOnChainReceiver, definido por chainId dentro de api/src/payments/wallet.service.ts. Los comercios lo activan cadena por cadena; el valor por defecto pasa a activado cuando la semana canaria sale limpia.

Estrategia de gas para charge()​

Las transacciones charge() del keeper necesitan gas. Reutilizamos la infraestructura de paymaster existente en api/src/withdrawals/services/gas-strategy:

• Con paymaster de Alchemy (Base, Arbitrum, Optimism, Polygon): el keeper llama a SubscriptionHub.charge() como UserOperation con patrocinio de la política. Coste de gas cero para la EOA del keeper.
• Ethereum mainnet (sin paymaster): el keeper paga con su saldo de gas en caliente. Lo recarga a diario la wallet de la plataforma y se monitoriza con una alerta de Datadog por saldo bajo.
• Gas subvencionado por el comercio (opcional): los comercios pueden definir una gas_refund_address y el keeper cobra el reembolso de ahí, siguiendo el patrón actual de soporte/comisión. Fuera del alcance del despliegue inicial.

Segundo keeper: Chainlink y Gelato​

El segundo keeper es una apuesta por la redundancia, no un sustituto. Funciona junto al programador de NestJS.

Chainlink Automation (preferido en EVM)​

• Registrar un Upkeep por cada SubscriptionHub.
• checkUpkeep() devuelve performData = abi.encode(ids[]) para todos los id con block.timestamp >= nextChargeAt (leídos de una función view).
• performUpkeep(performData) llama a charge(ids) en lote.
• Financiado con LINK desde la tesorería de la plataforma; saldo monitorizado.

Gelato Web3 Functions (alternativa)​

• Una Web3 Function en JS consulta el hub, encuentra los ID vencidos y envía una transacción charge(ids[]).
• El precio se paga a posteriori desde 1Balance de Gelato.

Cualquiera de los dos basta por sí solo; elegiremos según la experiencia operativa durante la Fase 3. Ejecutar ambos no es problema: charge() es idempotente dentro de un periodo gracias a lastChargedAt.

SLO y monitorización​

Objetivos de SLO publicados:

La monitorización se conecta a la configuración de Sentry existente documentada en la skill de flujo de trabajo de Sentry del repositorio. Alertas:

• Reverts de charge() por hora > umbral → PagerDuty
• Saldo nativo de la EOA del keeper por debajo de N gwei × gasLimit × 100 → PagerDuty
• Upkeep de Chainlink/Gelato en mal estado → aviso
• Retraso del indexador de eventos Paid > 5 min → aviso

Obsolescencias​

Igual que en las Fases 1 y 2, pero en más cadenas. Todavía no se elimina nada; la eliminación espera a la Fase 7.

Plan de migración​

• Enlaces de pago nuevos: usan receptores en contrato en cualquier cadena con el flag activado.
• Suscripciones nuevas: usan SubscriptionHub en cualquier cadena con el flag activado.
• Clientes existentes: migración voluntaria en la renovación, igual que en la Fase 2.
• Liquidación entre cadenas (Relay): superficie sin cambios; el keeper sigue llamando a los ejecutores de Relay en api/src/withdrawals/services/bridge, solo que desde una EOA sin custodia.

Riesgos y mitigaciones​

• Direcciones distintas entre cadenas. Mitigación: desplegador CREATE2 determinista (por ejemplo, 0x4e59b44847b379578588920cA78FbF26c0B4956C) con un hash de init-code fijo; las factorías comparten dirección en las cuatro cadenas.
• Límites de la política de paymaster por cadena. Mitigación: monitorización por cadena y alertas de cuota de la política al 70 % de uso.
• Cambios frecuentes en el registro de upkeeps de Chainlink. Mitigación: un upkeep por cadena; la lista de ID se lee on-chain, así que dar de alta comercios no requiere cambios en la configuración de Chainlink.
• Cobro doble entre keepers. Mitigación: lastChargedAt monótono más ChargeSkipped para duplicados; ambos keepers son idempotentes por diseño.
• Picos de gas en mainnet. Mitigación: ajuste del tamaño de lote por cadena; un techo de precio de gas por encima del cual charge() se aplaza un bloque.

Lista de estado​

• Despliegues completados en Ethereum, Arbitrum, Optimism y Polygon
• Direcciones de factoría + hub publicadas en la referencia de contratos
• Políticas de paymaster validadas por cadena
• Upkeep de Chainlink Automation activo en al menos 2 cadenas
• Panel de SLO en Datadog
• Runbook para caídas del keeper (charge() manual desde la CLI del comercio)
• Comercios canarios desplegados por cadena

Qué sigue​

Solana es la otra gran cadena que debemos hacer no custodial: Fase 4.

Documentación de referencia: Estado de la Fase 3 · Estrategia de keepers · Referencia de contratos

En resumen​

• El programa payment_link es propietario de una PDA por enlace de pago, derivada de seeds = [b"pl", link_id]. Sin keypair, sin semilla, sin barrido.
• El programa subscription usa la autoridad delegada de SPL, la misma primitiva en la que ya nos apoyamos en Cobro automático, como un allowance explícito concedido por el pagador.
• Los repartos se hacen por CPI a la misma lógica fee_splitter que construimos en EVM, adaptada a las cuentas de Solana.
• El servicio de barrido api/src/withdrawals/services/solana-withdrawal-transfer.service.ts se omite para los enlaces con el flag y se elimina en la Fase 7.

Qué cambia en esta fase​

El lado del «después» sustituye la semilla HD de api/src/payments/wallet.service.ts (la rama m/44'/501'/i'/0') por un cálculo de PDA puramente determinista.

Programas introducidos​

Nuevo paquete contracts/solana/ (Anchor).

Programa payment_link​

Cuentas por enlace:

#[account]
pub struct PaymentLink {
    pub link_id: [u8; 32],
    pub expected_mint: Pubkey,        // e.g. USDC on SOL
    pub expected_amount: u64,
    pub split: Split,
    pub created_at: i64,
    pub status: PaymentStatus,
}

Instrucciones:

• initialize(link_id, expected_mint, expected_amount, split): diferida; la llama en el primer depósito el envoltorio de tipo factoría.
• pay(link_id, amount): valida mint + importe, transfiere por CPI a la ATA de la PDA y luego reparte por CPI de forma atómica. Emite PaymentReceived { link_id, payer, amount }.
• refund(link_id): requiere la multisig y replica el reembolso de EVM.

Semillas de la PDA: [b"pl", link_id]. La PDA no tiene clave privada: firma mediante invoke_signed.

Programa subscription​

Aprovecha Approve / Revoke de SPL para delegar la autoridad. El pagador firma spl_token::approve designando la PDA del programa como delegada por hasta cap tokens. Después:

pub fn charge(ctx: Context<Charge>, id: [u8; 32]) -> Result<()>

Cualquiera puede llamarla; comprueba:

• clock.unix_timestamp >= next_charge_at
• clock.unix_timestamp > last_charged_at // monotonic
• amount_charged + period_amount <= cap
• que la autoridad delegada siga presente en la ATA del pagador

Si pasa, spl_token::transfer_checked por CPI cobra de la ATA del pagador (como delegada) y reparte por CPI.

Eventos: SubscriptionCreated, Charged, ChargeSkipped, Canceled. Tienen la misma forma que produce el indexador de EVM, así que api/src/webhooks es agnóstico.

Cambios en la API​

• La rama de Solana de WalletService.generateAddressForNetwork deja de derivar keypairs y devuelve en su lugar findProgramAddressSync(["pl", linkId], programId). No se escribe ninguna fila encryptedSeed para los nuevos enlaces de Solana.
• Un nuevo servicio indexador observa los logs del programa (webhooks de Helius o streams de Triton) y emite los eventos de webhook existentes.
• api/src/scheduler/processors/subscription-auto-charge.processor.ts añade una rama para SOL: construye una transacción charge y la firma con el keeper (camino sin gas mediante una transacción patrocinada, parecido al paymaster de la Fase 2).
• withdrawals/services/solana-withdrawal-transfer.service.ts no se llama para los enlaces con el flag.

Gas en Solana​

Las comisiones de Solana son pequeñas (normalmente 5000 lamports por firma, 0,000005 SOL). El keeper usa un saldo de SOL en caliente con el mismo patrón de alertas que en la Fase 3. Como Solana no tiene un paymaster al estilo de Alchemy, las transacciones patrocinadas usan un patrón simple de cofirmante: el keeper firma como pagador de comisiones y el pagador no necesita SOL en absoluto.

Obsolescencias​

• Derivación HD de SOL (m/44'/501'/i'/0') para enlaces nuevos: no se llama cuando el flag está activado.
• solana-withdrawal-transfer.service.ts: se omite para los enlaces con el flag.
• SolanaRelayBridgeExecutorService en api/src/withdrawals/services/bridge/solana-relay-bridge-executor.service.ts se mantiene: el puente de SOL a EVM cuando el comercio está en EVM sigue usando Relay, pero el disparador pasa al programa.

Plan de migración​

El mismo modelo voluntario que en la Fase 2:

• Enlaces de pago nuevos: direccionados por PDA.
• Suscripciones nuevas: basadas en delegación SPL.
• Suscripciones activas existentes: banner + email en la siguiente renovación para volver a delegar al nuevo programa.
• Los depósitos en curso en direcciones heredadas siguen liquidándose por el camino heredado.

Riesgos y mitigaciones​

• La delegación SPL se puede sobrescribir. Mitigación: charge vuelve a comprobar delegated_amount antes de transferir; si la comprobación falla emite ChargeSkipped(DelegateRevoked) y sigue la misma plantilla de email que el caso de allowance revocado en EVM.
• Autoridad de actualización de Anchor. Mitigación: una multisig Squads 3 de 5 es propietaria de la autoridad de actualización, con timelock. Coincide con la postura de la Safe en EVM de la Fase 0.
• SOL envuelto frente a SOL nativo. Mitigación: payment_link admite ambos, con un expected_mint explícito por enlace para evitar ambigüedades.
• Picos de comisiones de prioridad. Mitigación: cálculo dinámico de la comisión de prioridad en el keeper; reintento de respaldo con mayor prioridad tras un slot.
• Auditoría. Mitigación: auditoría de OtterSec o Neodyme de ambos programas antes del despliegue en mainnet.

Lista de estado​

• Workspace de Anchor contracts/solana/ creado
• Programa payment_link con todas las instrucciones + tests
• Programa subscription con todas las instrucciones + tests
• Indexador con webhooks de Helius publicado
• Rama de SOL del keeper en subscription-auto-charge.processor.ts
• Informe de auditoría publicado
• Despliegue en mainnet desde la multisig Squads
• Grupo canario de comercios

Qué sigue​

Bitcoin. La cadena más difícil para la no custodia, y en la que tenemos que ser honestos sobre los límites: Fase 5.

Documentación de referencia: Estado de la Fase 4 · Referencia de contratos · Arquitectura

En resumen​

• Cada enlace de pago en BTC pasa a ser una multisig taproot 2 de 2: un firmante del comercio y un firmante de la plataforma. La plataforma no puede mover fondos de forma unilateral.
• Cada depósito recibe una PSBT de reembolso prefirmada guardada off-chain, para que el pagador pueda recuperar los fondos si el comercio desaparece.
• Las xpub maestras salen del servidor de la API y pasan a un servicio HSM o MPC (por ejemplo, Lit o Turnkey). Ningún mnemónico en disco.
• Los pagos recurrentes en BTC quedan fuera del alcance hasta que Lightning BOLT12 esté listo para producción. Hoy, Cobro automático ya indica que BTC no se admite para el cobro automático, y eso sigue siendo así.

Qué cambia en esta fase​

Hoy, BitcoinHotWalletService en api/src/withdrawals/services/bitcoin-hot-wallet.service.ts deriva una dirección p2wpkh unilateral a partir de un mnemónico guardado en el servidor y la barre mediante bitcoin-withdrawal-transfer.service.ts. Es una única clave que controlamos.

Tras la Fase 5:

Ninguna parte puede gastar sola. Ningún servidor guarda una semilla unilateral.

Qué vamos a publicar​

1. Taproot 2 de 2 por enlace​

• Wallet de descriptores por enlace: wsh(multi(2, merchant_pubkey, platform_pubkey)) o un equivalente taproot (tr(NUMS, {pk(m), pk(p)}) con MuSig2 para una salida que parece de firma única, bueno para la privacidad y las comisiones).
• La clave del comercio vive en el navegador o en la extensión móvil del comercio. El flujo de alta del comercio pide una xpub; las claves por enlace se derivan de ella.
• La clave de la plataforma vive detrás de un servicio HSM o MPC. El servidor de la API nunca ve el material privado.

2. PSBT de reembolso prefirmada​

Cuando se detecta un depósito:

1. La API monta una PSBT que devuelve el depósito, menos el gas, a la dirección del pagador (capturada al crear el enlace de pago cuando se conoce la wallet del pagador; si no, se aplica la política sendback).
2. Ambos firmantes firman la PSBT de reembolso de inmediato y se guarda (cifrada) en la base de datos.
3. El comercio puede emitir el reembolso en cualquier momento con un clic; no hace falta firmar nada más.

Es el equivalente en BTC de una función refund() on-chain.

3. Rotación de claves MPC​

• Las xpub maestras de las claves de la plataforma rotan anualmente.
• Todas las claves por enlace derivadas siguen las rotaciones; los enlaces antiguos siguen funcionando porque su multisig ya está on-chain con la pubkey concreta.
• La rotación se registra en el mismo historial de auditoría que los despliegues de la multisig de la Fase 0.

Qué no vamos a publicar​

• Suscripciones / cobro automático en BTC. Hoy no hay un diseño creíble en la L1. La documentación de cobro automático actual ya excluye BTC, y eso sigue siendo correcto.
• Repartos atómicos on-chain para BTC. Los repartos ocurren en la PSBT de liquidación que firma el comercio. El reparto sigue siendo determinista y visible en la transacción emitida, pero no lo impone el script.
• Fedimint o statechains. Investigación interesante; no entra en esta fase.

Lightning como camino futuro​

Los pagos recurrentes en BTC tienen una opción realista: ofertas BOLT12 de Lightning + la extensión recurrence. Eso nos daría una solución de suscripciones en BTC comparable al approve + pull de ERC-20. Lo seguimos como una fase futura:

• Depende de implementaciones maduras de la recurrencia BOLT12 en LND y CLN.
• Depende del soporte de las wallets Lightning (Phoenix, Zeus, Blink) para la recurrencia BOLT12.
• Requiere una flota de nodos LN con liquidez suficiente; probablemente mediante un socio (Voltage, Greenlight).

Publicaremos un documento de diseño dedicado cuando las herramientas de base estén listas. Hasta entonces, BTC sigue siendo de pago único.

Obsolescencias​

• BitcoinHotWalletService: mantiene su interfaz, pero el proveedor de claves pasa a HSM/MPC. Deja de generarse la dirección de depósito p2wpkh unilateral para los enlaces nuevos.
• Las direcciones de depósito BTC heredadas se pueden seguir liquidando hasta su caducidad mediante el antiguo camino de barrido.

Plan de migración​

• Enlaces de pago BTC nuevos: direcciones multisig 2 de 2. La interfaz no cambia; el formato de dirección pasa a taproot.
• Enlaces BTC abiertos existentes: las direcciones unilaterales heredadas siguen activas hasta su caducidad; no forzamos la migración.
• Comercios sin un firmante BTC configurado: por ahora usan una multisig solo de la plataforma, con un paso de alta obligatorio para añadir una clave del comercio en un plazo de 30 días. Así se conserva el camino de reembolso y no se bloquea el volumen BTC existente.

Riesgos y mitigaciones​

• El comercio pierde su clave. Mitigación: el alta del comercio pide dos xpub (principal + respaldo); la de respaldo es opcional, pero muy recomendada.
• Caída del HSM de la plataforma. Mitigación: el HSM es redundante entre regiones; recuperación de claves de emergencia mediante una ceremonia multisig documentada en el runbook.
• Compromiso del almacenamiento de PSBT de reembolso. Mitigación: las PSBT de reembolso están cifradas en reposo con una clave KMS distinta; además, son inútiles sin que la firma del comercio se vuelva a hacer para otro destino (el destino está fijado en la PSBT prefirmada).
• Madurez de MuSig2. Mitigación: la v1 sale con un 2 de 2 explícito wsh(multi(...)); MuSig2 llegará más adelante, cuando las herramientas estén ampliamente auditadas.
• Picos en el mercado de comisiones. Mitigación: las PSBT de liquidación incluyen un gancho CPFP que el comercio puede subir; el keeper monitoriza la mempool y avisa a los comercios cuando el gas de liquidación supera un umbral.

Lista de estado​

• Plantilla de descriptor taproot finalizada
• Proveedor HSM / MPC seleccionado (Lit frente a Turnkey frente a HSM propio)
• Flujo de alta de la xpub del comercio en el panel
• Derivación y almacenamiento de descriptores por enlace
• Generación de PSBT de reembolso prefirmadas + almacenamiento cifrado
• Interfaz de cofirma de liquidaciones (firma del comercio en un clic)
• Runbook para el failover del HSM y la pérdida de claves del comercio
• Grupo canario de comercios en BTC 2 de 2

Qué sigue​

Descentralización opcional del keeper mediante EigenLayer: Fase 6.

Documentación de referencia: Estado de la Fase 5 · Consideraciones sobre Bitcoin · Modelo de seguridad

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:

1. Una conversación comercial bloqueada explícitamente por el riesgo de un «keeper de una sola parte».
2. Un marco regulatorio que reconozca la disponibilidad respaldada por un AVS como control aceptable.
3. Un deterioro significativo del precio o la disponibilidad de Chainlink Automation en nuestras cadenas más usadas.
4. 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

En resumen​

• Eliminar hd_wallet_seed, la configuración WALLET_ENCRYPTION_KEY y la lógica de derivación para las cadenas con el flag.
• Borrar los caminos de EVM/SOL en api/src/withdrawals/: SmartAccountWalletService.drainSmartAccountWallet, solana-withdrawal-transfer.service.ts y los archivos de spec relacionados.
• Mantener el camino de BTC (reducido al modelo 2 de 2 de la Fase 5).
• Actualizar los términos del servicio, la política de privacidad y los controles SOC2 para reflejar una superficie de custodia mucho menor.
• Publicar un postmortem que resuma lo aprendido.

Qué cambia en esta fase​

Antes de esta fase, el código tiene dos versiones de todo (el camino de barrido antiguo y el nuevo camino por contrato) detrás de feature flags. Después de esta fase, el camino nuevo es el único en EVM y Solana.

Qué eliminamos​

Base de datos​

• La tabla hd_wallet_seed y su entidad TypeORM en api/src/payments/infrastructure/persistence/relational/entities/hd-wallet-seed.entity.ts.
• La columna wallet_address.derivationPath se conserva para consultas históricas, pero pasa a admitir nulos; ninguna fila nueva la escribe para EVM/SOL.
• Una migración archiva las filas de semillas cifradas en almacenamiento en frío durante siete años (retención regulatoria) y luego elimina la tabla.

Código​

En api/src/payments/wallet.service.ts:

• Eliminar encryptSeed, decryptSeed, getOrCreateHDWallet, generateAddressForNetwork (ramas de EVM + SOL), getNextAvailableIndex y la importación dinámica de @account-kit/wallet-client.
• getOrCreateAddressForPaymentLink pasa a ser un envoltorio fino sobre factory.computeAddress para EVM y findProgramAddressSync para Solana.

En api/src/withdrawals/services/smart-account-wallet.service.ts:

• Eliminar drainSmartAccountWallet, transferFromSmartAccount, batchTransferFromSmartAccount, getSmartAccountClientForDepositWallet y derivePrivateKey.
• El módulo se mantiene (todavía tiene un uso pequeño para utilidades relacionadas con BTC y para leer saldos).

Otras eliminaciones:

• api/src/withdrawals/services/solana-withdrawal-transfer.service.ts
• Los archivos .spec.ts y fixtures correspondientes.
• La rama custodial de subscription-auto-charge.processor.ts (queda la rama SubscriptionHub.charge).

Configuración​

• WALLET_ENCRYPTION_KEY: se elimina de .env, de los secretos de despliegue y de la documentación.
• Cualquier material de firmante de Alchemy Account Kit en la configuración (las claves de API de @account-kit/* se mantienen si se siguen usando para el paymaster).

Qué se mantiene​

• Hot wallet de BTC: reducida al modelo multisig 2 de 2 de la Fase 5. No queda ninguna semilla HD de EVM/SOL.
• Política de paymaster de Alchemy: la usa el keeper para patrocinar charge() cuando aplica.
• Ejecutores de puente de Relay: siguen orquestando la liquidación entre cadenas; quienes llaman son EOA de keeper, no firmantes custodiales.
• Todos los webhooks, emails, facturación, panel y analíticas: sin cambios.

Actualizaciones legales y de cumplimiento​

• Términos del servicio: «OrcaRail no custodia fondos de EVM ni de Solana durante la liquidación de pagos» pasa a ser una afirmación factual, no un texto aspiracional.
• Política de privacidad: eliminar las referencias al material de semillas almacenado.
• Alcance de SOC2: los controles de custodia se reducen; los hallazgos de auditoría se mapean a la nueva superficie, más pequeña.
• Postura como transmisor de dinero: nueva revisión con asesoría legal. Menos puntos de contacto con la custodia simplifican el análisis en varias jurisdicciones.

Postmortem​

Un artículo complementario resumirá lo aprendido en las Fases 0 a 7: qué tardó más de lo esperado, qué fue mejor, cuál fue el coste real de ingeniería de la no custodia y cómo reaccionaron los comercios. Cadencia prevista: un artículo en los 30 días siguientes a la publicación de la Fase 7.

Obsolescencias (ninguna nueva)​

Esta fase es en sí misma la obsolescencia. Todos los caminos con el flag useOnChainReceiver pasan a estar activados por defecto; el flag se elimina.

Plan de migración​

Cuando se ejecute la Fase 7, todos los pagos y suscripciones nuevos llevarán más de 12 meses siendo no custodiales. La migración se centra en la cola larga de enlaces heredados:

• Enlaces de pago heredados abiertos y caducados → liquidar el polvo residual con un script de una sola vez y parar.
• Suscripciones heredadas que nunca migraron → aviso por email 30 días antes del cierre, migración en un clic en el panel y suspensión del cobro automático si no migran.
• Saldos residuales en direcciones de depósito heredadas → barrer por última vez con el antiguo camino de drenaje hacia las direcciones de retiro del comercio y luego retirar las claves.

Riesgos y mitigaciones​

• Polvo residual en direcciones antiguas. Mitigación: ejecutar un script de barrido final antes del desmantelamiento; publicar en un informe público cualquier polvo irrecuperable.
• Riesgo legal por eliminar demasiado pronto. Mitigación: archivo de 7 años de las filas de semillas cifradas (nunca descifrables sin la clave de cifrado, que se destruye en una ceremonia); los auditores pueden seguir verificando el estado histórico.
• Alguien depende de una forma de API no documentada. Mitigación: aviso público de obsolescencia con 90 días; entrada en el changelog de la API; contacto directo con los principales comercios.

Lista de estado​

• Todos los comercios de EVM + SOL en el flujo no custodial durante al menos 90 días
• Suscripciones heredadas residuales a cero
• Script de barrido final completado
• Migración de hd_wallet_seed al archivo en frío completada
• Eliminaciones de código fusionadas
• Términos del servicio + política de privacidad actualizados y publicados
• Artículo de postmortem publicado

El final de la hoja de ruta​

Tras la Fase 7, la postura de custodia es:

• EVM, Solana: no custodial. OrcaRail no guarda ningún material de semillas.
• Bitcoin: custodia reducida mediante multisig 2 de 2 con firmante del comercio.
• Momento en tránsito: eliminado en EVM/SOL; reducido a un camino de reembolso multisig en BTC.

Eso es lo que nos propusimos en la hoja de ruta no custodial.

Documentación de referencia: Estado de la Fase 7 · Modelo de seguridad · Hoja de ruta

Varios lectores preguntaron, con razón: si el objetivo es convertirse en un protocolo, ¿por qué quedarse en eliminar la custodia? ¿Cómo sería el riel si OrcaRail pudiera desaparecer mañana y los pagos siguieran fluyendo?

Este artículo es un debate. Cinco posturas defienden cinco arquitecturas distintas. Un moderador pone a prueba cada una. Nadie gana por completo, pero al final tenemos más claro qué compromisos estamos asumiendo realmente.

Qué significa exactamente «protocolo totalmente no custodial»​

Antes de empezar el debate necesitamos una definición compartida. Un sistema es un protocolo totalmente no custodial si se cumplen todas estas condiciones:

1. Custodia: ninguna parte retiene fondos de usuarios en tránsito, ni siquiera durante un bloque.
2. Disponibilidad: ninguna parte individual es imprescindible para que se produzca un pago o un cobro de suscripción legítimo.
3. Resistencia a la censura: ninguna parte individual puede denegar una transacción bien formada y pagada.
4. Control de actualizaciones / cambios: las actualizaciones requieren el consentimiento de varias partes, no el despliegue de una sola empresa.
5. Transparencia: las reglas en las que confía un usuario son totalmente legibles on-chain o bajo un hash verificable.

El plan actual cumple (1). Cumple parcialmente (3), (4) y (5). No cumple (2): el keeper y la API de OrcaRail siguen siendo necesarios para que el camino feliz funcione de forma fiable. El debate que sigue trata sobre si llevar los cuatro listones restantes hasta el final, y a qué coste.

Las posturas​

Entran cinco arquitectos. Escuchémoslos.

• Pragmático: smart contracts + API de OrcaRail (la hoja de ruta actual).
• Maximalista: protocolo on-chain puro + frontend descentralizado (el «modelo Uniswap»).
• Soberano: OrcaRail como L3 / appchain con precompilados específicos para pagos.
• Creyente en los intents: los pagadores expresan intents; una red de solvers sin permisos los liquida.
• Defensor de los estándares: un EIP abierto para enlaces de pago y suscripciones; cualquiera lo implementa.

Ronda 1: las declaraciones iniciales​

Pragmático: «Publica algo real y luego descentraliza las partes dolorosas».​

La hoja de ruta ya elimina el problema difícil (la custodia). Los keepers pueden ser cualquiera: nuestro programador en NestJS es un llamante entre varios; Chainlink y Gelato se pueden registrar mañana. El indexador es público: cualquiera puede suscribirse a los mismos eventos Paid y Charged y reconstruir el estado. La «API de OrcaRail» no es la capa de liquidación, es una capa de comodidad sobre contratos públicos. Los comercios que quieran el camino totalmente protocolario ya pueden saltarse nuestra API y llamar directamente a la factoría.

Afirmación: somos un 80 % protocolo. El 20 % restante son herramientas (wallets, paneles, email), no confianza. Las herramientas deben poder seguir iterándose.

Maximalista: «Sin API. Eventos, contratos, subgraph. Y ya».​

Uniswap existe. 1inch existe. Se accede a ellos mediante los frontends que alojan sus empresas, pero cualquiera de esos frontends podría desaparecer y el protocolo seguiría funcionando. Eso es lo que significa «protocolo».

Para OrcaRail, eso sería:

• Factorías, hubs y divisores en todas las cadenas EVM/Solana.
• Un subgraph canónico (o indexador de Solana) que cualquiera pueda consultar.
• Un frontend descentralizado fijado en IPFS/Arweave y resuelto mediante ENS (orcarail.eth). El panel del comercio y la app de pago son paquetes estáticos; cada versión está direccionada por contenido.
• Ninguna API REST de OrcaRail en el camino crítico. El SDK llama al subgraph. Los webhooks se derivan de eventos on-chain mediante indexadores como servicio (Alchemy, QuickNode, autoalojados).

Afirmación: cualquier cosa que necesite api.orcarail.com para que un pago funcione es un protocolo a medias.

Soberano: «Haz de los pagos un precompilado en nuestra propia cadena».​

Los pagos son sensibles a la latencia y repetitivos. Pagamos el mismo gas por el mismo reparto cada vez. ¿Por qué alquilamos la seguridad de una L1/L2 para un caso de uso que se puede especializar?

Lancemos OrcaRail Chain como un rollup de OP Stack (o una appchain de Cosmos, o una cadena Arbitrum Orbit). Entonces:

• La semántica de los enlaces de pago es un precompilado, no un contrato de Solidity de 80 líneas. Las comisiones pasan de céntimos a casi cero.
• La lógica del keeper se integra en la producción de bloques: el secuenciador ejecuta las llamadas charge() como parte del bloque, con penalización según la seguridad de la propia cadena.
• El puente hacia las cadenas «reales» (Ethereum, Arbitrum, Solana) usa el puente canónico existente + Relay; OrcaRail Chain es la capa de coordinación, no la capa de valor.
• Las suscripciones pasan a ser ciudadanas de primera: «suscripción» es un tipo de transacción, como «transferencia» en Bitcoin.

Afirmación: la forma más barata de que un protocolo funcione de forma fiable a escala es no compartir espacio de bloque con mints aleatorios de NFT.

Creyente en los intents: «Los pagadores expresan intenciones. Los solvers compiten por liquidarlas».​

El pagador dice: «Quiero pagar al comercio X 50 $ en USDC desde cualquiera de mis wallets, en la próxima hora, optimizando comisiones». Eso es un intent: firmado, pero todavía no es una transacción.

Una red de solvers sin permisos (al estilo CoW, SUAVE, Anoma, relayers tipo Across) ve el intent, encuentra la ruta más barata (incluidos puentes y cross-chain, desde el token que tenga el pagador) y lo liquida. Los solvers cobran una recompensa incluida en el intent.

Para las suscripciones: el pagador firma un intent recurrente («cobra 20 $/mes en USDC de mi wallet a la PDA de este comercio, durante 12 meses, cancelable en cualquier momento»). Los solvers compiten por llamar a charge() cuando vence, ganando una microcomisión. Es en lo que se convierte el «AVS de keepers» de la Fase 6 si entornas los ojos, pero con un mercado real en lugar de un esquema de slashing.

Afirmación: los keepers no son realmente un problema de fiabilidad, sino de diseño de mercado. Construyamos el mercado.

Defensor de los estándares: «Escribe un EIP. Ganamos todos, nosotros incluidos».​

Los enlaces de pago y las suscripciones de OrcaRail son una primitiva genérica. Shopify, Coinbase Commerce, otras pilas de checkout cripto alojadas y un par de docenas de startups están construyendo lo mismo. Deberíamos escribir un EIP para enlaces de pago no custodiales y un EIP complementario para suscripciones por allowance, con una implementación de referencia.

Entonces:

• Cualquier wallet puede mostrar la URL de un enlace de pago con una interfaz estándar («estás pagando al comercio X, 50 $, USDC, no custodial»).
• Cualquier indexador (The Graph, Goldsky, Envio) admite los eventos estándar desde el primer momento.
• Cualquier procesador, incluido un futuro competidor de OrcaRail, puede alojar el mismo protocolo.
• El producto de OrcaRail pasa a ser la mejor implementación de un estándar abierto, no una pila cerrada.

Afirmación: la mayor ventaja competitiva en pagos es la confianza en la primitiva, no en la pila de una empresa. Hagamos pública la primitiva.

Ronda 2: el moderador interroga​

Al Pragmático: «Sé sincero: si OrcaRail deja de pagar la factura del paymaster, ¿se sigue cobrando la suscripción de Alice?»​

Pragmático: en la hoja de ruta actual, tras la Fase 3, sí: Chainlink Automation sigue ejecutando charge(). La factura del paymaster es por el gas del keeper; Chainlink usa LINK para el mismo trabajo. Pero los comercios que necesitan el panel de OrcaRail para conciliar se verían afectados: los emails, los reintentos y los códigos de fallo legibles viven en nuestra API. Los contratos siguen funcionando; el producto no.

Moderador: ¿«Los contratos siguen funcionando, pero las personas no se enteran» es realmente disponibilidad?

Pragmático: Es disponibilidad de liquidación sin disponibilidad de experiencia de usuario. Es una distinción real: debemos asumirla, no esconderla. Además, es barato de arreglar con el tiempo: publicar nuestras plantillas de email, abrir el código del indexador, dejar que otro aloje el panel. No tenemos que hacerlo todo en la Fase 1.

Al Maximalista: «Los paneles en IPFS fijados con ENS están muy bien hasta que un regulador nos envía una carta sobre un comercio».​

Maximalista: Entonces OrcaRail deja de alojar a ese comercio en nuestro panel. El protocolo sigue dándole servicio mediante otro frontend, o el suyo propio. Es una característica, no un fallo: compáralo con las finanzas tradicionales, donde «el procesador congeló mi cuenta» es un drama recurrente sin remedio a nivel de protocolo.

Moderador: A los comercios a los que expulsa un procesador de tarjetas normalmente también los expulsa la red de Visa. En pagos, el riel y el procesador suelen ser el mismo censor.

Maximalista: Exacto, y ese es justo el problema que resuelve un protocolo. Visa no puede censurar Ethereum. OrcaRail, con una arquitectura de protocolo, no puede censurar a los comercios a nivel de riel, solo a nivel de frontend. Los frontends son intercambiables; los rieles no.

Al Soberano: «¿Cómo retiran los comercios a USDC en Ethereum si la liquidación vive en OrcaRail Chain?»​

Soberano: Igual que cualquiera sale de cualquier L2: con el puente canónico. Integraríamos Relay de forma nativa para que la salida de stablecoins sea inmediata. El volumen diario de retiros es minúsculo comparado con el volumen dentro de la cadena.

Moderador: Nos estás pidiendo que operemos una cadena. Toda cadena que importa tiene modos de fallo: paradas del secuenciador, retrasos en la publicación del state root, salidas por el puente. Esos fallos son públicos y visibles. «El secuenciador de OrcaRail lleva 3 horas caído, pagos detenidos en todo el mundo» es un titular peor que «la API de OrcaRail tuvo una caída de 3 horas».

Soberano: Es un titular peor solo hasta que descentralizas el secuenciador. Las pruebas de fraude de OP Stack y la secuenciación compartida (Espresso, Astria) hacen que esto sea cada vez menos un riesgo de una sola parte. Tienes razón en que no empezaríamos ahí. Pero también en que no deberíamos operar una cadena solos; lanzaríamos mediante un socio de rollup-as-a-service con un camino creíble hacia la secuenciación compartida.

Moderador: Son muchas dependencias.

Soberano: Lo son. El intercambio es: dejamos de pagar gas para siempre, dejamos de pelear por espacio de bloque en mainnet y podemos publicar primitivas a medida. Si el volumen de pagos es lo bastante grande para justificar algo de esto, está justificado. Si no, me equivoco.

Al Creyente en los intents: «Los mercados de solvers tienen un problema de MEV. ¿Quién protege al pagador de un solver que se queda con una parte?»​

Creyente en los intents: El intent se firma con restricciones estrictas. El importe pagado no puede superar lo que autorizó el pagador. Lo que puede variar es la ruta (qué puente, qué DEX si hace falta un swap) y el momento. Un solver malicioso no puede desviar fondos; en el peor caso, puede ser lento. La competencia lo elimina.

Moderador: La competencia baja las comisiones en las rutas de mucho volumen. ¿Y el micropago cross-chain de 5 $ de USDC a USDC que a nadie le compensa resolver?

Creyente en los intents: Es un hueco real. La respuesta son los solvers de respaldo: OrcaRail opera uno a coste. El mercado cubre el 95 % superior; nosotros cubrimos la cola larga. Con el tiempo, cadenas más baratas y mejores puentes cierran el hueco.

Moderador: O sea, que también operas un keeper, solo que lo llamas solver.

Creyente en los intents: Un keeper que es uno entre varios, compitiendo por un intent público, con un respaldo: sí. Esa es la diferencia entre «el backend de OrcaRail es el keeper» y «OrcaRail es un participante en un mercado abierto».

Al Defensor de los estándares: «Los EIP tardan años. ¿Qué hacemos mientras tanto?»​

Defensor de los estándares: Publicas primero la implementación de referencia, siguiendo tu plan actual. Después redactas el EIP en torno a lo que publicaste, no por adelantado. Así se escribieron ERC-4337, ERC-721 y ERC-20. La hoja de ruta actual es compatible con esto: la superficie de SubscriptionHub podría ser la superficie del ERC, con pequeños ajustes de nombres.

Moderador: ¿Algún riesgo en publicar tu «ventaja competitiva» como estándar?

Defensor de los estándares: La ventaja no es el contrato. La ventaja son las integraciones, los SLA, el trabajo de cumplimiento, los paneles, la entregabilidad del email y la confianza de los comercios. Nada de eso lo puede copiar un competidor leyendo un EIP. Abrir la superficie de los contratos lleva la competencia a los terrenos donde somos fuertes.

Ronda 3: dónde gana realmente cada postura​

Tras el interrogatorio, cada postura es más fuerte en dimensiones concretas. Tabla de puntuación sincera:

Ninguna fila domina. Por eso esto es un debate y no un plan de despliegue.

Ronda 4: la síntesis del moderador​

Así es como leería yo el debate, como la persona que tiene que elegir.

El Pragmático gana hoy porque el producto tiene que seguir publicándose y no podemos permitirnos parar 18 meses para reescribir la arquitectura. La hoja de ruta actual es una versión estrictamente mejor que la custodial que operamos hoy, con mejoras incrementales compatibles.

El Maximalista gana por principios y capta una restricción real: el día en que nuestra API sea la razón por la que un comercio no puede cobrar es el día en que dejamos de ser un protocolo. Esa es la presión que debe guiar cada decisión de ingeniería de las Fases 1 a 7: publicar el indexador, publicar el subgraph, fijar el panel en IPFS bajo ENS, documentar cómo autoalojarlo. La hoja de ruta del Pragmático lo hace posible, pero no lo obliga. Deberíamos obligarlo.

El Soberano gana si la escala lo justifica. Por debajo de cierto umbral de volumen, operar una cadena es una carga. Por encima, alquilar espacio de bloque de Ethereum para repartir 3 $ entre seis cada vez es absurdo. Sabremos que hemos cruzado ese umbral cuando una fracción dominante de nuestro volumen sean rutas de pagador a comercio en la misma cadena y la optimización de gas suponga un ahorro medible en la cuenta de resultados. Todavía no.

El Creyente en los intents gana en cross-chain. Los pagos son por naturaleza multiactivo y multicadena. Un flujo de pagador basado en intents («paga al comercio X, me da igual cómo») es la mejor experiencia posible para un pagador cripto. Deberíamos adoptar intents en la capa del SDK del pagador antes que en la capa de liquidación. Eso hace que los solvers existentes (Across, deBridge, Relay) encajen de forma natural sin tener que construir un mercado nuevo.

El Defensor de los estándares gana en todo donde gana el Maximalista, con menos riesgo. Escribir un EIP en torno a lo que publiquemos en las Fases 1 y 2 es gratis, útil para el ecosistema y no nos frena. Además nos da un relato creíble de «estamos construyendo un riel, no una trampa» para los comercios que evalúan rieles cripto por primera vez.

La respuesta combinada​

La síntesis aburrida pero correcta: publicar el camino del Pragmático, imponer la presión del Maximalista, adoptar intents para la experiencia del pagador, escribir un EIP por el camino y mantener al Soberano como opción de la Fase 8+ condicionada a la escala.

En concreto, estos son los compromisos incrementales sobre la hoja de ruta existente:

• M1: subgraph público desde la Fase 1. Todos los eventos Paid y Charged en un subgraph canónico que cualquiera pueda consultar. No bloquea la API.
• M2: app de pago fijada en IPFS desde la Fase 2. Cada versión está direccionada por contenido y pay.orcarail.eth se resuelve mediante ENS.
• M3: kit de autoalojamiento desde la Fase 3. Docker Compose + documentación para que cualquiera ejecute un panel compatible con OrcaRail a partir de los mismos contratos.
• M4: SDK de intents desde la Fase 3. orcarail.pay(intent) en el cliente enruta por las redes de solvers existentes (Across/Relay) para pagos cross-chain. Solver de respaldo operado por OrcaRail para la cola larga.
• M5: borrador de EIP desde la Fase 2. Coescribir el EIP de enlaces de pago con otro procesador o un equipo de wallet, usando nuestro SubscriptionHub como base.
• M6: evaluación trimestral del Soberano junto a la evaluación de EigenLayer. Disparadores: volumen de pagos por cadena, coste de gas por pago como % del valor del pago y demanda de los comercios de liquidación por debajo del céntimo.

Estas cinco incorporaciones llevan la hoja de ruta existente de «no custodial» a «no custodial, con forma de protocolo y creíblemente neutral». No ralentizan las Fases 1 a 7. Se siguen como líneas de trabajo vivas e independientes.

Se formalizan como la Línea P en el whitepaper del protocolo, que convierte M1-M5 en las fases P1-P5 y mantiene M6 (cadena propia) como una P6 opcional.

Lo que explícitamente no hacemos todavía​

• Cadena propia. No en los próximos 18 meses. Se reevalúa cada trimestre.
• Token de OrcaRail en el lanzamiento. No hay token ahora. Un futuro token de gobernanza queda reservado como opción para después de la descentralización (consulta el whitepaper del protocolo para la postura completa). Sin preventa, sin asignaciones, sin puntos.
• Camino Maximalista on-chain puro sin ninguna API. El producto necesita superficies legibles para las personas y los comercios necesitan a alguien a quien llamar cuando algo falla. Permitiremos el uso sin API, no lo exigiremos.
• Nuestra propia red de solvers. Usaremos las existentes. Puede que operemos un solver de respaldo a coste para las rutas de cola larga que ignoran los solvers existentes, pero no arrancaremos una nueva red competidora.

Dónde queda esto​

Este artículo es un complemento de la hoja de ruta no custodial, no un sustituto. La hoja de ruta sigue siguiendo las Fases 0-7. Este debate añade un sexto eje, la forma de protocolo, con el que se debe evaluar cada fase.

Si hubieras estado en el debate, envíanos tu postura. Publicaremos los contraargumentos sólidos.

Lecturas relacionadas

• La hoja de ruta no custodial de OrcaRail: la hoja de ruta canónica
• Por qué el cobro por allowance supera al escrow y a las session keys: el debate sobre el modelo de suscripciones, en el mismo formato
• Evaluación de EigenLayer: registro de decisiones complementario sobre keepers descentralizados
• Arquitectura: lo que construye realmente el camino del Pragmático

Los tres modelos​

1. Cobro por allowance (approve de ERC-20 + delegación SPL)​

El pagador firma approve(spender, cap) una sola vez en el contrato del token. Después, el spender (nuestro SubscriptionHub o el programa de Solana) llama a transferFrom (EVM) o transfiere con autoridad delegada (SOL) cuando vence un periodo. El pagador conserva la custodia; el spender puede cobrar hasta cap durante la vida de la suscripción.

Cancelación: el pagador firma approve(spender, 0) o Revoke. A partir de ahí, ningún cobro puede salir bien.

Es lo que ya usa hoy el Cobro automático. La Fase 2 traslada el spender de una hot wallet controlada por la plataforma a un contrato on-chain, pero el lado del pagador no cambia.

2. Depósito en escrow​

El pagador deposita los fondos de N periodos en un contrato de escrow por suscripción. El contrato los libera al comercio según el calendario. El pagador puede retirar el saldo no usado en cualquier momento (menos los periodos pagados).

3. Smart wallet con session keys​

El pagador usa una smart wallet ERC-4337 y concede una session key con alcance limitado al contrato de suscripción. La session key solo puede hacer lo que permite su alcance (por ejemplo, «transferir hasta X USDC cada 30 días a esta dirección»). El pagador revoca eliminando la session key.

La puntuación​

Evaluamos los tres en cinco ejes:

Por qué no escrow​

El escrow tiene el discurso más atractivo («los fondos del pagador están bloqueados en un contrato, no en una empresa»), pero la peor experiencia real:

• A los pagadores no les gusta bloquear N meses de fondos. Una suscripción de 20 $/mes con un escrow de 12 meses supone 240 $ bloqueados. Pone techo a la conversión.
• Los retiros se complican: el contrato tiene que llevar la cuenta de periodos pagados y no pagados, gestionar reembolsos parciales e impedir que el comercio toque fondos futuros.
• «Escrow que guarda fondos de clientes» tiene en varias jurisdicciones un tufo regulatorio que «allowance a un smart contract» no tiene.

Por qué no session keys​

Las session keys en smart wallets 4337 son elegantes. Pero exigen que la wallet del pagador sea una smart wallet. En 2026 la mayoría de los pagadores siguen usando EOA (MetaMask, Rabby, hardware wallets, firmantes de Safe), y los pagadores de Solana usan wallets de keypair al estilo Phantom. Obligar a darse de alta en 4337 para una suscripción mata la conversión.

Hay un camino en el que 4337 se convierte en la wallet por defecto del pagador y las session keys pasan a ser triviales. Todavía no estamos ahí.

Por qué gana hoy el cobro por allowance​

• Ningún cambio en la wallet del pagador. Funciona cualquier wallet que pueda firmar un approve de ERC-20, es decir, todas.
• Ningún fondo bloqueado. El pagador conserva la custodia; el cobro ocurre justo a tiempo.
• La revocación es universal. approve(0) o Revoke es una primitiva que ya muestra la interfaz de cualquier wallet.
• El keeper es un commodity. SubscriptionHub.charge(id) es público y sin permisos. NestJS, Chainlink, Gelato o un AVS de EigenLayer (consulta la Fase 6) pueden llamarlo.
• El relato regulatorio es más simple. La plataforma nunca retiene fondos en tránsito.

Limitaciones conocidas y cómo las mitigamos​

El cobro por allowance no es perfecto. Los inconvenientes, con honestidad:

1. Aprobaciones infinitas​

Las wallets suelen proponer por defecto valores de approve infinitos. Los contratos maliciosos con allowances infinitos vacían wallets. Nuestra mitigación: la interfaz pide explícitamente una aprobación limitada (por ejemplo, 12 × monthly_amount para una suscripción anual), muestra la cifra en dólares y ofrece el texto «cancela cuando quieras». El contrato impone cap por separado del allowance de ERC-20.

2. Revocación entre ciclos​

Un pagador puede revocar a mitad de la suscripción y el siguiente cobro fallará. Es el mismo modo de fallo que una tarjeta guardada que se cancela. Se gestiona con el webhook + email existentes: subscription-insufficient-allowance.hbs y subscription-past-due.hbs.

3. Allowance desactualizado tras un cambio de precio​

Si el comercio sube el precio a mitad de la suscripción, el cap antiguo puede quedarse corto. Se gestiona con el invariante de cap, que revierte charge(), y con la interfaz del comercio pidiendo una nueva aprobación.

4. Cobro doble por reorganización​

Un bot que aproveche una reorganización de bloques puede repetir charge(). Se gestiona con el lastChargedAt monótono de SubscriptionHub.

Qué cambia hoy para los pagadores​

Nada. El flujo actual de Cobro automático ya pide approve(spender, amount) y SPL Approve: los mismos pasos. La Fase 2 traslada el spender a la dirección de un contrato no custodial. Tu wallet muestra la misma pantalla de permisos.

Qué cambia para los comercios​

Nada en la forma de la respuesta de la API. El campo approval_spender_address del objeto auto_charge de la suscripción simplemente apunta al contrato SubscriptionHub en lugar de a una hot wallet de OrcaRail. Los webhooks se emiten en los mismos momentos.

Resumen​

El cobro por allowance gana claramente en compatibilidad de wallets y capital de trabajo, y empata o gana en todos los demás ejes. Por eso las suscripciones de OrcaRail se basan en él.

Relacionado: Fase 2: suscripciones por allowance · Documentación de cobro automático · Modelo de seguridad

Por qué suscripciones en OrcaRail​

Las suscripciones sirven para SaaS, membresías, igualas y cualquier producto que se facture en un intervalo fijo (día, semana, mes, año), con periodos de prueba, límites de ciclos y reglas de cancelación opcionales. Usas la misma autenticación de pagos que el resto de la plataforma y puedes reaccionar a los eventos del ciclo de vida con los webhooks de suscripción.

Dos formas de cobrar: enlaces de pago o cobro automático​

• send_payment_link (por defecto): en cada ciclo de facturación, el pagador recibe un enlace de pago (por email y/o flujo alojado). Paga cuando abre el enlace: es lo habitual en un checkout cripto y se combina fácilmente con las rutas de Relay y la elección de wallet.
• auto_charge: el pagador preautoriza a la hot wallet de OrcaRail para cobrar el importe del periodo en cada renovación. Tras la configuración, las renovaciones no requieren que el pagador abra un enlace nuevo cada vez, siempre que el saldo y la autorización sigan siendo válidos.

Crea y configura el cobro con POST /api/v1/subscriptions; lista, actualiza, pausa y cancela con gestionar suscripciones. Los campos completos de la petición y los ejemplos están en esas guías.

Cobro automático: cómo lo gestionamos​

1. El comercio crea una suscripción con collection_method: "auto_charge" y los campos habituales amount, interval, token_id, network_id y los datos de contacto del pagador.
2. El pagador abre la suscripción o la experiencia de pago del primer ciclo. Ve el alcance total de la aprobación (por ejemplo, la suma de los próximos cargos que le pides cubrir) y firma una autorización on-chain:
   • En cadenas EVM, es un approve(spender, amount) estándar de ERC-20 con nuestra hot wallet como spender.
   • En Solana, el paso equivalente es una delegación de token SPL de al menos el importe de un periodo a nuestra hot wallet de Solana.
3. El pagador llama al endpoint público POST /api/v1/subscriptions/:id/approve-auto-charge con el hash de la transacción del allowance (o de la delegación), payer_wallet_address, payer_network_id y payer_token_id. No hace falta la clave de API del comercio: el pagador demuestra su intención al haber firmado la transacción en la cadena.
4. OrcaRail verifica on-chain que el allowance o la delegación cubre al menos un ciclo de facturación para la hot wallet esperada antes de marcar el cobro automático como aprobado. Antes de cada cobro podemos volver a comprobar la autorización, para no confundir problemas transitorios de RPC con un allowance revocado.
5. En cada ciclo de facturación, el proceso de facturación intenta el cobro (en EVM, un flujo de tipo transferFrom del pagador a la liquidación; en Solana se usa el saldo delegado). Si sale bien, el periodo avanza; si falla repetidamente (por ejemplo, saldo insuficiente o aprobación revocada), la suscripción puede pasar a past_due y se avisa al pagador. Puedes escuchar webhooks como subscription.payment_link.payment_failed o subscription.past_due, como se describe en Cobro automático y webhooks.

Revocación y alternativa: si el pagador revoca on-chain, los cobros posteriores fallan. También puede completar POST .../revoke-auto-charge después de revocar para que registremos el estado y podamos cambiar el cobro a send_payment_link, con instrucciones por email para gestionar la suscripción y volver a pagar mediante enlaces. Los detalles están en Cobro automático y Gestionar suscripciones.

Seguridad y claridad: solo se usa para los cobros la wallet que completó la aprobación; mostramos totales y número de ciclos claros para que los pagadores sepan qué han autorizado. En planes muy largos o sin fin, considera limitar los importes aprobados y renovar la aprobación periódicamente, o quedarte con los enlaces de pago. Consulta Cobro automático.

Multichain: cómo encaja con las suscripciones​

• Ancla del comercio: cada suscripción se crea con un network_id y un token_id que definen cómo se fija el precio y se liquida en términos de API: la red y el activo «base» de ese plan.
• Contexto del pagador en el cobro automático: el cobro automático guarda payer_network_id y payer_token_id, la red y el token donde el pagador realmente definió el allowance o la delegación. Pueden diferir de los campos principales de la suscripción cuando el pagador paga desde otra cadena o activo compatible, de forma coherente con cómo las cotizaciones y el checkout resuelven las rutas del lado del pagador.
• Cobertura alineada con Relay: las redes y monedas compatibles se mantienen alineadas con Relay; cuando Relay amplía cadenas y tokens, nuestro inventario le sigue. Resumimos ese modelo en Redes y monedas compatibles: con la tecnología de Relay.
• Adónde llegan los fondos: los comercios siguen configurando direcciones de retiro por tipo de cadena (y pueden anularlas por pago cuando se admite). Para la imagen completa de los retiros multichain y las varias direcciones por cadena, consulta OrcaRail es multichain: retiros y alineación con Relay.

Resumen​

Las suscripciones en OrcaRail combinan recursos REST de suscripción con autorización no custodial del pagador para el cobro automático y pagos multichain, sin renunciar a la experiencia de pago alojada ni a las APIs que ya usas para los pagos únicos.

App de OrcaRail · Documentación · Relay

De dónde sale la lista​

No mantenemos una lista propia, curada a mano, de redes y tokens compatibles. En su lugar:

• Las redes se sincronizan desde la Chains API de Relay (api.relay.link/chains para mainnet, más las testnets). Nuestro proceso de seed crea los registros de red a partir de los datos de cadenas de Relay, incluidos los tipos de cadena EVM, Bitcoin y Solana cuando Relay los admite.
• Las monedas y tokens se sincronizan desde la Currencies v2 API de Relay (get-currencies-v2). Los tokens se insertan o actualizan por red, así cada cadena recibe el conjunto correcto de activos pagables y transferibles por puente.

Cuando Relay añade una nueva cadena o moneda, nuestro proceso de seed/actualización la incorpora. Obtienes una alineación automática con la cobertura de Relay sin trabajo de integración adicional por tu parte.

Qué significa «compatible»​

Los pagos y (cuando aplica) los puentes siguen las rutas compatibles de Relay. Actualmente Relay admite más de 69 redes blockchain de estos tipos:

• Cadenas EVM (Ethereum, Base, Polygon, Arbitrum, Optimism y muchas más)
• Bitcoin
• Solana (SVM)
• Tron

En cada cadena, el soporte de tokens puede ser "All" (tokens con liquidez de Solver o DEX) o "Limited" (solo tokens marcados con supportsBridging: true). Para la referencia oficial de rutas y tokens compatibles, consulta la documentación de Relay:

• Supported Tokens & Routes: cómo comprobar si una ruta es compatible
• Contract Addresses: direcciones de solvers y contratos por cadena

Cómo ver qué admite OrcaRail​

Usa nuestra API para obtener el conjunto actual de redes y tokens disponibles en OrcaRail:

• Redes: GET /payments/networks: lista todas las redes compatibles (puedes filtrar con ?active=true).
• Tokens por red: GET /payments/networks/:id/tokens: lista los tokens de una red concreta (usa el id de la red de la lista anterior).
• Monedas fiat/de visualización: GET /price/currencies: lista las monedas fiat compatibles para precios y cotizaciones.

Tienes todos los detalles en la documentación de Payments API: listar redes / listar tokens y Price API: listar monedas.

Resumen​

Las redes y monedas compatibles en OrcaRail funcionan con la tecnología de Relay y se actualizan automáticamente: una integración, muchas cadenas.

App de OrcaRail · Documentación · Relay

Multichain, pero no todas las cadenas (todavía)​

Hoy OrcaRail está pensado para cadenas compatibles con EVM. No admitimos Bitcoin ni Solana (ni tokens nativos de Solana) como cadenas de primer nivel en nuestros flujos de pago y retiro. Así mantenemos una superficie de integración acotada y APIs coherentes mientras crecemos.

Si tu stack es Ethereum, Base, Polygon, Arbitrum, Optimism u otras L1/L2 EVM, tienes una sola integración y una sola documentación. Sin flujos separados para Bitcoin o Solana, por ahora.

Varias direcciones de retiro por tipo de cadena​

En los retiros es donde lo «multichain» de verdad compensa. En OrcaRail puedes configurar varias direcciones de retiro por tipo de cadena.

• Control por cadena: define un destino por defecto distinto (o un conjunto de direcciones) para Ethereum, Base, Polygon, etc., para que los fondos lleguen donde quieras en cada red.
• Anulación por pago: al crear un payment intent puedes seguir pasando una withdrawal_address para enviar ese pago concreto a un vendedor o a la tesorería en la cadena correcta.
• Sin un único cuello de botella: gestiona marketplaces, SaaS o estructuras con varias entidades sin forzarlo todo por una sola cadena o una sola dirección.

Es decir: multichain significa varias redes y varios destinos de retiro por cadena, todo configurable en el panel y mediante la API.

Relay admite Bitcoin y Solana, y nosotros también (en la hoja de ruta)​

Relay admite Bitcoin y Solana (y sus tokens) como parte de su cobertura multichain. OrcaRail está diseñado para alinearse con el modelo de Relay: un enlace, muchas cadenas.

Hoy no admitimos Bitcoin ni Solana, pero nuestra arquitectura y nuestra hoja de ruta están pensadas para que cuando los añadamos, sea el mismo producto: las mismas APIs, el mismo modelo de retiros (varias direcciones por cadena) y el mismo panel. «Nosotros también» significa aquí que estamos comprometidos con la misma visión multichain que encarna Relay, incluidos Bitcoin y Solana, y que estamos creciendo en esa dirección.

Hasta entonces, tienes una experiencia multichain estable y centrada en EVM, con control total sobre adónde van los fondos en cada cadena admitida.

Resumen​

Multichain en OrcaRail significa: muchas cadenas EVM ya, varias direcciones de retiro por cadena y un camino hacia Bitcoin y Solana al ritmo de Relay.

App de OrcaRail · Documentación · Relay

Lo construimos con ayuda de la IA y con una convicción clara: los pagos cripto deben ser abiertos, transparentes y accesibles en todas las cadenas. Durante demasiado tiempo, comercios y desarrolladores han tenido que elegir entre herramientas de código abierto complejas y sin mantenimiento, o pasarelas de pago cerradas y caras que te atan a su ecosistema y cobran comisiones altas.

Creamos OrcaRail para romper ese paradigma. OrcaRail es una plataforma de pagos multichain que une la lógica de negocio Web2 con la liquidación Web3: alojada, con precios simples basados en porcentaje y un generoso plan gratuito, o autoalojada para tener soberanía total.

La filosofía: un bien público transparente​

Creemos que los rieles financieros de internet deben ser un bien público. OrcaRail alojado cuesta el 0,5 % de cada transacción completada, con tus primeras 1.000 transacciones gratis, para que podamos operar una infraestructura fiable sin dejar de ser accesibles para quienes construyen. OrcaRail autoalojado es gratis, sin comisiones de software de OrcaRail: despliégalo en tu propio hardware y paga solo lo que cueste tu infraestructura. Los SDK oficiales, el MCP y los plugins tienen licencia MIT.

Las cotizaciones de cada pago pueden incluir conceptos opcionales que tú controlas, por ejemplo una comisión de soporte configurable (porcentaje) y una comisión en las claves de API, además de comisiones de puente al enrutar entre tokens o redes. Están documentadas en nuestras guías de Comisiones y límites y son independientes del precio de la plataforma alojada.

Al mantenernos en código abierto y dejar que la comunidad mejore el producto, buscamos rieles no custodiales y de alto rendimiento, con menos riesgo de contraparte que las pasarelas cerradas: transparentes por diseño.

Si quienes construyen usan OrcaRail alojado, lo autoalojan o combinan ambos, juntos podemos hacer frente a los silos de pago opacos y de comisiones altas.

La experiencia de desarrollo: primitivas de pago conocidas​

Si sabes integrar procesadores de pago Web2 tradicionales, ya sabes usar OrcaRail. Diseñamos nuestra arquitectura para darte estados predecibles, flujos auditables y webhooks seguros ante reintentos.

• Primero las stablecoins: pon precio a tus productos en fiat (USD/EUR) y liquida al instante en USDC o USDT. Elimina el riesgo de volatilidad para tu negocio y ofrece a tus clientes un checkout fluido.
• Checkout listo para usar: usa nuestros enlaces de pago alojados, widgets integrables e interfaces compatibles con WalletConnect para ofrecer una experiencia limpia.
• Webhooks e idempotencia: mantén tu base de datos perfectamente sincronizada con la realidad on-chain. Nuestro sistema emite eventos fiables para los estados succeeded, processing y canceled, con reintentos automáticos.
• SDK de Node.js y API REST: integra una vez, conéctate en todas partes.

  npm install @orcarail/node
  

Multichain y multitoken de forma nativa​

Web3 está fragmentado, pero tu pasarela de pago no debería estarlo. Tienes una sola integración que funciona sin fricciones en todas las redes.

Hoy OrcaRail admite cadenas compatibles con EVM desde el primer momento. Pero no nos quedamos ahí: todas las cadenas compatibles con Relay están en camino. Nuestra tecnología de enrutamiento inteligente ayuda a elegir automáticamente la red más rápida o con menores comisiones para cada pago, para que tus clientes nunca abandonen un carrito por comisiones de gas desorbitadas.

Retiros dinámicos: pensados para SaaS y marketplaces​

Los negocios de internet modernos son complejos. Tanto si gestionas una plataforma SaaS como un marketplace con varios vendedores o una app de la economía de creadores, enrutar fondos a mano es una pesadilla. OrcaRail lo resuelve de forma nativa:

• Enrutamiento por pago: pasa una withdrawal_address al crear un payment intent. Cuando el cliente paga, los fondos se envían automáticamente a la wallet de ese vendedor concreto.
• Valores por defecto: para configuraciones más simples, omite la dirección y deja que los fondos se liquiden en la dirección por defecto de tu cuenta.
• Comisiones divididas: ¿gestionas una plataforma? Define un porcentaje de comisión en tus claves de API. Ganas tu parte en cada transacción, calculada de forma visible en el checkout y enviada automáticamente a tu propia dirección de retiro.

¿Qué sigue en la hoja de ruta?​

Esto es solo el primer día. A medida que crecemos, nuestro compromiso con un ecosistema abierto no hace más que crecer:

1. Más cadenas compatibles: despliegue rápido de cadenas no EVM mediante la integración con Relay.
2. Autoalojado: despliega en tu propia infraestructura para tener soberanía y privacidad, sin comisión de software por transacción por nuestra parte.
3. Herramientas avanzadas de cumplimiento: campos de metadatos opcionales e integraciones para flujos KYT/KYC sin fricciones.

Pruébalo: nota la diferencia​

Te invitamos a comprobar lo fáciles que pueden ser los pagos cripto.

• 🚀 Empieza a construir: crea una cuenta, genera una clave de API y crea tu primer enlace de pago en menos de dos minutos.
• 🎮 Prueba la demo en vivo: prueba el flujo completo, desde la creación del intent hasta la confirmación por webhook.
• 📖 Lee la documentación: explora nuestra referencia de API, las guías de los SDK y las descripciones de la arquitectura.

El futuro debe ser abierto y transparente. Construyámoslo juntos.

App de OrcaRail · GitHub · X/Twitter