All metrics are derived from on-chain data on the Linera Conway testnet. A participant scanner runs hourly via systemd timer, querying block history from 9 market chains (BTC/ETH/SOL × 1m/3m/5m) through Linera RPC worker endpoints. A separate snapshot process queries market state (pools, generations, resolutions) and agent GMIC balances every hour. Raw data is stored as JSON snapshots in .prod-deploy/snapshots/YYYY-MM-DD-HH.json.
Wallets are identified by their authenticated signer address (0x... public key) extracted from incomingBundle.messages[].authenticatedSigner in each block. When a bundle targets a market application (matched by applicationId), the signer is recorded as a market participant.
When authenticatedSigner is null (cross-chain message routing), the scanner falls back to the bundle's origin chain ID. These chain-ID addresses are resolved to their owner public keys via chain(chainId).executionState.system.ownership.owners and merged with existing signer entries to avoid double-counting.
Deduplication: After the initial baseline scan, a dedup pass resolves all chain-ID entries to owner keys. If a chain-ID address maps to an owner already present as a 0x signer, the entries are merged: trade counts are summed, timestamps take min/max, market lists are unioned, and scan_deltas are concatenated. This reduced the raw count from ~86K to ~52K unique wallets.
Limitation: Wallet counts represent distinct trading accounts, not unique humans. A single person may control multiple wallets. No heuristic clustering (e.g., by funding source) is currently applied.
A "trade" is defined as one accepted incoming bundle whose messages target a market application. The scanner paginates through block history using blocks(chainId, from, limit) queries, processing up to 10,000 blocks per batch. Only bundles with action: "Accept" are counted; rejected bundles are excluded.
Trade counts are cumulative per wallet (total_trades) and also tracked as time-series deltas (scan_deltas) — each hourly scan records how many new trades were found for each wallet. Time-windowed metrics (today, this week, etc.) are computed by summing scan_deltas within the relevant window.
Limitation: Trade counts measure bundle frequency, not GMIC volume. A wallet that places 100 small bets counts as 100 trades, same as one placing 100 large bets. Per-trade GMIC amounts are not available from the current on-chain data (the trades MapView in the contract schema exists but is not populated).
GMIC balances shown on the leaderboard are queried on-chain via the fungible token application (ca9dd5c2...) deployed on each user's chain. For each top-50 leaderboard wallet, the scanner queries /chains/{chain_id}/applications/{token_app_id} with accounts.entry(key: "{owner}").
The chain_id used is the wallet's origin chain from the participant database. If the origin chain doesn't hold the wallet's GMIC (they traded from a non-home chain), the balance returns null and is shown as "—" on the dashboard.
Coverage: ~25% of top-50 wallets currently have GMIC data. Coverage improves as wallets trade from their home chains in subsequent scans. Our bot fleet wallets always have GMIC data since we know their exact chain mappings.
19 wallet addresses belonging to our agent fleet are tagged as known bots via configs/known-bots.json. These are the OWNER_* addresses from state.env — the wallets our strategic and noise agents trade from. The "Show bots" toggle includes/excludes these from the leaderboard. Bot wallets are visually dimmed with a "BOT" tag when shown.
No automated bot detection is applied to external wallets. All non-flagged wallets are treated as organic participants.
Each market runs in discrete generations — timed prediction cycles configured via generationConfig (duration: 60s for 1m markets, 180s for 3m, 300s for 5m). Each generation opens a yes/no pool, accepts bets during the window, then resolves via an external price oracle. The "Market Rounds" metric is the sum of currentGeneration across all 9 markets — the total number of completed prediction cycles since market creation.
Pool volume is computed from poolHistory entries on each market chain — the sum of absolute deltas in yesPool and noPool between consecutive snapshots within the measurement window. This represents total GMIC flowing into and out of prediction pools, not net position changes.
Resolution rate is the percentage of completed generations that received an oracle resolution. Computed by batch-querying resolutions.entry(key: N) for the last 20 generations per market using aliased GraphQL fields. A resolution contains the outcome (Yes/No) and timestamp. Unresolved generations typically indicate oracle downtime.
Snapshots are generated hourly at :05 past each hour via a systemd timer. The participant scan (incremental, last 2 hours of blocks) runs as ExecStartPre before the snapshot. Dashboard polls for the latest snapshot every 60 seconds. A staleness badge appears if the most recent snapshot is older than 90 minutes.
Historical data prior to 2026-03-25 was backfilled from the baseline participant scan's last_seen timestamps, bucketed by hour. These backfilled snapshots use "wallets last active in that hour" as the activity metric, which differs from the real incremental scan's trade count. Daily chart aggregations smooth this difference.