Skip to main content

The Protocol Debate: Five Visions for a Fully Non-Custodial OrcaRail

· 14 min read
OrcaRail
OrcaRail
Crypto payment rails for web2 apps

April 20, 2026 — The non-custodial roadmap we published last week describes one path: smart contracts on each chain, an OrcaRail-run keeper, an OrcaRail-run indexer, and an OrcaRail-run API. It removes custody but keeps us in the middle of almost everything else.

Several readers — rightly — asked: if the goal is to become a protocol, why stop at removing custody? What would the rail look like if OrcaRail could go dark tomorrow and payments kept flowing?

This post is a debate. Five positions argue for five different architectures. A moderator pokes at each. Nobody wins outright, but by the end we are clearer about which trade-offs we are actually making.

What "fully non-custodial protocol" means, precisely​

Before the debate starts, we need a shared definition. A system is a fully non-custodial protocol if all of these hold:

  1. Custody: no party holds user funds in transit, not even for a block.
  2. Liveness: no single party is required for a legitimate payment or subscription charge to happen.
  3. Censorship-resistance: no single party can deny a well-formed, paid transaction.
  4. Upgrade / change control: upgrades require multi-party consent, not a single company's deploy.
  5. Transparency: the rules a user is trusting are fully readable on-chain or under verifiable hash.

The current plan clears (1). It partially clears (3), (4), (5). It does not clear (2) — OrcaRail's keeper and API are still required for the happy path to fire reliably. The debate below is about whether to push the remaining four bars all the way, and at what cost.

The positions​

Five architects walk in. Let's hear them.

  • Pragmatist — Smart contracts + OrcaRail API (current roadmap).
  • Maximalist — Pure on-chain protocol + decentralized frontend (the "Uniswap model").
  • Sovereign — OrcaRail as an L3 / appchain with payment-specific precompiles.
  • Intents Believer — Payers express intents; a permissionless solver network settles them.
  • Standards Advocate — An open EIP for payment links and subscriptions; anyone implements.

Round 1 — The opening statements​

Pragmatist: "Ship something real, then decentralize the painful parts."​

The roadmap already removes the hard problem (custody). Keepers can be anyone — our NestJS scheduler is one caller among several; Chainlink and Gelato can be registered tomorrow. The indexer is public: anyone can subscribe to the same Paid and Charged events and rebuild state. The "OrcaRail API" is not the settlement layer, it is a convenience layer on top of public contracts. Merchants who want the fully-protocol path can already skip us and call the factory directly.

Claim: we are 80% protocol. The remaining 20% is tooling (wallets, dashboards, email), not trust. Tooling should stay iterable.

Maximalist: "No API. Events, contracts, subgraph. That's it."​

Uniswap exists. 1inch exists. They are accessed via the frontends their companies host, but any of those frontends could go dark and the protocol would keep working. That is what "protocol" means.

For OrcaRail, that looks like:

  • Factories, hubs, splitters on every EVM/Solana chain.
  • A canonical subgraph (or Solana indexer) anyone can query.
  • A decentralized frontend pinned to IPFS/Arweave, resolved via ENS (orcarail.eth). The merchant dashboard and pay app are static bundles; every release is content-addressed.
  • No OrcaRail REST API in the critical path. The SDK calls the subgraph. Webhooks are derived from on-chain events by indexer-as-a-service (Alchemy, QuickNode, self-hosted).

Claim: anything that requires an api.orcarail.com for a payment to work is a partial protocol.

Sovereign: "Make payments a precompile on our own chain."​

Payments are latency-sensitive and repetitive. We pay the same gas for the same split every time. Why are we renting L1/L2 security for a use case that can be specialized?

Launch OrcaRail Chain as an OP Stack rollup (or a Cosmos appchain, or an Arbitrum Orbit chain). Then:

  • Payment-link semantics are a precompile, not an 80-line Solidity contract. Fees go from cents to ~zero.
  • Keeper logic is baked into block production: the sequencer fires charge() calls as part of the block, slashable by the chain's own security.
  • Bridging to "real" chains (Ethereum, Arbitrum, Solana) uses the existing canonical bridge + Relay; OrcaRail Chain is the coordination layer, not the value layer.
  • Subscriptions become first-class — "subscription" is a transaction type, like "transfer" on Bitcoin.

Claim: the cheapest way to make a protocol work reliably at scale is to not share a block space with random NFT mints.

Intents Believer: "Payers express intent. Solvers compete to settle."​

The payer says: "I want to pay merchant X $50 in USDC from any of my wallets, within the next hour, optimizing for fees." That's an intent, signed but not yet a transaction.

A permissionless solver network (CoW-style, SUAVE, Anoma, Across-style relayers) sees the intent, finds the cheapest route — including bridging, cross-chain, from whatever token the payer holds — and settles it. Solvers are paid a bounty embedded in the intent.

For subscriptions: the payer signs a recurring intent ("pull $20/month of USDC from my wallet to this merchant PDA, for 12 months, cancellable anytime"). Solvers compete to call charge() when due, earning a micro-fee. This is what Phase 6's "keeper AVS" becomes if you squint, but with a real market instead of a slashing scheme.

