RAIL20 Roadmap

Private payments on Base, in the open. This is our working plan for the next several months - token launch, more chains, B20 support, 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. 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.
• Deterministic burner wallets. Same-chain swap uses a one-time burner whose key is derived from the user's signature. The burner executes the DEX swap on-chain and re-shields the output back into the pool. No random keys, no localStorage state, always recoverable.
• 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.

RAIL20 and Base's Beryl Upgrade (B20)

Base is introducing B20, its own native token standard, as part of the Beryl upgrade. B20 is a strict superset of ERC-20, implemented as Rust precompiles rather than EVM contracts. Every standard transfer, approve, and balanceOf behaves exactly as ERC-20 does, with extra capabilities layered on top: transfer policies, freeze-and-seize, role systems, memos, and supply caps.

Because B20 is ERC-20-compatible at the interface level, RAIL20 supports B20 tokens with no contract changes. Adding a B20 pool is a configuration change - a token address, decimals, and symbol - and the existing pool contract, proof circuit, and relayer all work unchanged.

This matters for three reasons:

• RAIL20 users get privacy on Base's native standard from day one. No waiting for a v2 of the pool. No fresh audit surface. The Groth16 verifier and Poseidon tree are asset-agnostic.
• B20's compliance features compose with RAIL20's selective-disclosure model. A B20 issuer's transfer policy still applies when tokens enter or leave the pool; RAIL20's view keys and POI let users prove clean provenance to that policy on demand. Privacy and compliance stop being a trade-off.
• RAIL20 is future-proof for Base's roadmap. As Base's stack unifies and B20 rolls out, RAIL20 rides that curve rather than fighting it. Rebasing B20 Asset tokens will run in non-rebase mode inside pools, since notes carry fixed amounts, but nothing else about the design has to change.

B20 mainnet activation on Base is still pending, but the interface is public and stable. We've validated our pool design against it, and the first B20 pool ships in the v3 release.

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 B20: RAIL20 will support it on day one of the first B20 pool release. 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.