RAIL20 Roadmap

Private payments across chains, in the open. This is our working plan for the next several months - token launch, more chains and tokens, Private Proofs of Innocence - grounded in what is already live today.

Where RAIL20 is Today

RAIL20 is a zero-knowledge privacy layer for tokens on Base, Robinhood Chain, Arbitrum, and BNB Smart Chain. Users shield tokens into a per-token anonymity pool, transact privately using Groth16 zero-knowledge proofs, and unshield to any address whenever they want. No mixer, no fixed denominations, no waiting periods.

The system running in production today:

Every one of these has been exercised with real on-chain transactions. If a swap or bridge is interrupted mid-flow, funds are always recoverable from the user's signature. There is no localStorage-only failure mode; there is no random ephemeral key that can be lost.

Why Now

The last few weeks have taught us three things worth designing around:

• Same-chain swaps should never wait on an off-chain solver. Routing ETH ↔ USDC through a cross-chain solver was correct in theory and painful in practice: intents queued in PENDING_DEPOSIT for tens of minutes when solvers optimized for cross-chain liquidity elsewhere. Same-chain swaps now settle in one on-chain transaction through Uniswap V3, mirroring how PrivacyCash uses Jupiter on Solana. Cross-chain bridges keep using the solver network, where it belongs.
• State that lives only in localStorage is a fund-loss trap. Any cached "stage" hint or ephemeral private key that isn't reproducible from the user's signature will eventually strand funds. Every burner in RAIL20 is now derived deterministically as keccak256("rail20-burner-v2:" + keccak256(sig) + ":" + nonce), and recovery scans on-chain state, not local hints.
• Public RPCs beat closed key-gated ones. Public Base RPC has been more reliable in practice than key-gated Alchemy endpoints, and it removes a rate-limit-shaped single point of failure. The entire runtime and deploy path is public-RPC by default.

Technical Foundations

RAIL20 is a small set of purpose-built parts, not a monolith. If you want the deep dive, the architecture page has the full data flow. The summary:

• Per-token pool contracts. One contract per asset. Each holds a Poseidon Merkle tree of note commitments, verifies proofs on-chain, and tracks spent nullifiers. There is no shared vault to compromise, and the anonymity set is naturally per-asset.
• 2-in / 2-out UTXO circuit. Groth16 over BN254, Poseidon hashing, 26-level tree with 100-root history. Every private operation is exactly one transact call. Deposits, sends, swaps, and bridges all reuse the same primitive.
• Relayer-built proofs. The user signs a single message, and the relayer scans the pool, builds the proof, and broadcasts. Users pay no gas and their wallet never touches the transaction. The relayer cannot move funds without the signature.
• Recoverable burner wallets. Same-chain swap uses a one-time random burner whose key is encrypted (AES-256-GCM under your sign-in signature) and registered before funding. The burner executes the DEX swap on-chain and re-shields the output back into the pool. Recoverable from any device via the registry; legacy signature-derived burners are still swept too.
• 1Click for cross-chain. Bridge routes through NEAR Intents 1Click solver network, which is what 1Click was designed for. Verified ~25-second delivery for Base → Arbitrum.

Everything above is running in production. None of it is speculative.

Roadmap Preview

In the spirit of building in public, here is our current working plan for the next several months. We'll iterate as we learn, but this is a real commitment, not marketing.

We're targeting a shipping cadence of roughly one release every four to six weeks - smaller, tightly scoped upgrades over infrequent large ones. This is the same discipline Base is now moving to for their own stack, and for the same reason: frequent small releases are easier to verify, audit, and integrate.

Multi-chain by design

RAIL20's pool contract, Groth16 verifier, and Poseidon tree are asset- and chain-agnostic. Adding a new shielded pool - a different token, or the same design on a new EVM chain - is a configuration change (token address, decimals, symbol), not a new contract or a fresh audit surface.

This is what lets RAIL20 expand quickly:

• New chains ship as config, not rewrites. The same verified circuit and relayer run on every chain, so each new deployment reuses the same audited core.
• Compliance composes with selective disclosure. When a token carries a transfer policy, it still applies as tokens enter or leave the pool; RAIL20's view keys and POI let users prove clean provenance on demand. Privacy and compliance stop being a trade-off.
• Any ERC-20-compatible standard works unchanged. Because the pool interacts through the standard transfer/approve/balanceOf surface, new token standards that stay ERC-20-compatible are supported without contract changes. Rebasing tokens run in non-rebase mode inside pools, since notes carry fixed amounts.

Token Launch Next Week

The RAIL20 token launches with the v2.1 release next week. It is designed around three uses:

• Protocol utility inside the app - fee discounts on shielded operations, priority relayer paths.
• Governance - deciding which pools to add next, which chains to prioritize for bridge coverage, how appFees are distributed.
• Revenue share - a share of protocol fees flowing back to token holders through a transparent, on-chain mechanism.

The full tokenomics, distribution, and vesting details will be published in a dedicated post at launch. This roadmap is the technical picture; the token post will cover the economics.

What This Means for You

• If you're a user today: Nothing changes. Everything you're using stays live and working. New features arrive as they're released.
• If you're an integrator: The public docs here and at github.com/rail20dev/protocol are the source of truth. The relayer API surface (/api/balance, /api/deposit/prepare, /api/withdraw, /api/swap, /api/swap-private, /api/burner-gas, /api/bridge/quote, /api/intent-status) is stable across the v2 series. A TypeScript SDK arrives in v3.
• If you're waiting for a new chain or token: new pools ship as configuration, so support arrives with no contract migration, no user re-shield, no drama.

Building in the Open

Everything above is public. The protocol documentation is MIT-licensed. The pool contracts are verified on Basescan. The Groth16 verifier is generated from a standard universal setup and can be reproduced from the public ceremony output. We contribute back to the primitives we depend on (Uniswap V3, NEAR Intents 1Click, standard Groth16 / Poseidon libraries) and publish our own tooling as we go.

A dedicated external audit of the RAIL20-specific contracts is pending. The primitives underneath (Groth16 verification, Poseidon hashing, Merkle-tree commitment schemes over BN254) are industry-standard building blocks with no novel cryptography.

Join Us

Building private, compliant onchain payments at Base's scale is a team effort. If you're passionate about zero-knowledge cryptography, cross-chain settlement, or building the payment layer for the next billion onchain users, we want to hear from you.

• App: app.rail20.org
• Docs: docs.rail20.org
• Twitter: @railB20
• Protocol: github.com/rail20dev/protocol

RAIL20 wins when Base wins, and Base wins when Ethereum wins. Same north star.