Claim: keepers aren't really a reliability problem — they're a market-design problem. Build the market.

Standards Advocate: "Write an EIP. Everyone wins, including us."​

OrcaRail's payment links and subscriptions are a generic primitive. Shopify, Coinbase Commerce, other hosted crypto checkout stacks, and two dozen startups are building the same thing. We should write an EIP for non-custodial payment links and a companion EIP for allowance-pull subscriptions, with a reference implementation.

Then:

  • Any wallet can render a payment-link URL with a standard UI ("you are paying merchant X, $50, USDC, non-custodial").
  • Any indexer (The Graph, Goldsky, Envio) supports the standard events out of the box.
  • Any processor — including a future OrcaRail competitor — can host the same protocol.
  • OrcaRail's product becomes the best implementation of an open standard, not a locked-in stack.

Claim: the biggest moat in payments is trust in the primitive, not in one company's stack. Make the primitive public.

Round 2 — The moderator cross-examines​

To Pragmatist: "Be honest — if OrcaRail stops paying the paymaster bill, does Alice's subscription still charge?"​

Pragmatist: In the current roadmap, after Phase 3, yes — Chainlink Automation keeps firing charge(). The paymaster bill is for keeper gas; Chainlink uses LINK for the same job. But merchants who need OrcaRail's dashboard to reconcile would degrade: emails, retries, human-readable failure codes all live in our API. The contracts keep running; the product doesn't.

Moderator: Is "contracts keep running but humans can't tell" really liveness?

Pragmatist: It's settlement liveness without UX liveness. That's a real distinction — we should own it, not hide it. It's also cheap to fix over time: publish our email templates, open-source the indexer, let someone else host the dashboard. We don't have to do all of that in Phase 1.

To Maximalist: "ENS-pinned IPFS dashboards are great until a regulator sends us a letter about a merchant."​

Maximalist: Then OrcaRail stops hosting that merchant on our dashboard. The protocol keeps serving them via another frontend, or their own. That is feature, not bug — compare TradFi, where "the processor froze my account" is a recurring drama that has no protocol-level remedy.

Moderator: Merchants who get off-boarded from a card processor usually also get off-boarded from Visa's network. In payments, the rails and the processor are often the same censor.

Maximalist: Correct, and that is exactly the problem a protocol solves. Visa cannot censor Ethereum. OrcaRail, on a protocol architecture, cannot censor merchants at the rail level — only at the frontend. Frontends are swappable; rails are not.

To Sovereign: "How do merchants withdraw to USDC on Ethereum if settlement lives on OrcaRail Chain?"​

Sovereign: Same way anyone leaves any L2: the canonical bridge. We'd integrate Relay natively so the exit is immediate for stables. The daily withdrawal throughput is tiny compared to the in-chain volume.

Moderator: You're asking us to run a chain. Every chain that matters has failure modes — sequencer halts, state-root posting lag, bridge exits. Those fail publicly and visibly. "OrcaRail sequencer offline for 3 hours, payments halted globally" is a worse headline than "OrcaRail API had a 3-hour outage."

Sovereign: It's a worse headline only until you decentralize the sequencer. OP Stack's fault-proofs and shared sequencing (Espresso, Astria) make this progressively less of a single-party risk. You're right that we're not starting there. But you're also right that we shouldn't run a chain alone; we'd launch via a partner rollup-as-a-service with a credible path to shared sequencing.

Moderator: That is a lot of dependencies.

Sovereign: It is. The trade is: we stop paying gas forever, we stop fighting for mainnet blockspace, and we get to ship custom primitives. If payment volume is large enough to justify any of this, it's justified. If it's not, I'm wrong.

To Intents Believer: "Solver markets have an MEV problem. Who protects the payer from a solver that skims?"​

Intents Believer: The intent is signed with strict constraints. Amount paid cannot exceed what the payer authorized. What can vary is the route (which bridge, which DEX if a swap is needed) and the timing. A malicious solver cannot redirect funds; at worst, they can be slow. Competition drives that out.

Moderator: Competition drives fees low on high-volume routes. What about the $5 USDC → USDC cross-chain micropayment nobody is paid enough to solve?

Intents Believer: That's a real gap. The answer is fallback solvers — OrcaRail runs one at cost. The market handles the top 95%; we handle the long tail. Over time, cheaper chains and better bridges close the gap.

Moderator: So you're also running a keeper, just calling it a solver.

Intents Believer: A keeper that is one of several, competing on a public intent, with a fallback — yes. That is the difference between "OrcaRail's backend is the keeper" and "OrcaRail is a participant in an open market."

To Standards Advocate: "EIPs take years. What do we do until then?"​

Standards Advocate: You ship the reference implementation first, using your current plan. Then you draft the EIP around what you shipped, not in advance. That's how ERC-4337, ERC-721, and ERC-20 got written. The current roadmap is compatible with this — the SubscriptionHub surface could be the ERC surface, with small naming adjustments.

Moderator: Any risk in publishing your "moat" as a standard?

