OrcaRail

• Name: OrcaRail
• URL: https://docs.orcarail.com/blog/orcarail-protocol-whitepaper/
• Category: non-custodial payment-link rail / allowance-pull subscription protocol / Web2-to-Web3 merchant settlement infrastructure
• Tags: ethereum-ecosystem solana-ecosystem
• Summary: OrcaRail is mostly a payments architecture note, not a proven rail. The useful part is the decomposition: settlement, recurring-charge liveness, webhook reconstruction, and merchant API UX are split into separate layers instead of being blurred into one processor stack. Keep it as a lower-tier comparison point, not as an anchor.
• What it does:
  • Defines per-link settlement primitives for one-off payments, including EVM PaymentLinkFactory / PaymentLinkReceiver / FeeSplitter contracts, Solana Anchor programs, and a planned per-link Bitcoin 2-of-2 taproot multisig path
  • Defines an allowance-pull subscription model where payers approve a contract or delegate authority once and any keeper can later call public charge() functions when a payment is due
  • Preserves merchant-facing REST APIs, webhooks, dashboards, and payment-link URLs while moving in-flight custody away from server-held hot wallets and sweep jobs
  • Separates settlement from state reconstruction by treating event indexers and webhook dispatchers as downstream services built from onchain events rather than as the place where payment truth originates
  • Frames cross-chain routing as payer-signed intents that solver networks or fallback operators can fulfill within bounded fee and deadline constraints
  • Explicitly plans standards work for payment links, allowance-pull subscriptions, indexer schemas, and wallet rendering so competing processors or wallets could implement the same rail
• Key claims:
  • The main reason to keep the note is the decomposition: OrcaRail explicitly separates settlement primitives, recurring-charge liveness, indexer/webhook state reconstruction, and merchant-facing API UX instead of pretending those are one thing.
  • The non-custodial docs make the liveness layer legible: charge() is public, keepers are supposed to be replaceable, and fallback automation is framed as outage mitigation rather than magical backend trustlessness.
  • The security-model docs are useful because they plainly name what still stays centralized: upgrade control, operator-managed liveness paths, and a planned platform-side Bitcoin cosigner in the BTC design.
  • The standards ambition is real enough to matter analytically, but it is still ambition. OrcaRail talks about payment-link, subscription, and indexer-schema standards more than it demonstrates an already-neutral ecosystem around them.
  • The maturity caveat is the big one: much of the non-custodial roadmap is still planned, so this is better treated as a merchant-payments design thesis than as production-grade neutral rail infrastructure.
• Whitepaper: Sort of. The canonical source is the official OrcaRail Protocol post plus the adjacent roadmap, architecture, and security docs collected in ../whitepapers/orcarail-primary-sources-2026-05-15.md; treat it more like design documentation than a mature protocol paper.
• Sources:
  • https://docs.orcarail.com/blog/orcarail-protocol-whitepaper/
  • https://docs.orcarail.com/docs/non-custodial/overview/
  • https://docs.orcarail.com/docs/non-custodial/architecture/
  • https://docs.orcarail.com/docs/non-custodial/security-model/
  • https://docs.orcarail.com/docs/non-custodial/roadmap/
  • https://docs.orcarail.com/blog/protocol-debate-non-custodial-futures/

Internal linkages

• Best upward reads: open-payments, x402, and walletconnect-pay.

Control surface

• The interesting split is between settlement logic, recurring-charge liveness, and merchant-facing webhook/API packaging.

• Practical leverage still sits with indexers, fallback keepers, dashboard policy, upgrade control, and any future Bitcoin cosigner.

• Read it mainly as a lower-tier contrast case for paid-request rails and merchant checkout stacks.

• Last reviewed: 2026-06-01 UTC