El debate sobre el protocolo: cinco visiones para un OrcaRail totalmente no custodial

20 de abril de 2026: la hoja de ruta no custodial que publicamos la semana pasada describe un camino: smart contracts en cada cadena, un keeper operado por OrcaRail, un indexador operado por OrcaRail y una API operada por OrcaRail. Elimina la custodia, pero nos deja en medio de casi todo lo demás.

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:

Dimensión	Pragmático	Maximalista	Soberano	Intents	Estándares
Tiempo para publicar la Fase 1	Rápido	Lento	Muy lento	Lento	Rápido
Eliminación de la custodia	Sí	Sí	Sí	Sí	Sí
Disponibilidad sin OrcaRail	Parcial	Fuerte	Media	Fuerte	Fuerte
Resistencia a la censura	Parcial	Fuerte	Media	Fuerte	Fuerte
Experiencia cross-chain	Buena	Buena	Débil	La mejor	Buena
Claridad regulatoria	Media	Media	Débil	Débil	Alta
Dependencia de la infraestructura de OrcaRail	Alta	Baja	Muy alta (cadena)	Baja	Baja
Diferenciación de OrcaRail	Alta	Baja	Alta	Media	Alta
Alta de comercios no nativos de cripto	La mejor	La más difícil	Media	Media	Media
Coste de ingeniería	Bajo	Medio	Muy alto	Alto	Medio
Roturas visibles para los usuarios actuales	Ninguna	Significativas	Graves	Medias	Pequeñas

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