Predict statistics
Date range · UTC
to
Overview
Counterparty
filters Overview and Wallets
Loading…
Trading volume
Bucket
Loading…
Active users
Window
Loading…
Reload boost
Range
to
Loading…
Amounts in USDe
| # | Wallet | Trades | Volume | P&L | Share of losses | Reload boost |
|---|
Wallets
Counterparty
Amounts in USDe ·
| # | Wallet | Trades | Volume | Counterparty stake | Avg odds | P&L | ROI | Won | Lost | Open | Last trade |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Loading… | |||||||||||
About these numbers
- Scope
- Every prediction whose on-chain creation time falls inside the date range in the page header (UTC, both days inclusive), grouped by its counterparty: the Combos Vault (0x79cb…552d), the Singles Vault (0xdd9b…f223), Others for any other counterparty, and Total. Wallets are always the predictor side (the side taking the price); configured counterparties are never counted as wallets, even when they act as predictor. The Overview and Wallets sections follow the Counterparty filter; the charts always show every group.
- Volume, gross volume and average odds
- Volume is the collateral a wallet staked, in USDe; it matches Meridian's native volume metric. Counterparty stake is what the other side put up against it, and gross volume is the two added together. Average odds is volume ÷ gross volume, the volume-weighted implied entry price the users paid; the wallet table shows the same figure per wallet as Avg odds.
- P&L
- Realized as of load time, booked on the pick configuration's result: a win pays the counterparty's stake, a loss costs the wallet's own stake, open and non-decisive predictions count 0. This is the accounting Meridian's own leaderboard uses. ROI = P&L ÷ volume. The counterparty's P&L is the negative of the wallets' net P&L.
- Volume over time
- The range bucketed by UTC day, ISO week (Monday to Sunday) or calendar month, drawn as bars stacked by counterparty, so each bar's height is the total for that bucket. A bucket is drawn faded when the range or the current moment cuts it short. Active wallets is the one metric whose groups do not add up (a wallet can trade against more than one counterparty), so the distinct total is marked with a tick above the stack. Hover or focus the chart for every group's value; the table and CSV carry the same numbers (CSV: one row per bucket and group).
- Trailing windows
- Rolling series with one point per UTC day in the range. Each point covers the window ending at the end of that day (for today, ending now). DAU, WAU and MAU are distinct wallets with at least one prediction in the trailing 1, 7 and 30 days; the Custom window does the same for the number of days entered. Volume and trades are summed over the same window; "per day" measures divide by the window length, so a 30-day point is the average daily figure over those 30 days. The page fetches the extra earlier days the windows need before the range start.
- Reload boost
- The Boost pool tile carries a percentage field: 100% pays out the traders' whole net loss, 50% pays half. It scales every wallet's boost by the same factor and leaves each wallet's share of losses untouched. Computed over every wallet that traded against the configured counterparties in the range (predictions against any other counterparty are left out; the Counterparty filter does not apply). PNL is the total realized P&L of those wallets. If PNL is zero or positive, every boost is 0. Otherwise a wallet with a net loss Lu receives |PNL| × Lu ÷ LT, where LT is the sum of net losses over all losing wallets, so the boosts add up to the traders' net loss. Wallets with zero or positive P&L get 0. P&L uses the same definition as the rest of the page: predictions created in the range, realized as of load time.
- Fetching
- Mainnet only. The server keeps the full prediction history cached and refreshes it incrementally (new predictions plus newly resolved pick configurations) before answering, so a date range arrives in one response and the page reloads as soon as the range changes. Local copies of the page query the GraphQL API page by page instead, throttled under its 200 requests per minute limit.