OrcaRail Developer Packages Are Open Source
July 31, 2026 — OrcaRail's developer packages are now open source under the MIT license. You can use them freely, open issues when something breaks or is missing, and contribute improvements when you can.
July 31, 2026 — OrcaRail's developer packages are now open source under the MIT license. You can use them freely, open issues when something breaks or is missing, and contribute improvements when you can.
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.
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.
April 20, 2026 — Before we write a line of Solidity, we freeze the spec. Phase 0 is the design and sign-off phase of the non-custodial roadmap: what moves on-chain, what does not, which chain ships first, who audits the contracts, and who holds the deployer keys.
April 20, 2026 — Phase 1 is the real engineering start of the non-custodial roadmap. We replace per-link HD-derived EOAs and Alchemy smart accounts with a factory + minimal-clone receiver pattern on EVM. Funds are split atomically on the pay transaction; no sweep, no custody.
April 20, 2026 — Phase 2 moves recurring billing to an on-chain SubscriptionHub. The payer signs one approve in their wallet, and anyone (including our keeper) can call charge(id) when a period is due. Funds move directly from the payer to the merchant splits — OrcaRail never holds them.
April 20, 2026 — Phase 4 brings the non-custodial model to Solana. Two Anchor programs replace the per-link HD-wallet + sweep flow: payment_link for one-off payments and subscription for SPL-delegate auto-charge. No mnemonic lives on our servers for new Solana links.
April 20, 2026 — Bitcoin is the chain where we have to be honest. The L1 script surface does not have the expressiveness of EVM or Solana, so the "payment-link contract that splits atomically" pattern does not translate. What we can do is reduce custody from "OrcaRail holds the xpub" to "two-signer multisig with a merchant signer and a pre-signed refund," and push recurring payments to a future Lightning path.
April 20, 2026 — Phase 6 is the phase where we explicitly do not build something, unless a real requirement forces it. EigenLayer restaking is powerful, but it is not a general-purpose home for "a payment system." This post explains what an AVS would give us, when it is worth building, and why Chainlink + NestJS is sufficient for most of what we need.