Standards Advocate: The moat isn't the contract. The moat is integrations, SLAs, compliance work, dashboards, email deliverability, merchant trust. All things a competitor can't copy by reading an EIP. Open-sourcing the contract surface moves competition to the places where we are strong.

Round 3 — Where each position actually wins​

After the cross-examination, each position is stronger in specific dimensions. Honest scorecard:

DimensionPragmatistMaximalistSovereignIntentsStandards
Time to ship Phase 1FastSlowVery slowSlowFast
Custody eliminationYesYesYesYesYes
Liveness without OrcaRailPartialStrongMediumStrongStrong
Censorship-resistancePartialStrongMediumStrongStrong
Cross-chain UXGoodGoodWeakBestGood
Regulatory clarityMediumMediumWeakWeakHigh
Dependency on OrcaRail infraHighLowVery high (chain)LowLow
OrcaRail's differentiationHighLowHighMediumHigh
Onboarding for non-crypto-native merchantsBestHardestMediumMediumMedium
Engineering costLowMediumVery highHighMedium
Existing user-visible breakageNoneSignificantMajorMediumSmall

No row is dominant. Which is why this is a debate and not a rollout plan.

Round 4 — Moderator's synthesis​

Here is how I would actually read the debate, as the person who has to pick.

Pragmatist wins today because the product has to keep shipping and we do not have the luxury of pausing for an 18-month architecture rewrite. The current roadmap is a strictly-better-than-custodial version of what we run today, with compatible incremental improvements.

Maximalist wins on principle and captures a real constraint: the day our API is the reason a merchant cannot get paid is the day we stop being a protocol. That is the pressure that should guide every Phase 1-7 engineering decision: publish the indexer, publish the subgraph, pin the dashboard to IPFS under ENS, document how to self-host. The Pragmatist roadmap makes this possible, it does not force it. We should force it.

Sovereign wins if scale justifies it. Below some volume threshold, running a chain is overhead. Above it, renting Ethereum block space to split $3 six ways every time is absurd. We will know we've crossed that threshold when a dominant fraction of our volume is same-chain merchant-to-payer routes and gas optimization is measurable line-item savings. Not yet.

Intents Believer wins on cross-chain. Payments are inherently multi-asset, multi-chain. An intent-based payer flow ("pay merchant X, I don't care how") is the best UX possible for a crypto payer. We should adopt intents at the payer-SDK layer before we adopt them at the settlement layer. That makes existing solvers (Across, deBridge, Relay) a natural fit without requiring us to build a new market.

Standards Advocate wins everywhere Maximalist does, with less risk. Writing an EIP around what we ship in Phases 1 and 2 is free, helpful for the ecosystem, and does not slow us down. It also gives us a credible "we are building a rail, not a trap" story for merchants evaluating crypto rails for the first time.

The blended answer​

The boring-but-correct synthesis: ship Pragmatist, enforce Maximalist, adopt Intents for payer UX, write an EIP along the way, keep Sovereign as a Phase 8+ option conditional on scale.

Concretely, what that means as incremental commitments on top of the existing roadmap:

  • M1: Public subgraph from Phase 1. Every Paid and Charged event in a canonical subgraph anyone can query. Non-blocking for the API.
  • M2: IPFS-pinned pay app from Phase 2. Every release is content-addressed, pay.orcarail.eth resolvable via ENS.
  • M3: Self-host kit from Phase 3. Docker-compose + docs that let anyone run an OrcaRail-compatible dashboard from the same contracts.
  • M4: Intent SDK from Phase 3. orcarail.pay(intent) on the client routes through existing solver networks (Across/Relay) for cross-chain payments. OrcaRail-run solver fallback for the long tail.
  • M5: EIP draft from Phase 2. Co-author the payment-link EIP with another processor or a wallet team, using our SubscriptionHub as the basis.
  • M6: Sovereign evaluation quarterly alongside EigenLayer evaluation. Triggers: payments volume by chain, gas cost per payment as % of payment value, demand from merchants for sub-cent settlement.

These five additions take the existing roadmap from "non-custodial" to "non-custodial, protocol-shaped, credibly neutral." They do not slow down Phases 1-7. They are tracked as separate living workstreams.

They are formalized as Track P in the protocol whitepaper, which turns M1-M5 into phases P1-P5 and keeps M6 (own-chain) as an optional P6.

What we are explicitly not doing yet​

  • Own chain. Not in the next 18 months. Re-evaluate quarterly.
  • OrcaRail token at launch. No token now. A future governance token is reserved as an option for post-decentralization (see the protocol whitepaper for the full stance). No presale, no allocation, no points.
  • Pure on-chain Maximalist path with no API at all. The product needs human-readable surfaces, and merchants need someone to call when things go wrong. We will enable API-free usage, not require it.
  • Our own solver network. Use existing ones. We may run a fallback solver at cost for the long-tail routes existing solvers ignore, but we will not bootstrap a new competing network.

Where this lands​

This post is a companion to the non-custodial roadmap, not a replacement. The roadmap still tracks Phases 0-7. This debate adds a sixth axis — protocol-shape — that every phase should be evaluated against.

If you were in the debate, send us your position. We will publish strong counter-arguments.

Related reading