RainChain Phase 0 — in development

Rain Chain / Technology

A matching engine that is the chain.

One Rust node binary runs consensus, the native RainCore state machine and RainEVM in the same block. Ordering, matching and settlement are protocol rules every validator checks.

Overview

Why an L1, not an L2

A rollup design was specified and evaluated. It inherits Ethereum security for funds, but sequencer-ordered EVM execution cannot match a native matching engine for latency, cancel priority, gasless trading or validator-enforced ordering. Rain Chain chose performance and sovereignty, and makes the main cost — the bridge and validator security — the most carefully specified part of the design.

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
System overview.

Design principles

  • Consensus, RainCore and RainEVM share one state root per block.
  • RainCore uses integer arithmetic only — no floating point anywhere in the state transition — with canonical encoding and domain-tagged SHA-256 state hashes.
  • Any honest node replaying the block log from genesis reproduces every state hash bit-for-bit.
  • Trading on RainCore is gasless; spam is bounded by volume-based rate limits.
  • Ordering rules are block-validity rules, not proposer goodwill.

Consensus

Pipelined BFT, 200 ms, one-block finality

A block with commit signatures from more than 2/3 of voting power is final and cannot be reverted except by pre-published social-layer recovery. Execution is pipelined: consensus on block h+1 proceeds while block h executes.

PropertyDesign
Block time200 ms target, 7–26 validators across at most 3 continents
FinalityDeterministic, single-slot (one block); p99 time-to-finality ≤ 600 ms target in testing
Voting powerStake-weighted; each validator's counted power capped at 10%
ProposerRotates weighted by power
Vote extensionsCarry randomness-beacon shares and pending bridge-withdrawal signatures
TopologyValidators behind sentry nodes; validator IPs not public
EngineRust BFT library (Malachite or Commonware) selected by a Phase 0 spike; CometBFT fallback would relax blocks to 500 ms

Why seven validators at genesis

BFT tolerates f faulty validators among n ≥ 3f + 1. Four validators tolerate one fault — no margin during an upgrade or a datacentre outage. Seven gives f = 2: one validator down for maintenance plus one malicious or failed at the same time. The protocol refuses to produce blocks with fewer than 5 active validators.

Block pipeline

The three-class ordering rule

Within each block, RainCore actions are sorted into three classes and executed in this order:

  1. Non-taking — actions that place no GTC or IOC taker order: post-only (ALO) orders, deposits, transfers, staking, admin and oracle actions.
  2. Cancels — by order id or cloid, including scheduleCancel triggers and expiries.
  3. Takers — actions that place at least one GTC, IOC or FOK order.

Within a class, the proposer's order is kept; a modify is classified by the new order it places. A block that violates the rule is rejected by every validator.

RainEVM transactions execute after all RainCore actions. Writes from EVM contracts into RainCore are queued and applied in class order at the start of the next block, so contracts cannot jump the cancel queue.

After a halt or pauseAffected markets enter a post-only window of 10 blocks (≈ 2 s) in which only class-1 and class-2 actions are accepted, so makers refresh quotes before takers return. Circuit breakers reopen the same way.
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

RainCore

One merged book per outcome

Every binary outcome has a single book expressed in YES price. An order to buy NO at q is stored as a sell of YES at 1 − q. Liquidity is not split across two books and one price-time queue removes cross-book arbitrage. Each match takes one of three paths, chosen automatically by what each side holds:

TakerMakerExecution
Buy YES (has quote)Sell YES (holds YES)Transfer — ordinary trade of YES for quote
Buy YES (has quote)Buy NO (has quote)Mint-on-match — taker pays p, maker pays 1 − p; one YES + one NO minted from 1.00 collateral
Sell YES (holds YES)Sell NO (holds NO)Burn-on-match — YES holder receives p, NO holder 1 − p; the pair merges and 1.00 is released
  • Mint and burn are atomic within the fill. The invariant quote locked = outstanding complete sets × 1.00 holds after every action and is part of the market's state hash.
  • At equal price, resting holders' sells queue ahead of mint orders, because they release rather than lock collateral.
  • Tick 0.001 across 0.001–0.999 (market option 0.01). Outcome markets trade at 1–3¢ and 97–99¢ routinely, where a 1¢ tick is a 30–100% relative spread.
  • Collateral: USDT and USDC as separate quote assets (no implicit 1:1), balances stored as integers, prices on a 6-decimal fixed-point scale.

Multi-outcome

Up to 64 outcomes, one winner

A multi-outcome market groups N binary outcomes (N ≤ 64) where exactly one resolves YES. Prices stay arbitrage-consistent without a single N-way book:

negRisk-style conversion

A holder of NO on k outcomes may convert it atomically into (k − 1) units of quote plus YES on each of the other N − k outcomes.

Basket mint

One YES on every outcome costs exactly 1.00 and can be merged back at any time.

Orders & market-maker tooling

Exchange-grade, natively

ORDER TYPES

Limit GTC, IOC, FOK, post-only (ALO), market (as IOC/FOK), reduce-only, GTD (expiry timestamp) and expiresAfter (reject if included late).

