RainChain Phase 0 — in development

Layer 1 for prediction & outcome markets

The chain for outcomes.

Rain Chain runs a native order-book engine and a full EVM in the same 200 ms block, finalised in one slot. Merged YES/NO books, native resolution, randomness and bounded leverage are protocol primitives — not contracts bolted on top.

Read the specification How it works

Status: Phase 0. The core matching engine is built and benchmarked; devnet, testnet and mainnet are not live yet. See the roadmap.

Built for

One chain, four kinds of participant.

Every primitive an outcome business needs lives in the protocol: books, complete sets, resolution, randomness, settlement and builder fees.

01 / TRADERS

Gasless, final, fair

Trade YES or NO on one deep book with no gas per order. Fills are final in one block, winning shares settle to 1.00 automatically — no claim transaction.

02 / MARKET MAKERS

Quote without getting picked off

Cancels and post-only orders execute before takers in every block — a consensus rule, not proposer goodwill. Batches, dead-man switch, agent keys and 0 bps maker fee.

03 / BUILDERS

Ship a front end, earn per fill

Builder codes pay up to 50 bps per fill. RainEVM contracts read books and outcomes via precompiles and use a native randomness beacon.

04 / VALIDATORS

Stake-ranked seats

Seven genesis validators, growing to 26 by stake. Voting power is stake-weighted and capped at 10% per validator. Commission 5–20%, slashing enforced.

How it works

One binary. One state root. One block.

Consensus, the RainCore trading engine and RainEVM share a single state root per block. Funds move from Arbitrum One through a rate-limited bridge.

  • Consensus — pipelined BFT, 200 ms block target, single-slot finality, stake-weighted voting.
  • RainCore — native, integer-only state machine: accounts, merged books, matching, outcome tokens, margin, resolution, staking, randomness.
  • RainEVM — EVM-equivalent execution in the same block, gas in RAIN, precompiles into RainCore.
  • Bridge — burn-and-mint for RAIN, lockbox for USDT/USDC, validator-signed withdrawals with size-based delays and hourly caps.
Explore the architecture
Rain Chain architecture Apps and market makers send signed actions to a Rain Chain node. The node runs pipelined BFT consensus, the RainCore trading engine and RainEVM, which share one state root. RainEVM reads RainCore through precompiles; writes are queued to the next block. A bridge connects to Arbitrum One: burn-and-mint for RAIN, a lockbox for USDT and USDC. Apps · front ends · market makers · AI agents EIP-712 signed actions (RainCore) · EVM transactions (RainEVM) RAIN CHAIN NODE — single Rust binary Consensus — pipelined BFT 200 ms blocks · single-slot finality · stake-weighted · ordering = validity RainCore native trading state machine — Merged YES/NO order books— Mint / burn on match— Margin & liquidation— Resolution · staking— Randomness beacon RainEVM EVM-equivalent (revm) — Gas in RAIN, base fee burned— ERC-4337 at genesis— Open ERC-20 creation— House Vault templates— Runs after RainCore read write h+1 One state root per block · deterministic replay from genesis validator-signed bridge ARBITRUM ONE RAIN — burn-and-mint one global supply, capped mint USDT / USDC — lockbox 2/3 signatures · delays · hourly cap
Rain Chain system overview. The bridge contract on Arbitrum One is the only place user funds sit outside Rain Chain.

Key numbers

Designed for news-speed markets.

Protocol parameters from specification v0.2. Network latency and throughput figures are design targets until a public load test replaces them.

200 msBlock timeTarget
1 blockDeterministic finalitySingle-slot BFT
~300kActions/s, engine execution, single threadMeasured, Phase 0 bench*
0 bpsMaker fee · 20 bps takerLaunch schedule
7 → 26Validators, ranked by stakeGenesis → active set
10%Voting-power cap per validatorConsensus rule
0.001Tick size — tight quotes in the tailsPer-market option 0.01
2× → 5×Bounded, long-only leveragePhased; in-play ≤ 2× at beta

* Phase 0 benchmark of the RainCore engine alone: 296k–346k actions/s depending on block size, on one CPU thread, excluding signature verification and consensus. It is not a network throughput claim. The network design target is ≥ 20,000 order actions/s sustained.

The ordering rule

Makers move first. Every block.

Within each block, RainCore actions run in three classes. A block that breaks the order is rejected by every validator.

  1. Non-taking actions — post-only (ALO) orders, deposits, transfers, staking, oracle actions.
  2. Cancels — by order id or client id, including dead-man switch triggers and expiries.
  3. Takers — anything placing a GTC, IOC or FOK order that can cross the book.

A market maker who quotes and cancels is never picked off within a block by a taker that arrived in the same block. That is the single most important property for tight spreads on news-driven markets.

Read the rule in detail
In-block ordering rule Actions arrive in mixed order. Each block executes class 1 non-taking actions first, then class 2 cancels, then class 3 taker orders, keeping proposer order within each class. ARRIVAL ORDER (proposer) TakeALOCancelTakeALOCancelDep. sorted into classes — block validity rule EXECUTION ORDER (every validator checks) 1Non-takingALO, deposits, stakingALOALODep. 2Cancelsby id / cloid, expiriesCancelCancel 3TakersGTC / IOC / FOKTakeTake then RainEVM transactions · EVM writes to RainCore queue to h+1
Proposer order is kept within a class; classes always run 1 → 2 → 3. RainEVM transactions execute after all RainCore actions.

Native primitives

Everything outcome markets need, in the protocol.

Merged YES/NO book

Buying NO at q is selling YES at 1 − q on the same book. Matches transfer shares, mint a complete set, or burn one — automatically.

Multi-outcome markets

Up to 64 outcomes with exactly one winner, kept arbitrage-consistent by atomic negRisk-style conversion.

Native resolution

Three tiers — AI proposal, AI dispute, stake-weighted oracle vote — with RAIN bonds and automatic settlement.

Randomness beacon

Threshold-BLS beacon every block. Unbiasable and verifiable; exposed to contracts via a commit-then-reveal precompile.

Bounded leverage

Isolated, long-only margin on outcome shares, funded by a lending vault, with a four-step liquidation waterfall.

RLP vault

A protocol liquidity vault that quotes new markets post-only, backstops liquidations and earns a share of fees.

Status & roadmap

Where we are, honestly.

Rain Chain is in development. No public network is running yet. About 9–11 months from start to a stable mainnet is planned.

Now

Phase 0 — Foundations

RainCore state machine built: merged books, mint/burn-on-match, multi-outcome, ordering rule, order types. 70 tests passing; engine benchmarked. Next: consensus spike, 4-node devnet, signatures.

~6 weeks
Coming

Phase 1 — Public testnet

7-node testnet, resolution module, market-maker onboarding, bridge on Arbitrum Sepolia, RainEVM + precompiles, explorers, SDK.

~3 months
Coming

Phase 2 — Mainnet beta

Audits, 7 validators (≥ 4 independent), $25M deposit cap, 2× leverage on eligible markets, app migration.

~2–3 months
Coming

Phase 3 — Stable

Open set to 26 validators, leverage to 3× then 5×, permissionless markets, spot listing auctions, caps lifted gradually.

6–12 months

Read the full design.

Consensus, RainCore, leverage, bridge, token and validator economics — every parameter, in one document.

Read the specification For developers