Case Study: Volume Competitions on Predict Markets

A volume competition assumes something that is obvious on a perp DEX and not at all obvious on a predict market: that there is a number called "volume" and everyone agrees when it happened. This is a structural case study of making that assumption true on binary up/down contracts — what counts, when it counts, and what has to be defended against. No results, no commercial terms.

What a predict market trade is

On TurboFlow, a predict market contract is a binary bet on direction. A trader pays a premium denominated in USDT, picks up or down, and picks a duration. At expiry the contract settles: a win pays the premium multiplied by a return rate on top of the stake returned, a loss burns the premium.

That is a materially different object from a perp fill. There is no notional, no leverage, no position that is opened and later closed. There is a premium, a direction, a clock, and a binary outcome.

Volume is the premium, fixed at placement

The scoring definition is one line: an order's volume is its USDT premium, recorded at the moment the order is placed.

Three properties fall out of that, and they are the reason this maps cleanly onto competition scoring at all.

It is known immediately. A perp position's contribution can change as it is added to and closed. A predict order's premium is final the instant it is placed — the trade's size does not evolve. There is no settlement to wait for before the volume number is correct.

It is unleveraged. The premium is money actually at risk. Perp notional is not, which is why perp volume is scored an order of magnitude below spot: leverage makes notional cheap to manufacture. Premium has no such lever. What a trader risks is what they are scored on.

It is direction-neutral. Scoring the premium rather than the outcome means the competition measures participation, not luck. A volume competition on a binary market that scored payouts would be a lottery with extra steps; scoring premium keeps it a volume competition. If you want profit to be the contest, that is a PnL competition and a different design — see volume vs PnL competitions.

Cancelled orders do not count

An order whose status is cancelled is skipped entirely. The reasoning is simply that its premium was refunded, so it never traded.

This is small and it is not optional. Without the exclusion, a trader could place and cancel repeatedly and accumulate scored volume having risked nothing at all — the cheapest possible farm on any competition, requiring no capital and no market view. Volume must mean money that was actually committed, and a refunded premium was not.

The exclusion is also why the sync waits before freezing a day. A day's rows are only closed once three hours have passed beyond the day's end. Since volume is fixed at placement, that buffer exists for exactly one purpose: absorbing late cancellations that would otherwise leave a frozen day overstating what a wallet actually traded.

Why events contracts fit day-bucket scoring

Competitions score in start-anchored 24h buckets: day 1 is the first 24 hours after the competition's start time, day 2 the next, and so on. A competition starting at 14:00 rolls its day at 14:00, not at midnight UTC. Caps and raffle draws use that boundary.

Predict orders slot into that model without any of the ambiguity a position-based venue introduces. Each order has one timestamp — placement — and lands in exactly one bucket, computed as the elapsed time since the campaign start divided by 24 hours. There is no open-and-close pair to split across a boundary, no funding accrual to attribute, and no question about whether a position opened on day 2 and closed on day 4 belongs to either.

That is genuinely rare. On most venues, deciding which day a trade belongs to is a design decision with defensible alternatives. On a predict market it is a lookup.

Orders outside the campaign's day range are dropped, and orders on markets outside the competition's scope are dropped before bucketing. Market scoping uses the same resolution as the rest of the platform: the competition stores its eligible pairs, and an unscoped competition counts every market.

The two data-integrity defences

The venue API shapes the ingestion, and two of its properties would silently corrupt a leaderboard if handled naively.

The window filter is inclusive on both ends. Adjacent day buckets therefore share a boundary second, and an order placed in that second is served in both windows.

Pagination is offset-based, newest-first, with no total count. An order placed while the walk is in progress shifts every later page down by one and causes rows to be served twice. Neither behaviour can skip an order — inserts only happen at the top — but both duplicate.

The consequence is that deduplication is mandatory, not defensive hygiene. Every multi-call fetch funnels through one dedup step rather than each caller remembering. The complication is that the documented item schema carries no order id, so the dedup key prefers an id when the live API supplies one and otherwise falls back to a composite that is unique unless the same wallet places two identical orders on the same pair in the same millisecond.

This is the sort of detail that decides whether a leaderboard is trustworthy. A duplicated row is not a rendering bug — it is a wallet being paid twice for one trade out of a pool that other people are competing for.

Fetching without hammering the venue

The venue exposes per-wallet order history rather than a bulk feed, and windows may span at most 24 hours. That makes a naive sync expensive: every wallet, every day, every tick.

The sync avoids it with one observation — days close in order, so the closed days for a wallet form a prefix of the day list. On each tick it finds the first day that is not yet closed and fetches only from there forward. In steady state that is a single day per wallet; the full window is only read on a wallet's first sync. Wallets are processed with bounded concurrency, and an already-closed day is never re-read, which is also why a closed day's stored value is authoritative rather than recomputed.

One more property worth copying into any venue integration: a single failing wallet — a venue 4xx, malformed data — does not abort the campaign's tick. That wallet keeps its previous values, everyone else stays current, and the failure surfaces through the job's exit code. The alternative, where one bad row freezes an entire leaderboard, is how a competition loses credibility in an afternoon.

What generalises

Three lessons that apply to any venue whose primitive is not a perp fill:

1. Find the moment the size is final, and score that. For predict markets it is placement. Whatever the venue's equivalent is, scoring it removes an entire class of "the number changed after I looked" complaints.
2. Exclude anything refunded, reversed or cancelled — and hold the day open long enough to see it. A settlement buffer is cheaper than a disputed payout.
3. Assume the venue API duplicates. Inclusive windows and offset pagination over a moving list are the norm, not the exception. Build the dedup into the client so no caller can forget it.

For the venue-specific view, read TurboFlow trading competitions. For the full inventory of what a campaign layer has to handle across venue shapes, trading campaign infrastructure for perp DEXs, and for the rules that decide whether counted volume means anything, wash-trading resistance in volume campaigns.