What it is
A parimutuel market is a betting or prediction structure where all wagers on a given event are pooled together by outcome, with no fixed odds set in advance. Once the event resolves, the entire losing pool (minus any fee) is redistributed to everyone who bet on the winning outcome, in proportion to how much they staked. This is the same model used for over a century in horse-race betting, adapted on-chain for prediction markets, sports betting, and other binary or multi-outcome events.
How it works
- A market is created for a future event with two or more possible outcomes (e.g., "Team A wins" vs. "Team B wins," or a price range for an asset).
- Users deposit funds into the pool for whichever outcome they believe will happen; the smart contract simply tracks each outcome's cumulative pool size and each user's contribution to it.
- Unlike an order book or AMM, there's no live "price" being quoted for a bet — the implied odds only emerge from the ratio of pool sizes, and that ratio shifts continuously as more bets come in on either side.
- Betting typically closes at a defined cutoff (event start, oracle-set deadline), after which no new stakes can join either pool.
- After the event resolves — usually via an oracle or a designated reporter — the contract determines the winning outcome and computes each winning bettor's payout as
(their stake / winning pool total) × total pool across all outcomes, minus a protocol fee. - Losing bettors' stakes are fully absorbed into the payout for winners; there is no counterparty risk to a specific market maker, since the pool itself is the counterparty.
Why designers use it
- Requires no market maker or liquidity provider to set prices, which removes the need for someone to take on directional inventory risk.
- Guarantees the pool is always exactly balanced (payouts can never exceed what was collected), so there's no solvency risk from mispriced odds.
- Works well for thin or infrequent markets (niche events, long-tail predictions) where a traditional order book would have no liquidity.
- Simple to implement and reason about on-chain, since it only requires tracking pool totals and a resolution oracle, not a pricing curve or matching engine.
Failure modes
- Late-bet sniping: because the payout ratio isn't locked in until betting closes, bettors can wait until just before the cutoff to bet on an outcome that's become obviously likely, capturing most of the reward with little actual risk (a well-known parimutuel exploit).
- No price discovery mid-event: since implied odds only reflect the ratio of money already in the pool, they lag real-world information until enough people bet on the new information, unlike a continuously priced order book or AMM.
- Oracle dependency: the entire payout hinges on correctly and honestly resolving the outcome, so a manipulated or delayed oracle directly steals from or misallocates the pool.
- Thin-pool distortion: if one side of the pool is very small, a single large bettor can dominate the effective odds or, worse, make the payout on that side economically irrational for further bettors, discouraging participation.
- Liquidity lock-up: funds are illiquid from the moment of the bet until resolution, with no way to exit early unless the protocol explicitly builds a secondary market for positions.
What to check before using it
- Check whether the design includes protections against late-bet sniping, such as time-weighted stakes or a betting-close buffer before the event.
- Verify the oracle or resolution source is credible, timely, and resistant to manipulation or disputes.
- Look at expected pool depth for the markets you plan to run — very thin markets produce distorted, easily-gamed odds.
- Confirm the fee structure (rake) is disclosed and reasonable, since it's deducted from the winning pool before payout.
- Assess whether users need an exit path before resolution (a secondary market or cancellation mechanism), since parimutuel positions are otherwise locked until the event settles.