Used for the project’s invariant framing (non-custodial, non-stop, credibly neutral, web2-compatible), Track N / Track P split, standards ambitions, and post-decentralization threshold
Used to confirm the legacy custodial sweep model, the target per-link contract/program architecture, and the claim that merchant APIs and payment-link UX remain stable while custody moves under the hood
Used to confirm the specific component split across PaymentLinkFactory, PaymentLinkReceiver, FeeSplitter, SubscriptionHub, Solana Anchor programs, BTC multisig paths, and the event indexer
Used to confirm what remains centralized after the transition: 3-of-5 Safe / Squads control, 48-hour timelock on EVM proxies, keeper EOAs as gas-only callers, and a platform-side Bitcoin cosigner in the planned BTC path
Used to confirm the project’s own decomposition between settlement liveness, UX liveness, standards, frontends, solver markets, and appchain alternatives
Key takeaways from primary sources
OrcaRail’s most useful contribution is not that it wants to accept stablecoin payments; many products do that. Its real analytical value is that the docs repeatedly separate settlement custody, subscription liveness, event indexing, and merchant-facing API ergonomics into different layers.
The target architecture relocates one-off payment custody into per-link EVM contracts, Solana PDAs, and a planned Bitcoin 2-of-2 taproot path. That means the hosted API can remain familiar while the settlement object becomes the actual trust root.
The subscription model is especially important. OrcaRail treats recurring billing as public charge() execution against payer-granted allowances/delegates, which makes keeper markets and fallback execution a distinct protocol surface rather than a hidden backend cron job.
The protocol materials are candid that non-custodial settlement is necessary but not sufficient for protocol status. The whitepaper and debate post both highlight that indexers, frontends, standards, and upgrade control are separate decentralization problems.
The security-model page makes the remaining control surfaces unusually legible: upgradeable factories/hubs behind multisigs, immutable per-link receivers, gas-only keeper EOAs, token allowlists, pause controls on some shared contracts, and a still-required platform cosigner on the planned Bitcoin path.
The debate post is valuable because it preserves the internal tradeoff space: a pragmatist path with hosted tooling, a maximalist path with decentralized frontends/subgraphs, an intents path with solver markets, and a standards path with interoperable payment-link and subscription EIPs.
OrcaRail is therefore more useful as a protocol-design specimen than as a simple merchant-processor entry. It exposes how a payment rail can preserve Web2 merchant ergonomics while trying to relocate trust into public settlement and public charge triggers.
Specific source signals worth retaining
The whitepaper is the best source for the invariant framing and the post-decentralization threshold of multiple independent frontends, keepers, and non-OrcaRail integrations.
The architecture docs are the best source for the concrete component split and for the explicit replacement mapping from legacy wallet derivation / sweep code into factory/receiver/hub/program primitives.
The security-model page is the best source for who controls upgrades, which components stay immutable, and how much authority keepers actually retain after the transition.
The roadmap is the clearest maturity check and prevents overstating the project as already-live neutral infrastructure.
The protocol-debate post is the clearest source for the project’s own distinction between settlement liveness and UX liveness, plus its standards-versus-product tension.
Why this entry belongs in the corpus
It sharpens the payment-auth and agentic-commerce cluster by exposing a merchant-integration stack where settlement, liveness, indexing, and front-end hosting are separate layers.
It gives the corpus a strong comparison point between machine-facing payment standards like x402/Open Payments and merchant-facing checkout rails that still want auditable, public settlement objects underneath.
The durable insight is that non-custodial payments is not one thing. A rail can move custody into contracts yet still centralize liveness, indexing, front-end discovery, or upgrade authority, and OrcaRail’s docs make those layers unusually explicit.