Skip to main content

OrcaRail Protocol: A Whitepaper for Non-Custodial, Non-Stop, Web2-to-Web3 Payment Rails

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

April 20, 2026 — This is the OrcaRail Protocol whitepaper. It is the canonical statement of what OrcaRail is becoming: an open, credibly neutral, non-custodial, non-stop payment rail that a Web2 merchant can integrate using familiar HTTP APIs and webhooks, and a Web3 payer can use with any wallet — and that keeps settling even if OrcaRail, the company, disappears.

It extends — it does not replace — the non-custodial roadmap and the protocol debate. The non-custodial roadmap (Track N, Phases 0-7) removes custody. This whitepaper adds a parallel Track P that decentralizes the rest: indexers, frontends, standards, keepers, and governance.

Abstract​

OrcaRail Protocol is a set of on-chain primitives — payment-link factories and receivers, allowance-pull subscription hubs, fee splitters, Anchor programs on Solana, and taproot multisig descriptors on Bitcoin — together with public specifications for indexers, keepers, frontends, and SDKs that operate on top of those primitives. The protocol satisfies four invariants: non-custodial (no party holds funds in transit), non-stop (legitimate settlement continues without OrcaRail), credibly neutral (no single party can censor a well-formed paid transaction), and web2-compatible (merchants keep API keys, webhooks, and dashboards). The rollout is two parallel tracks: Track N removes custody in seven phases; Track P decentralizes indexing, frontends, standards, and settlement routing in five phases. No token exists at launch and none is planned as part of this whitepaper; a future governance token is explicitly reserved as an option for post-decentralization and would, if introduced, ship under its own whitepaper.

1. Introduction — Why a protocol, not just a product​

OrcaRail ships today as a hosted payments product with self-hosted options on the way. That is a product, not a protocol. Products can be improved; protocols can be trusted in absentia.

The non-custodial roadmap takes custody out of the path. That is necessary but not sufficient. Even without custody, a payment rail can still break if the company running it stops paying AWS bills, gets sanctioned, or simply pivots. A protocol has to keep working when those things happen.

The protocol debate walked through five architectures. The synthesis was: ship the Pragmatist path, enforce Maximalist pressure against it, adopt intents for payer UX, write standards along the way, keep own-chain as an optional future. This whitepaper is that synthesis written as commitments.

2. Design goals​

Each goal is stated with a precise, testable definition. "Does the design satisfy this?" must have a yes-or-no answer.

  1. Non-custodial — At no point during a payment or subscription charge does a wallet or account controlled by OrcaRail, a merchant's processor, or any intermediary hold the payer's funds. Test: can a regulator freeze in-flight funds by serving OrcaRail alone? No.
  2. Non-stop — If OrcaRail's servers go dark indefinitely, a legitimate due subscription charge still settles on-chain, and a payer can still complete a one-off payment. Test: after a 30-day OrcaRail outage, has any correctly-configured subscription missed a charge? No.
  3. Credibly neutral — The on-chain rules are public, immutable per-link, and applied equally. OrcaRail cannot selectively deny service at the settlement layer (only at its own frontend). Test: can an unwelcome merchant still be paid through a third-party frontend? Yes.
  4. Web2-compatible — Merchants retain the ergonomics they already have (REST endpoints, webhooks, API keys, dashboards, email). Protocolization does not require a merchant to run Ethereum tooling to accept a payment. Test: can a non-crypto-native merchant integrate in under an hour? Yes.
  5. Real P2P — Defined precisely in the next section.

A design that misses any goal is incomplete.

3. What "real P2P" means here​

Peer-to-peer is overloaded. In this protocol it has three concrete layers.

  • Settlement P2P — Payer signs; funds flow payer → on-chain contract (EVM) or program-owned PDA (Solana) or 2-of-2 multisig (Bitcoin) → merchant and fee recipients, atomically. No OrcaRail wallet is in the path. This is enforced by Track N.
  • Discovery P2P — A payment link or subscription is fully resolvable from its on-chain data plus (optionally) IPFS-pinned metadata. Any wallet, any frontend, any third-party processor can render and complete it. OrcaRail's hosted dashboard is one implementation of the rendering layer, not the registry.
  • Liveness P2P — SubscriptionHub.charge(id) and the Anchor charge instruction are public. Any EOA or solver can call them. OrcaRail's scheduler is one participant among several (Chainlink, Gelato, merchant-run, solver-run).

