The OrcaRail Non-Custodial Roadmap
April 20, 2026 — Today we are publishing the full roadmap for moving OrcaRail from its current custodial sweep model (we generate a deposit address per payment link, then sweep and split funds) to a non-custodial smart-contract model (funds land in a per-link contract that splits and settles atomically, and subscriptions pull from a payer-controlled allowance).
This post is the index. Each phase has its own deep-dive post and a living docs page, so you can deep-link to exactly the part you care about.
Why we are doing this
The current flow works, but it has a simple structural problem: between deposit and settlement, OrcaRail holds the funds. That is true even though we never hold merchant operating balances — the in-flight moment between "payer sent" and "merchant received" is custodial. Removing that moment is a security, compliance, and reliability win.
Concretely, the legacy path looks like:
The target is:
Funds never pass through a wallet we control. Splits happen on-chain. Subscriptions pull from an allowance the payer can revoke at any time.
What is changing, in one page
| Area | Before | After |
|---|---|---|
| Payment link addresses | HD-derived EOA or Alchemy smart account per link | Deterministic CREATE2 on EVM; PDA on Solana — no key material stored by OrcaRail |
| Settlement | Sweep transaction after observation | Atomic split inside the receiver on the pay transaction |
| Subscriptions | Custodial pull from merchant-funded wallet | Payer signs ERC-20 approve or SPL delegate; keeper calls charge(id) |
| Keeper | Single NestJS scheduler | NestJS primary + Chainlink Automation or Gelato fallback (+ optional EigenLayer) |
| Cross-chain | Relay bridge executed by keeper | Same Relay route, but as an on-chain call from a non-custodial receiver |
| Bitcoin | Hot wallet with server-held xpub | 2-of-2 taproot multisig per link (merchant + platform) with pre-signed refunds |
The roadmap
Each phase is self-contained and shippable. Early phases remove custody for the largest volumes (EVM payments and subscriptions) and later phases tackle the harder chains and optional decentralization.
- Phase 0: Designing a non-custodial payment stack — fee/split spec freeze, chain selection, audit vendor, deployer multisig, the subscription-model decision matrix.
- Phase 1: Contract-based payment links on EVM —
PaymentLinkFactory+PaymentLinkReceiver+FeeSplitter, deterministic addresses, event indexer. - Phase 2: Allowance-pull subscriptions —
SubscriptionHub, new payer flow, keeper replacing the custodial auto-charge processor. - Phase 3: Multi-EVM rollout and keeper redundancy — Ethereum, Arbitrum, Optimism, Polygon + Chainlink/Gelato fallback.
- Phase 4: Non-custodial Solana with Anchor PDAs —
payment_linkandsubscriptionAnchor programs, SPL delegate auto-charge. - Phase 5: Bitcoin — taproot 2-of-2 and honest scope — reduced custody, pre-signed refunds, Lightning BOLT12 as future work.
- Phase 6: Decentralized scheduler and EigenLayer — when an AVS helps and when it does not.
- Phase 7: Retiring the custody infrastructure — dropping
hd_wallet_seed, removing sweep paths, updating TOS.
A companion post, Why allowance-pull beats escrow and session keys, explains how we picked the subscription model.
What this means in practice
For merchants: after Phase 1, nothing changes in the API — payment-link URLs and webhooks behave the same. Withdrawal rules move from "settle after sweep" to "emit on pay". You get a faster, cheaper, more auditable path without code changes. Phase 2 adds a new public endpoint for payers to register their on-chain approve, matching the flow documented in Auto-charge.
For payers: one-off payments feel identical. Subscriptions add one extra signature at setup (the on-chain approve) and a clearer "revoke" path: revoke on-chain, and OrcaRail stops trying. Your funds never leave your wallet until the contract pulls them, and never sit in a wallet we control.
For integrators: API shape stays stable. New fields (contract addresses, deployment chain, allowance metadata) are additive, behind a feature flag per chain. Existing integrations keep working through their current renewal cycle and migrate on opt-in.
What stays custodial (for now)
Bitcoin. We will reduce custody materially in Phase 5 by moving every link to a 2-of-2 taproot multisig with a merchant signer, plus pre-signed refund PSBTs. But Bitcoin L1 does not have the contract expressiveness to eliminate custody outright today. BTC subscriptions remain out of scope until Lightning BOLT12 recurring payments are ready.
Timeline and status
The full plan is tracked at /docs/non-custodial/roadmap and each phase has a status page:
- Planned: 0 — 7
- In progress: none yet
- Shipped: none yet
We will publish a dated update post each time a phase ships.
Read the architecture docs
For the reference version of all of this — architecture diagrams, contract surface, migration guide, security model — start at /docs/non-custodial/overview.