Prediction markets have exploded in popularity since 2024, with platforms like Polymarket and Kalshi processing billions in trades. But behind every market lies a smart contract that must handle money, oracles, and complex settlement logic. A single bug can drain funds or freeze payouts. If you’re building or auditing a prediction market in 2026, you need a systematic checklist that covers the unique attack surfaces these protocols face.
Top 10 vulnerability classes in prediction markets
Prediction market contracts face risks that traditional DeFi protocols rarely encounter. Flash loan attacks can manipulate market prices before oracle snapshots. Integer overflow in share calculations can mint infinite positions. Access control flaws let unauthorized accounts resolve markets early or incorrectly. Timestamp dependence creates front-running windows around settlement. Gas griefing can block mass claim operations. Check for unsafe external calls to oracle contracts, missing input validation on market parameters, and improper handling of edge-case outcomes like ties or cancellations.
Rounding errors in binary contracts can leak value over thousands of trades. Always verify that share minting and redemption math is symmetric and that dust amounts cannot accumulate into exploitable sums. Test every arithmetic operation with boundary values: zero shares, maximum supply, and fractional outcomes.
Oracle manipulation attack surface
Oracles are the Achilles’ heel of any prediction market. An attacker who controls or manipulates the data feed controls the payout. Review oracle update frequency, the number of independent sources, and the delay between data submission and settlement. Single-source oracles are trivial to exploit. Multi-signature schemes must enforce minimum signer thresholds and prevent collusion. Time-weighted average prices (TWAP) can resist short-term manipulation but introduce lag that traders may exploit.
Check whether the contract validates oracle signatures on-chain and whether it includes dispute windows. A robust design lets users challenge suspicious outcomes before funds unlock. Test what happens if the oracle goes offline, returns malformed data, or submits conflicting results.
Settlement and dispute edge cases
Settlement logic must handle every possible outcome: binary yes/no, scalar ranges, categorical buckets, and ambiguous results. What happens if a sports match is canceled? If an election is contested? If the oracle reports an outcome outside the defined range? Your contract should define fallback rules, refund mechanisms, or governance votes for edge cases.
Dispute windows introduce new risks. Can a malicious actor spam disputes to delay payouts? Does the contract lock funds indefinitely if a dispute never resolves? Ensure that dispute bonds are high enough to deter abuse but low enough to allow legitimate challenges. Test re-entrancy during dispute submission and resolution.
Reentrancy in claim flows
Claim and withdrawal functions are prime targets for reentrancy attacks. If your contract calls an external token or sends ETH before updating internal balances, an attacker can recursively call back and drain funds. Use checks-effects-interactions: validate conditions, update state, then transfer assets. Consider reentrancy guards on every function that moves value. Test with malicious ERC-20 and ERC-721 tokens that trigger callbacks.