← Back to Prediction Circuit

How wagering works

Last updated: April 15, 2026

This page describes how Prediction Circuit handles wagering mechanics as implemented in our backend services: escrow, fees, matching, and settlement. Numeric rules come from the live server logic (including the order-book and wager resolution flows). Platform configuration (fee percentages, limits, and multipliers) can change over time; what follows is the structure of the math, not a guarantee of current parameter values.

1. Two balance modes

  • Forecast Points (FP) — virtual credits for free play. They are debited from your account balance when you trade or post wagers.
  • Stablecoins (USDT / USDC) — real funds held in the platform wallet: amounts are reserved from your available balance when you place a crypto wager or order, then moved at settlement.

2. Order book (limit orders)

The order book lets you bid for YES or NO contracts at a limit price between $0.01 and $0.99 per contract, in $0.01 ticks. Multi-outcome markets require an outcome ID on each order so liquidity is scoped to the correct option.

2.1 Escrow per contract

When you submit an order, the system locks enough collateral to cover the worst case if your order trades:

YES at price P → escrow per contract = P
NO at price P → escrow per contract = 1 − P

Total escrow for the order is that per-contract amount times the order size (quantity). The system also reserves an estimate for the taker fee (see below) so you cannot over-commit your balance.

2.2 Maker and taker (who is who?)

These words describe roles in a single trade, not “good vs bad” participants. Every fill has exactly one maker side and one taker side for that fill.

  • Maker (liquidity provider) — A trader whose limit order is already on the book when the trade happens. They posted a price and quantity they were willing to trade at and were willing to wait for a counterparty. Their order rests (stays visible) until it is matched, fully filled, or cancelled.
  • Taker (liquidity taker) — A trader whose order executes immediately against one or more existing resting orders because it crosses the book (it is marketable at the current best opposite-side prices). The taker is the aggressor: they lift the existing quotes instead of waiting.

On Prediction Circuit’s matching engine, the new incoming order that walks the opposite side of the book is the taker for each slice of volume it fills. Each resting order it hits is the maker for that slice. The fill price for that trade is always the maker’s limit price (the price that was already on the book).

If your own order only sits on the book and someone else hits it later, you were the maker for those fills. If your order comes in and matches right away, you are the taker (for that order’s executed portion). A large taker order can match many maker orders in sequence; each piece is a separate fill with its own maker/taker fees.

Fee quote in the app assumes you are taking liquidity (it estimates taker fees). If you end up as a maker because your order rests first, you are not charged the taker fee on that volume; maker fees follow the separate maker schedule (often zero depending on configuration).

2.3 Matching

Incoming orders walk the opposite side of the book (best prices first). The fill price is the resting (maker) order’s limit price. Each fill is recorded with that price, quantity, and separate taker and maker fee amounts.

2.4 Trading fees (Kalshi-style “kalshi_v1” model)

Fees use a quadratic-in-price schedule (same family as Kalshi’s formula). With:

  • C = contracts in the fill
  • P = fill price in dollars (0 < P < 1)
  • ktaker, kmaker = multipliers from platform configuration
fee_raw = k × C × P × (1 − P)
Then: round to 6 decimal places (mode from config, default toward ceiling), clamp to min/max fee if set.

Taker and maker fees are computed independently from the same fill. Maker fee uses its own k; if maker k is zero, makers pay no fee. Configuration is loaded from the database (ob_taker_k, ob_maker_k, min/max fee in cents, rounding mode).

The public fee quote endpoint combines escrow and estimated taker fee into a total cost for a hypothetical taker trade at a given price and size.

2.5 Settlement when the market resolves

After the market outcome is known, each filled order-book contract pays $1 per contract to the winning side (in the market’s currency — e.g. USDT notionally pegged to $1). Concretely, for a fill at price P with quantity Q:

Maker locked: P × Q
Taker locked: (1 − P) × Q
Winner receives: Q (full notional redemption)

Trading fees were already collected at fill time; settlement does not re-apply that fee on top of the redemption.

Any unfilled portion of resting orders is refunded at the same per-contract escrow rate (YES → P, NO → 1−P) when the market is resolved.

3. Peer wagers (create + match)

You can post a simple wager on an open market: you pick YES or NO and stake an amount. Another user matches by putting up the counter stake. When the wager is fully locked, both sides’ funds stay in escrow until resolution.

3.1 Platform fee on payout

For locked peer wagers, the resolver computes a gross payout pool from both stakes, takes a platform fee from that pool using basis points (fee_bps), and credits the net amount to the winner.

payout_gross = creator_stake + filler_stake
fee = floor(payout_gross × fee_bps / 10000) (if fee_bps > 0)
payout_net = payout_gross − fee

The default fee percentage for new wagers comes from platform configuration (default_fee_pct), which is also used to derive fee_bps where applicable.

3.2 If the market resolves before the wager fills

Open or partially filled legacy wagers can be unwound: unfilled stakes are released, and matched portions may be refunded according to the resolution job’s rules for that market state.

4. House AMM (fixed decimal odds)

On supported markets you can take a quoted side against house liquidity. At creation, the platform sets decimal odds (within configured min/max) and splits liability:

house_stake = user_stake × (decimal_odds − 1)

Both your stake and the house’s stake are reserved up front; the contract is immediately locked. At resolution, the same style of gross pool minus bps fee settlement applies as for other locked crypto wagers (fee taken from the winning payout).

5. Resolution and truth

Markets are resolved when administrators set the official outcome. Until then, orders and wagers are subject to market status (open vs resolved) checks. Void or special-case handling (where applicable) follows platform rules described in the Terms of Service.

6. How to use the product (UI)

  1. Fund — For crypto, deposit stablecoin and wait for confirmations; for FP, use granted or earned points.
  2. Pick a market — Read the question and resolution criteria.
  3. Trade — Either place order-book bids (price and size) or participate in peer/house flows offered in the app.
  4. Track — Open orders, fills, and locked wagers appear in your activity; fees are reflected per fill or at payout as above.
  5. Settlement — After resolution, winnings credit your available balance (crypto) or FP balance; withdraw crypto per wallet settings where supported.

This guide summarizes backend behavior for transparency. If any description conflicts with the Terms of Service or with a displayed fee or limit in the app, the in-product disclosure and governing terms take precedence.

© Prediction Circuit
Privacy Policy · How wagering works · Terms of Service