SELF-TRADE PREVENTION

Per order: CancelNewest (default), CancelOldest or Decrement.

CLOID

128-bit client order id, unique per account among open orders. Cancel and modify by cloid.

BATCHES

Up to 50 place / cancel / modify operations per signed action, atomic per operation, counted as n requests.

DEAD-MAN SWITCH

scheduleCancel(t) with t ≥ 5 s in the future; up to 10 triggers per UTC day per account.

AGENT KEYS

Up to 10 named keys per account, scoped trade or cancel-only, expiry ≤ 180 days. Agents can never withdraw, transfer or change staking.

NONCES

Each signer keeps its 100 highest nonces; a new nonce must exceed the smallest, be unused, and fall within (T − 2 days, T + 1 day).

RATE LIMITS

10,000-request initial buffer plus 1 request per $1 of filled volume. Cancels get min(limit + 100,000, 2 × limit).

LIMITS

1,000 open orders per account per market (raised by volume tier), $1 minimum notional, up to 20 isolated sub-accounts.

RainEVM

A full EVM in the same block

RainEVM is EVM-equivalent (Cancun-level opcodes, built on revm) and executes after RainCore in each block. Gas is paid in RAIN with EIP-1559: the base fee is burned, the priority fee goes to the proposer. ERC-4337 EntryPoint and paymasters are deployed at genesis so apps can sponsor gas or charge in USDT. ERC-20 creation is open.

PrecompileFunctionNotes
CoreReadBalances, positions, book top-N, mark price, market statusReads state at start of current block
CoreWritePlace/cancel orders, transfer to/from RainCore, open/close leverageQueued, applied in block h+1 in class order
Randomrequest(k) → id; get(id) returns 32 bytes once round h+k is finalCommit-then-reveal
ResolveMarket outcome and resolution stageBuild on resolved outcomes
StakeDelegate / undelegate on behalf of a contractFor liquid-staking contracts

Chain id and precompile addresses: TBA.

Randomness

A threshold-BLS beacon, every block

  • Validators run a distributed key generation at each validator-set change, producing a threshold BLS key (t = ⌊2n/3⌋ + 1).
  • Each block, validators add a signature share over (chain id, h) to their vote extension. The aggregate σh is unique and verifiable; Rh = SHA-256(σh). It is unbiasable and unpredictable until t shares are revealed.
  • Contracts use commit-then-reveal: a request in block n receives Rn+k, k ≥ 2 (default 3). The precompile reverts if read early.
  • If a round cannot be formed, requests roll to the next round — there is no fallback to proposer randomness.
Disclosed limitationCollusion of ≥ t validators could predict (not bias) a value. Contracts should cap single-bet payouts relative to vault equity; the published House Vault template caps them at 1%.

Rain publishes open-source, audited templates — House Vault, dice, scheduled lottery and a crash-style game. Rain does not operate games; operators deploy their own instances and run their own products.

Resolution

Native, three-tier, bonded

TierWho decidesWindowBond (RAIN)
1 · ProposalAI resolver key posts the outcome60 min0.1% of open interest, 50k–2M
2 · DisputeAI judge key re-decides60 min0.1% of OI, 20k–2M
3 · AppealStake-weighted vote by opted-in RAIN stakers (quorum 5%, 1-day commit + 1-day reveal)24 h0.2% of OI, 50k–5M
  • The losing side's bond is split 50% to the winning challenger and 50% burned. Tier-3 voters on the minority side lose 1% of voted stake.
  • Auto-settlement: at final outcome, every winning share becomes 1.00 quote in the holder's balance — no claim transaction. Open orders are cancelled first.
  • Markets whose source is unavailable stay tradable until resolved; there is no forced fallback outcome.
  • Resolver keys are rotatable in one governance action and held in HSM/KMS.

State commitment

Deterministic and replayable

RainCore state is encoded with fixed-width big-endian canonical encoding and hashed per module with domain-tagged SHA-256. The state root of block h is committed in a following block (one or two blocks later — fixed during Phase 0). Signed snapshots every 10,000 blocks let a new full node sync in ≤ 30 minutes (target); archive nodes retain all block and fill history.

In progressThe Phase 0 engine re-serialises the full state for its hash every block. That is correct but O(state); the next milestone replaces it with an incremental commitment.

Performance

Measured so far

Phase 0 benchmark of the RainCore engine on one thread of an 8-vCPU server, with a market-maker-heavy mix (60% post-only, 30% cancels, 10% crossing takers):

Actions / blockMedian execp99 execThroughput (exec only)
5,00014.3 ms18.2 ms345,500 /s
20,00064.3 ms72.0 ms311,800 /s
50,000166.5 ms218.7 ms296,500 /s
What this does and doesn't meanEngine execution only: no signature verification (to be parallelised before execution), no consensus, no networking, rate limits off. It shows headroom over the ≥ 20,000 actions/s network design target; it is not a network throughput claim. Public load tests will follow on devnet and testnet.