What "real P2P" does not mean here: we are not Lightning; we are not a direct wallet-to-wallet channel layer; we are not replacing a payment app with a DHT. OrcaRail is an on-chain protocol with off-chain UX. The P2P property comes from the impossibility of a middleman interposing on settlement, discovery, or liveness — not from avoiding on-chain rails.

4. System architecture​

At the highest level, the protocol is five layers.

The settlement layer is immutable-per-link on EVM and Solana, and per-link descriptor-derived on Bitcoin. The other four layers are swappable. A reader who wants the full technical diagram should go to /docs/non-custodial/architecture.

5. Settlement primitives​

Full reference: /docs/non-custodial/contract-reference. Summary:

  • EVM — PaymentLinkFactory (CREATE2 deterministic addresses), PaymentLinkReceiver (EIP-1167 minimal clone, immutable per link), FeeSplitter (basis-points atomic split), SubscriptionHub (allowance-pull with monotonic lastChargedAt).
  • Solana — payment_link Anchor program (PDA per link, CPI splits) and subscription Anchor program (SPL delegate authority, identical charge semantics to the EVM hub).
  • Bitcoin — 2-of-2 taproot multisig per link (merchant signer + platform signer from HSM/MPC) with pre-signed refund PSBTs. No recurring BTC until Lightning BOLT12 recurrence matures.

Every primitive is designed so that the same linkId or subscriptionId resolves to the same deterministic address on the same chain forever — no address rotation, no re-issuance, no server-held mapping.

6. Cross-chain as intents​

A protocol that treats cross-chain as "our backend calls Relay" is still a product. A protocol treats cross-chain as a payer intent:

  • The payer signs: "pay merchant X, $50 USDC, from any of my wallets on any supported chain, within 1 hour, with fees up to Y."
  • Existing solver networks — Across, Relay, deBridge, CoW-style — compete to fulfill the intent. Solvers are paid a bounty embedded in the intent.
  • For un-economic long-tail routes (small amounts, obscure chains) OrcaRail runs a fallback solver at cost so the tail still settles. The fallback is public and anyone else can run one too.

The payer signature is bounded by amount, recipient, deadline, and max fee. Worst case a malicious solver is slow; they cannot redirect funds. This is the "Intents Believer" synthesis from the protocol debate, written as a commitment.

7. Standards and interoperability​

OrcaRail's payment-link and subscription primitives are a generic rail. Their value compounds only if other processors, wallets, and indexers implement them natively.

Commitments:

  • Draft an EIP for non-custodial payment links using PaymentLinkFactory and PaymentLinkReceiver as the reference surface. Co-author with at least one other processor or wallet team to avoid the "EIP from one vendor" pattern.
  • Draft an EIP for allowance-pull subscriptions using SubscriptionHub as the reference. Monotonic lastChargedAt and the ChargeSkipped(reason) reason set are standardization targets.
  • Publish a Solana mirror via Anchor IDL and a written spec, so any Solana wallet or indexer can render a payment link from first principles.
  • Publish the canonical subgraph schema so any indexer (The Graph, Goldsky, Envio, self-hosted) can be drop-in compatible.

Writing the EIP does not reduce our moat. As argued in the debate, the moat is in integrations, compliance, SLAs, and merchant trust — none of which an EIP copies.

8. Governance​

Governance sits on two horizons.

Today and near-term​

  • EVM: 3-of-5 Safe multisig on each deployed chain. Hardware-wallet signers. Annual rotation. 48-hour timelock on proxy upgrades. Per-link PaymentLinkReceiver instances are immutable.
  • Solana: 3-of-5 Squads multisig with the same signer set and rotation policy.
  • Upgrade scope: factories and hubs sit behind UUPS proxies; per-link receivers and per-subscription records do not move under upgrades.
  • Publicly auditable: every deploy and upgrade runs as an announced multisig ceremony with signed transactions recorded.

