Saltar al contenido principal

Protocolo OrcaRail: whitepaper de unos rieles de pago no custodiales, ininterrumpidos y de Web2 a Web3

· 23 min de lectura
OrcaRail
OrcaRail
Crypto payment rails for web2 apps

20 de abril de 2026: este es el whitepaper del Protocolo OrcaRail. Es la declaración canónica de en qué se está convirtiendo OrcaRail: un riel de pagos abierto, creíblemente neutral, no custodial e ininterrumpido que un comercio Web2 puede integrar con las APIs HTTP y los webhooks de siempre, y que un pagador Web3 puede usar con cualquier wallet; y que sigue liquidando aunque OrcaRail, la empresa, desaparezca.

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.

DimensiónHoyTras las Líneas N y P
Custodia durante un pagoOrcaRail guarda la clave de la wallet de depósitoSin custodia. Pagador → contrato → comercio con repartos atómicos
Spender de las suscripcionesSmart account controlada por OrcaRailContrato público SubscriptionHub; cualquiera puede llamarlo
KeeperUn único programador en NestJSNestJS + Chainlink + Gelato + AVS de EigenLayer opcional
IndexadorInternoSubgraph público con un esquema documentado
App de pago / panelAlojados por OrcaRailAlojados + copias en IPFS/ENS; alojamientos de terceros bienvenidos
Primitiva de enlace de pagoForma interna de la APIBorrador de EIP con implementación de referencia
Liquidación entre cadenasEl keeper de OrcaRail llama a RelayIntents del pagador enrutados por un mercado de solvers + respaldo de OrcaRail
GobernanzaMultisig de OrcaRail (fundadores + equipo)Consejo público; gobernanza on-chain como opción real
Superficie regulatoria«OrcaRail es el procesador»«OrcaRail es un procesador entre muchos en el mismo riel»
API visible para el comercioREST + webhooksLos mismos REST + webhooks (estables)
TokenNingunoNinguno; reservado como opción futura (sección 9)

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