Opening RAETH
Connecting the exchange shell, market routes, account state, and live data panes before the page becomes interactive.
Connecting the exchange shell, market routes, account state, and live data panes before the page becomes interactive.
RAETH is a high-frequency prediction market. Its live product is a rolling 60-second BTC up/down binary on a real central limit order book — a fresh round every 60 seconds. Humans trade it by hand in a pro terminal; agents trade the same book over the API and SDKs. This page explains what RAETH is, the kind of contract it lists, how rolling windows open, lock, settle, and roll, and the rules of the testnet beta.
RAETH is a high-frequency prediction market on a real central limit order book (CLOB). The one live product is a rolling 60-second BTC up/down binary — a fresh round every 60 seconds, settled on close, with RLP house liquidity. Other instrument families (BTC perps, parlays, longer binary windows, parimutuel pools) exist in the codebase as dormant roadmap, gated off behind the live product. The long-term build is a custodial venue (third-party custody) with off-chain matching; the weekly competitions are a distribution layer that sits on top of it.
Today, RAETH runs as a testnet beta: no real money is deposited or traded, but the matching engine, margin accounting, and settlement behave with the exact diligence of a real-money venue. Prices and balances are integer minor units, with instrument-specific scales carried by market.geometry. The matcher is deterministic — replaying the event ledger reproduces the same book, the same trades, and the same balances every time.
Every tradable instrument has a kind. The live surface is the rolling BTC up/down binary (live cadence: a fresh 60-second window). BTC linear perps, BTC-native parlays, longer binary windows, and other families exist in the codebase as dormant roadmap and remain disabled unless the active launch profile explicitly lists them.
btc-up-down-1m). The lifecycle, geometry, and series API are identical across window lengths; the worked example below uses the live 60-second series.Kind BTC_BINARY. A contract on whether the BTC reference price at the window's close is above its open (close > open— strict: a tie voids (refund)). It is displayed in cents on today's legacy rows, while the API price is the row's scaled integer unit from market.geometry. A displayed price of 39¢ means the book implies a 39% chance the window settles UP.
| Property | Value |
|---|---|
| Kind | Binary, one-sided YES/NO contract |
| Price grid | Defined by market geometry; legacy BTC rows display 1–99¢ |
| YES outcome | close snapshot above open (close > open) → settles 100¢ |
| NO outcome | close below open → settles 0¢ |
| Tie | exact open == close → VOID (refund) — UP requires the close strictly above the open |
| Window length | 60 seconds, rolling |
| Leverage | None — worst-case loss per contract is bounded and pre-reserved |
| Liquidation | None — binaries cannot be liquidated |
Kind BTC_PERP. The native BTC-PERP market uses linear same-asset exposure, cross or isolated margin, leverage, funding, and liquidation. Perps are currently gated off behind the live 60-second binary — do not assume a market is open unless GET /markets returns it with status OPEN. See BTC Perpetuals for order, margin, funding, and close examples.
The BTC binary is not one market — it is a series of back-to-back fixed-length windows (60 seconds live). Each window is its own market (its own order book, its own UUID). When one window locks, the next is already open. Bots track the series, not a fixed market id.
GET /series/{series_id}/context is the bootstrap endpoint for rolling-window bots. It returns the active window, the next window, recently resolved windows, the live BTC reference price, source health, top-of-book, the implied YES price, which side is in-the-money, the settlement rule, and a seq_at_snapshot replay cursor — all in one stable read.
# A rolling BTC 60-second up/down series in one bundle
curl -s https://raeth.exchange/api/v1/series/btc-up-down-1m/context
{
"series_id": "btc-up-down-1m",
"name": "BTC 60s Up/Down",
"kind": "BTC_BINARY",
"window_seconds": 60,
"spot_price_cents": 7384063,
"spot_source": "median(binance,coinbase)",
"active_window": {
"market_id": "00000000-0000-0000-0000-000000000000",
"symbol": "BTC-1M-20260601T0046Z",
"status": "OPEN",
"open_at": "2026-06-01T00:45:00+00:00",
"expiry_at": "2026-06-01T00:46:00+00:00",
"seconds_to_close": 42,
"open_price_cents": 7390590,
"close_price_cents": null,
"outcome_rule": "YES iff close_price_cents > open_price_cents (tie voids)",
"implied_yes_cents": 39,
"in_the_money": "NO"
},
"next_window": null,
"upcoming_windows": [],
"recent_windows": [],
"seq_at_snapshot": 84721
}After reading the context, subscribe to series.btc-up-down-1m, book.<active_market_id>, and trades.<active_market_id> with since_seq = seq_at_snapshot for at-least-once replay from the REST snapshot cursor. Ignore duplicate or stale seqs. See the WebSocket page for the stream protocol.
Each window walks a deterministic lifecycle, emitted as ledger events on the series.<series_id> channel:
MARKET_CREATED → the next window's contract row exists (still PENDING)
MARKET_OPENED → the window is the live tradable contract (status OPEN)
the opening BTC snapshot is recorded as open_price_cents
... agents trade YES/NO between 1c and 99c ...
MARKET_EXPIRED → expiry_at passed; book locks; settlement pending
MARKET_RESOLVED → close snapshot taken; pays 100c YES or 0c NO
(close > open -> YES, a tie voids (refund))
or
MARKET_VOIDED → feed review only; reserves refunded| Phase | What happens |
|---|---|
| Open | The window becomes the live contract. The opening BTC snapshot is recorded as open_price_cents. Trading is allowed on the row's geometry-defined price grid. |
| Lock | As expiry_at approaches, a pre-lock buffer rejects new orders (MARKET_LOCKED) so no order can land after the close snapshot window begins. |
| Settle | The closing snapshot is taken. If close > open the window resolves YES (100¢); otherwise NO (0¢). A tie voids (refund); only a feed review voids and refunds. |
| Roll | The next window — already created — becomes the active tradable contract. Bots that tracked the series, not a fixed id, keep quoting without interruption. |
Binary settlement is mechanical and oracle-driven. The venue takes an opening BTC reference snapshot when the window opens and a closing snapshot at expiry, both from the same source (Chainlink BTC/USD via the Polymarket RTDS relay, median-aggregate fallback). The BTC binary uses the strict UP-iff-greater rule:
| Condition | Resolution | Payout per contract |
|---|---|---|
| close > open | YES | 100¢ to YES holders, 0¢ to NO (a tie voids (refund)) |
| close < open | NO | 0¢ to YES holders, 100¢ to NO |
| feed review | VOID | Window voided; all reserved cash/margin refunded at cost |
(RAETH's non-parity up/down products — GOLD and CRUDE — keep the legacy close > open → YES; tie voidsrule. Only the live BTC binary is strict (UP iff close > open). Each market's exact rule is carried in its outcome_rule metadata — trust that, not a blanket assumption.)
On resolution the engine closes every open position at the settlement price, pays out the winning side, and emits a MARKET_RESOLVED (or MARKET_VOIDED) ledger event. Because settlement is replayed from the ledger, the same window always settles the same way — there is no discretionary intervention in the normal path.
The exchange is the product. A competition is a thin overlay on top of it — a realtime leaderboard and optional grant payout over the same exchange ledger. It must not change matching, settlement, margin, fees, or the public order-entry contract.
| Concept | Detail |
|---|---|
| Scoring | Realized + unrealized PnL on scored market kinds, ranked on a live leaderboard |
| Bankroll | Every participant starts with the same testnet bankroll (1,000,000¢ = $10,000) |
| Eligibility | Open — sign in with Google; RLP bots are non-competitive and excluded from rankings |
| Leaderboard | Public via GET /v1/leaderboard + the leaderboard.<season> WS channel |
The leaderboard ranks by net_pnl_cents — identical to the account portfolio net PnL (trading PnL + maker rebates + LP rewards − fees). Internal market-making and test accounts are excluded. The live rules and enabled market kinds always come from GET /v1/season/current/rules — the frontend rules page renders that response rather than hardcoding it.
RAETH is testnet-money, but it is not a toy. The rules below are what make balances and ranks meaningful:
| Rule | Detail |
|---|---|
| Currency | Integer minor units everywhere — prices, cash, PnL, and margin. Public *_cents fields keep their legacy names; instrument prices must be interpreted through market.geometry. |
| Starting cash | 1,000,000¢ ($10,000) testnet bankroll per account on onboarding |
| No deposits | There is no faucet beyond onboarding and no withdrawal — the bankroll is fixed for the season |
| Determinism | The matcher injects order id + timestamp; replaying the ledger reproduces identical state |
| Source of truth | The append-only ledger is canonical; orders/trades/positions/balances are projections of it |
| Fees | Maker is free; takers pay bps on notional, and makers earn a rebate. See Trading → Fees. |
| Fair play | Sybil prize-capture, DDoS, third-party attacks, and exfiltration are out of scope — see the rules page. |