This is the governance described in /docs/non-custodial/security-model.

Post-decentralization​

Over time the signer set stops being exclusively OrcaRail employees and becomes a public council drawn from integrators, audit firms, keeper operators, and independent contributors. Upgrade authority migrates to the council. On-chain governance becomes a live option at this point — but only as a governance mechanism, not as a speculation vehicle.

The threshold for "post-decentralization" is explicit: at least three independent production frontends hosting the rail, at least three independent keepers firing charges, and at least one non-OrcaRail processor shipping integrations. Until those are real, the protocol is not yet decentralized regardless of what governance mechanism sits on top.

9. Future governance token (explicit reservation)​

This section is deliberately short and deliberately specific.

  • No token at launch. No presale. No allocation. No points. No retroactive claims.
  • A future governance token is reserved as an option, not as a commitment. It becomes appropriate only after the post-decentralization threshold in section 8 is met and a live base of integrators, keepers, and frontends exists that would benefit from formal signaling rights.
  • If we ever introduce one, it ships under its own whitepaper, with complete transparency on distribution, lockups, supply, and governance surface. The token whitepaper would be debated publicly before issuance.
  • The token would be governance-first, not speculation-first. Mechanisms that make sense: signaling upgrade votes, parameter setting within safe bounds, keeper operator reputation. Mechanisms that do not: fee discounts tied to holdings, pay-to-pay, yield farming.
  • We will not claim the protocol is decentralized because a token exists. Decentralization is measured by the things in section 8. A token is an instrument that can formalize already-achieved decentralization; it cannot manufacture it.

This reservation is recorded in the protocol whitepaper — this document — and nowhere else. Any future change to this stance is a change to this whitepaper, published publicly, not a unilateral announcement.

10. Economics and fees — how the protocol sustains itself without a token​

