Docs

Sprint — how many of something happens inside a short window, answered in buckets (for example 0–2, 3–5, 6+). Bucket edges are set from the recent observed distribution so no bucket is a foregone conclusion.

Threshold — a yes/no question about a count crossing a line inside a window.

Milestone — whether a specific token reaches a specific state, such as completing its bonding curve.

Race — which of several tokens gets somewhere first. These currently void rather than resolve: the comparison logic is not built, and a market that cannot be resolved correctly must void rather than guess.

Markets are parimutuel. Stakes go into per-outcome pools; when a market settles, the losing pools are distributed across the winning stakes in proportion to their size, after a 2% rake.

losing        = total_pool − winning_pool
distributable = floor(losing × (1 − 0.02))
your_share    = floor(distributable × your_stake / winning_pool)
your_payout   = your_stake + your_share

Everything is floored to whole points, so the sum of the payouts is at most the distributable amount and usually a little under. That difference — the dust — is burned along with the rake. Points are never invented: payouts plus rake plus dust always equals the total staked, and there is a test asserting exactly that.

Because winning_pool includes your own stake, backing a side dilutes it. This is why the price you see is not a fill price and why a projected payout falls as more money joins your side.

A price of 62¢ is the pools' implied probability, 62%. It is shown in cents because that is the vocabulary share-based prediction markets use, and because a share here can be defined precisely: one share pays 1 DP if its outcome wins. Your projected payout is therefore also your share count, and the price you effectively paid is stake / payout.

Under 500 DP staked or fewer than 2 bettors, prices are shown as an even split instead. Those are the same thresholds below which settlement refunds rather than pays out, so odds under them are not merely noisy — they describe a market that will not pay.

A worker process resolves markets on a tick. It counts the matching rows in our own eventstable for the market's window and picks the outcome that count falls into. It never calls a live API at settlement time: a resolution has to be reproducible from stored data, or it cannot be audited.

Event times are the moment our ingestion service received them from the upstream feed, because that feed sends no timestamp of its own. An event within a fraction of a second of a window boundary may land on either side of it.

If feed uptime over the window was below 90%, the market voids and refunds. So does a market with fewer than 2 bettors, under 500 DP staked, or nothing at all on the winning outcome.

Balances change in exactly two places, both SQL functions inside the database: one that places a bet and one that settles a market. Nothing in the application computes a payout and writes it. Settlement is idempotent — retrying a settled market returns immediately — because double-paying is the worst bug this system could have.

Every movement is written to an append-only ledger with a reason. Your balance, your profit and loss curve, and the leaderboard are all derived from it rather than stored separately, so they cannot disagree.

A linked Solana address is an identity and nothing more. No balance, ledger row or market references it, and no code in this product moves value to or from it. There are no payment tables and no token logic.

There is not one yet. When there is, it will be documented here — read endpoints for markets, prices and resolutions first, since those are the parts worth checking independently.