The protocol's revenue model is the same as the product's, just encoded on-chain.

  • Fee split lives in the FeeSplitter basis-points configuration per payment. Same buckets the withdrawals page describes today: merchant, platform (OrcaRail's hosted share), referral/affiliate, bridge fee.
  • OrcaRail-hosted surface (dashboard, email, paymaster gas, customer support) is paid for by OrcaRail's share of the split.
  • Alternative hosts — third-party processors, self-hosted operators, IPFS-pinned frontends — can ship with a zero-platform-bps split, or configure their own fee recipient. The protocol does not privilege OrcaRail's fee over anyone else's.
  • No emission, no subsidy, no staking yield. Costs are cash costs and cash revenues. The only way the protocol gets cheaper is if gas gets cheaper or a host accepts a smaller margin — not by issuing tokens to paper over running costs.

11. Security model​

Full statement: /docs/non-custodial/security-model. Core posture:

  • Per-link receivers and per-subscription records are immutable.
  • Factories and hubs are upgradeable only through multisig + timelock.
  • Keepers are gas-only EOAs with no fund-movement authority.
  • BTC signing uses an HSM or MPC service on the platform side, plus a merchant key; no server holds unilateral spend authority.

One addition specific to protocolization: independent frontend hosts must verify contract addresses against an on-chain registry (or a signed release manifest) before rendering a payment link. A malicious clone frontend that points payments at a look-alike contract is the most likely phishing vector once the ecosystem has multiple hosts. The canonical registry lives on-chain and the verification flow is documented as part of P2.

12. Roadmap — two parallel tracks​

The protocol rollout runs as two tracks at once.

Track N is the existing roadmap, unchanged. Track P formalizes the M1-M5 commitments from the debate post as phases. Both tracks target the same end state: a rail that keeps running if OrcaRail steps away.

Track P never blocks Track N and Track N never blocks Track P. Either track can ship a phase before the other.

13. Track P phases​

Five phases, each a natural extension of an M-commitment from the debate post.

P1 — Public subgraph and open indexer​

Scope: a canonical subgraph (The Graph, Envio, or equivalent) that indexes every Paid, SubscriptionCreated, Charged, ChargeSkipped, Canceled, and Refunded event from PaymentLinkReceiver and SubscriptionHub across every deployed chain. Schema published. Self-host instructions shipped so anyone can run the same index.

Status checklist

  • Subgraph manifest + mappings for EVM chains live in Phase 1 and Phase 3
  • Solana equivalent (Helius webhooks or Triton stream) with same event shapes
  • Schema documented and stable-versioned
  • One external indexer demonstrated running the same schema against live events

P2 — Decentralized frontends (IPFS / ENS)​

Scope: pin the OrcaRail pay app and merchant dashboard to IPFS with content-addressed release bundles. Resolve via ENS (pay.orcarail.eth, app.orcarail.eth). Reproducible builds so any reader can verify the bundle matches the source. A malicious clone has to impersonate both the contract addresses and the ENS record, not just the hostname.

Status checklist

  • Pay app builds reproducibly
  • Dashboard builds reproducibly
  • ENS records pointing to IPFS CIDs
  • Release-signing ceremony from the Safe multisig
  • On-chain contract-address registry frontends verify against before rendering

P3 — Standards (draft EIP)​

Scope: draft and submit an EIP for non-custodial payment links and a companion EIP for allowance-pull subscriptions. Co-author with at least one other processor or wallet team. Reference implementation is the OrcaRail contracts. Solana mirror spec published alongside the EIPs.

Status checklist

  • Co-author confirmed
  • Payment-link EIP draft in discussion-thread state
  • Subscription EIP draft in discussion-thread state
  • Solana spec published alongside Anchor IDLs
  • EIP editor feedback incorporated through Last Call

P4 — Intent-based payer SDK​

Scope: an SDK surface (orcarail.pay(intent)) that accepts a payer-signed intent and routes it through existing solver networks (Across, Relay, deBridge) with an OrcaRail-run fallback solver for long-tail routes. Intent schema standardized in sync with P3.

Status checklist

  • Intent schema finalized
  • SDK adapter for at least two solver networks
  • Fallback solver deployed and metered
  • Payer UX in the pay app supports same-intent + cross-chain
  • Spec published as part of the Node SDK reference

P5 — Self-host / reference implementation kit​

Scope: a Docker-compose (and Helm chart) that lets anyone run an OrcaRail-compatible processor end-to-end from the public contracts. Includes subgraph, keeper, indexer, optional dashboard, and an OpenAPI specification of the processor API that others can conform to.

Status checklist

  • Docker-compose that boots against a live chain and services a test merchant
  • OpenAPI spec for the processor API
  • Helm chart for Kubernetes operators
  • End-to-end test that a self-hosted operator can process payments identical to the hosted version
  • Documentation in /docs/non-custodial/ (added in a future docs-only change; out of scope for this whitepaper)

14. Optional P6 — Own-chain evaluation​

P6 mirrors the EigenLayer evaluation pattern. It is not a commitment. It is a quarterly review with specific triggers.

Current recommendation: defer.

Triggers that would open a design doc for a Phase P6 build:

  1. Payment volume on a single chain exceeds a threshold where gas becomes a material line-item of the platform fee.
  2. A canonical L2/L3 toolchain offers specialized precompiles for payment-split semantics at near-zero cost.
  3. Merchant demand for sub-cent settlement latency that mainnet / L2 consistently cannot meet.
  4. A partner rollup-as-a-service lets OrcaRail ship with shared sequencing on day one.

If triggered, the build would prefer OP Stack with shared-sequencing (Espresso, Astria) and a credible exit bridge to the canonical chains we already support. Even then, Phases N0-N7 and P1-P5 must be mature enough that an own chain is an optimization, not a dependency.

15. What OrcaRail is today vs. what it becomes​

A before/after at the rail level.

DimensionTodayAfter Tracks N and P
Custody during a paymentOrcaRail holds the deposit wallet's keyNo custody. Payer → contract → merchant atomic splits
Subscription spenderOrcaRail-controlled smart accountPublic SubscriptionHub contract; any caller
KeeperSole NestJS schedulerNestJS + Chainlink + Gelato + optional EigenLayer AVS
IndexerInternalPublic subgraph with a documented schema
Pay app / dashboardHosted by OrcaRailHosted + IPFS/ENS copies; third-party hosts welcome
Payment-link primitiveInternal API shapeDraft EIP with reference implementation
Cross-chain settlementOrcaRail keeper calls RelayPayer intents routed by a solver market + OrcaRail fallback
GovernanceOrcaRail multisig (founders + team)Public council; on-chain governance as a real option
Regulatory surface"OrcaRail is the processor""OrcaRail is one processor among many on the same rail"
Merchant-visible APIREST + webhooksSame REST + webhooks (stable)
TokenNoneNone; reserved as a future option (section 9)

The Web2-facing surface stays stable on purpose. Merchants that integrated against the REST API in 2026 do not break in 2028.

16. Threat model​

The threats we are explicit about, with their mitigations:

  • Contract bug → multiple audits per contract; immutable per-link receivers; UUPS upgrades behind 48-hour timelock on factories and hubs; public bug bounty.
  • Keeper outage → Track N Phase 3 keeper redundancy (Chainlink/Gelato) + Track P P4 solver network + public manual charge() fallback.
  • Frontend phishing → Track P P2 on-chain contract registry + ENS content-addressing + release-signing ceremony from the Safe multisig.
  • Governance capture → Multisig signer rotation; 3-of-5 threshold; post-decentralization council drawn from independent operators; public ceremonies.
  • Regulatory action against one host → Track P P5 self-host kit + multiple independent frontends so merchants have alternate rails.
  • Subgraph or indexer drift → Canonical schema + reproducibility tests; multiple independent indexers.
  • Solver market thinness → OrcaRail fallback solver at cost; permissionless entry for new solvers.
  • BTC key loss → Backup xpub at merchant onboarding; HSM failover; pre-signed refund PSBTs keep payer recovery possible.
  • EVM reorgs → Monotonic lastChargedAt in SubscriptionHub; Solana equivalent in last_charged_at.
  • Token-induced distortion → No token at launch; explicit reservation; any future token gated on independent-operator thresholds before it can claim a governance role.

17. Open questions we are honest about​

Writing this document does not solve every question it raises.

  • When does "post-decentralization" start, precisely? Section 8 gives a threshold (three independent frontends, three independent keepers, one non-OrcaRail processor). Whether that threshold is the right one is an open debate.
  • Who pays for the public subgraph at scale? The Graph has a market; self-hosted is free but operationally heavy. Economics are not yet settled.
  • What is the exit story for a merchant whose primary frontend host disappears? P5 makes self-hosting possible; it does not make it automatic. A "migrate-my-store-to-another-host" flow is future work.
  • What does governance actually decide in a protocol with immutable per-link contracts? Upgrades to factories, parameter-setting on hubs (paused token lists, new chain deployments), fee-split defaults for OrcaRail-hosted traffic — but not much more. Whether that is enough scope to justify on-chain governance is part of the post-decentralization conversation.
  • What happens to the protocol if OrcaRail, the company, changes its mind about the reservation in section 9? Any change is a published change to this whitepaper. No unilateral, quiet pivot.

18. Conclusion — A call to builders​

The non-custodial roadmap gets the rail off custody. This whitepaper gets the rail off OrcaRail. Both need to ship for either to matter.

If you are building a wallet, a dashboard, an indexer, a solver, a compliance tool, or a rival processor — the protocol is designed to accept your contribution without asking permission. Co-author the EIP. Run the subgraph. Pin your own frontend. Run a keeper or a solver. File issues against the reference implementation. The more of Track P is done by people who do not work at OrcaRail, the more the protocol earns the word protocol.

The Web2 merchants we work with today will not notice any of this — their API keys, webhooks, and dashboards keep working. That stability is the point. We are changing the foundation of the rail, not the surface the merchants touched when they signed up.

References