March 24, 2025. A $7M prediction market on Polymarket is waiting to settle. The question: will Ukraine sign a mineral deal with the U.S. before April? The real-world answer is obvious. Ukraine has not signed. Anyone following the news knows “No” wins.
But one wallet, BornTooLate.eth, has spent the past weeks quietly accumulating UMA governance tokens. It is now the fifth-largest staker in the system. Over 48 hours, it casts 5 million votes through three coordinated accounts, representing 25% of all votes cast. The market resolves “Yes.”
The correct side loses $7M. Polymarket calls it “unprecedented.” No exploit was run. No vulnerability was triggered. The oracle worked exactly as designed.1
Two oracle problems with one name
The term “oracle manipulation” covers two completely different attack surfaces that require different defenses.
Price oracles (Chainlink, Uniswap TWAP) measure a continuous numerical variable, the market price of an asset. Security means making it expensive to distort that price during the measurement window. The attack is purely quantitative: an adversary needs to move enough capital to shift the price reading, then profit on a correlated position before the distortion corrects.
Prediction market oracles (UMA, Kleros) adjudicate a binary claim about a real-world event: did Ukraine sign a deal? did the team win the championship? There is no on-chain proof of external truth. Security means making it expensive to corrupt a collective vote about what actually happened. The attack is social: an adversary needs to acquire enough voting power to override honest reporters.
OWASP’s Smart Contract Top 10 (2025) ranks price oracle manipulation as the #2 smart contract vulnerability category.2 But the Polymarket incident was not price oracle manipulation. It was something categorically different, and conflating the two produces security architectures that solve the wrong problem.
How optimistic oracles work
UMA’s optimistic oracle follows a three-phase cycle:3
1. REQUEST : A contract (Polymarket) asks the oracle: "Did Ukraine sign a deal?"
2. PROPOSE : A proposer submits an answer and posts a bond.
If unchallenged within 48 hours, the answer is accepted.
3. DISPUTE : A disputer can challenge the proposal, also posting a bond.
If disputed, UMA token holders vote to resolve.The economic logic is sound at small scale. Lying is unprofitable if the bond you lose on detection exceeds the reward for lying. The Schelling Point assumption: rational actors converge on truth because truth is the answer everyone else will also vote for, and deviating loses your bond.
There is also a griefing vector. A disputer can challenge a correct proposal in the final seconds of the 48-hour window, forcing a full governance vote and delaying settlement. If the disputer holds a correlated market position that profits from delay, the griefing cost (the dispute bond) may be worth paying. UMA’s two-round resolution process doubles the griefing cost, but does not eliminate the vector.4
The griefing problem is manageable. The governance capture problem is not.
The governance capture threshold
Token-weighted voting means the oracle’s security budget is the governance token’s market cap.
This creates a structural threshold. Below a certain payout-to-market-cap ratio, governance token voting is economically secure: acquiring enough tokens to sway a vote costs more than the market at stake. Above that ratio, the incentive inverts: rational stakers should vote dishonestly and profit from both the governance position and the correlated market position.
The math for the Polymarket incident, using approximate figures from the research:
UMA token market cap (approximate): ~$50M
Cost to acquire 25% voting power: ~$12.5M
Market at stake: $7M
Outcome probability before attack: 9% ("No" was overwhelming favorite)
Expected attacker gain from corrupting "No" → "Yes":
$7M × (1 - 0.09) = ~$6.4M from the bet position
plus governance token value retained after vote
Expected loss:
If caught and slashed: governance stake
But: no slashing mechanism for incorrect governance votes in UMAThere is no slashing for dishonest UMA votes. The protocol’s security assumption is that voting incorrectly is irrational because it undermines the token’s value. That assumption holds when the token’s value is large relative to any single market outcome. At $7M on a $50M-cap token, with a coordinated attacker already holding a large stake, the math tilts the other direction.
BornTooLate.eth acquired roughly 1.3 million UMA tokens to become a top-5 staker. Three coordinated accounts cast a combined 5 million votes, representing approximately 25% of total votes. The market resolved incorrectly despite a clear real-world answer.1
This is not a bug. The protocol worked as designed. The design’s assumptions were violated by scale.
Prediction market volume grew from $9B on Polymarket in 2024 to over $20B in 2025.5 The governance token market caps did not grow proportionally. The ratio has been moving in the wrong direction.
The ETH-staked alternative
The structural fix is to decouple oracle economic security from governance token market cap.
A February 2026 proposal on Ethereum Research suggests using ETH as collateral instead of a native governance token.5 ETH’s market capitalization is orders of magnitude larger than any governance token. An attacker acquiring enough ETH to dominate an oracle vote faces a cost ceiling that scales with Ethereum’s total capital base, not with the market cap of a protocol-specific token.
UMA and EigenLayer have an active research partnership exploring restaked ETH as an oracle economic security layer.6 The approach: validators restake ETH into an oracle module, committing that stake to honest dispute resolution. The economic security is now ETH collateral, not UMA market cap.
Kleros took a related approach in its original design. Jurors earn fees in ETH or xDAI , external value , not in PNK, Kleros’s own token. This avoids the circular security model where the token’s value depends on the oracle’s reputation, which depends on the token’s economic security.7
Both approaches share an unresolved problem. Slashing ETH is also a governance act. Someone has to decide whether a particular vote was dishonest and therefore slash-worthy. If that authority lives in a committee or a token-weighted vote, the governance capture risk moves up one layer. The question raised by the ethresear.ch proposal is open: can you design an oracle where slashing decisions are objective enough that they cannot themselves be gamed?5
Detection: price oracles versus governance oracles
The detection approaches for these two attack types are completely different.
For price oracle manipulation, tooling exists. AiRacleX (February 2026) is a three-stage LLM pipeline , knowledge mining, chain-of-thought prompt generation, and smart contract code analysis , that detects price oracle vulnerabilities at the code level.8 Validated against 60 known vulnerabilities from 46 real-world DeFi attacks (2021–2023), it achieves 2.58x improvement in recall over GPTScan (0.667 vs 0.259). It can run on open-source models instead of GPT-4, reducing cost for audit firms.
The remaining gap matters: AiRacleX still misses roughly one in three price oracle vulnerabilities. And it operates on code , static analysis of contracts before deployment.
For governance oracle manipulation, there is no static analysis equivalent. The attack is not in the contract code. A governance vote that resolves incorrectly is indistinguishable from one that resolves correctly at the code level. The manipulation is in token accumulation, wallet clustering, and vote timing , off-chain strategy that produces on-chain traces.
The forensic difference is instructive:
| Attack Type | Trace Span | Key Signals |
|---|---|---|
| Price oracle manipulation | 1–2 blocks | Flash loan, pool swap, price read in same block |
| Governance oracle manipulation | Days to weeks | Token accumulation, wallet clustering, vote timing near window expiry |
Both are fully on-chain. Price manipulation leaves a compact, readable trace in a single block: the flash loan initiation, the pool manipulation that distorts the price, and the oracle read that consumes the distorted price , all sequenced within the same transaction or the same block. Governance manipulation is slower and noisier, but the evidence is there: token acquisition at scale, coordinated voting from multiple accounts, settlement calls timed to challenge window expiry.
What to check before shipping
If you are building or integrating a prediction market oracle:
Calculate the governance capture threshold. Take the governance token’s current market cap and divide by the largest payout in any single market resolution. If the ratio is below 3x, you have a structural risk. A $50M market cap token securing a $20M market is one large bet away from inversion.
Audit the challenge window design. Is griefing profitable given the dispute economics? If a disputer can profit from delaying settlement by holding a correlated position, the dispute bond must exceed that profit. This is worth calculating explicitly, not assuming away.
For price oracles: use TWAP with minimum observation windows, circuit breakers, and multiple independent sources. The OWASP SC02 mitigations are well-established.2 AiRacleX-style LLM scanning is a useful additional pass for catching code-level vulnerabilities your static tools miss.
For governance oracles: monitor governance token concentration. An adversary telegraphs a governance attack before executing it , they have to accumulate tokens first. A large wallet becoming a top-5 staker in a short window is a warning signal. The accumulation is visible on-chain before the attack.
For post-incident forensics:
- Price oracle attack: reconstruct the flash loan block sequence. Look for large pool swaps preceding an unusual price read in the same block. The causal chain is usually one or two transactions.
- Governance oracle attack: trace token accumulation history, cluster coordinated wallets by funding source and voting timing, and compare vote submissions against challenge window expiry. The coordination is visible in the timing.
The on-chain record
The BornTooLate.eth attack is fully reconstructable from on-chain data. Token purchases that built the governance position. The three-account structure. Vote submissions and their timing relative to the challenge window. The final settlement call.
Every step of both attack types , price oracle manipulation and governance oracle manipulation , produces a deterministic sequence of on-chain events. The price manipulation sequence collapses into a few calls in one block. The governance attack spans days of token accumulation and coordinated voting.
Ethernal renders decoded call trees and transaction sequences for any EVM chain, which is exactly the data you need to reconstruct either attack pattern. Transaction tracing with Ethernal covers the mechanics.
The phase transition that matters
Prediction markets grew from $9B to $20B in a single year, and will likely keep growing. Oracle security assumptions written for smaller markets have not been revisited.
The governance capture problem is not exotic. It is the natural result of market volume outpacing governance token capitalization , a ratio that moves in the wrong direction as prediction markets scale. The UMA attack on Polymarket was the first widely visible instance. The design condition that enabled it has not changed.
The ETH-staked research direction is promising. The open problem , governance at the slashing layer , is real and unsolved. Until it is solved, the practical defense is quantitative: calculate the threshold, monitor token concentration, and size governance security relative to the largest market you expect to settle.
The oracle worked exactly as designed. The assumptions of the design were violated by scale. That distinction is the whole problem.
References
1. The Block. “Polymarket says governance attack by UMA whale to hijack a bet’s resolution is ‘unprecedented’.” The Block, March 2025. https://www.theblock.co/post/348171/polymarket-says-governance-attack-by-uma-whale-to-hijack-a-bets-resolution-is-unprecedented
2. OWASP. “SC02 , Price Oracle Manipulation.” OWASP Smart Contract Top 10, 2025. https://owasp.org/www-project-smart-contract-top-10/2025/en/src/SC02-price-oracle-manipulation.html
3. Risk Labs. “What is UMA’s Optimistic Oracle?” blog.uma.xyz, 2024. https://blog.uma.xyz/articles/what-is-umas-optimistic-oracle
4. Rock’n’Block. “How Prediction Markets Resolution Works: UMA Optimistic Oracle & Polymarket.” rocknblock.io, 2024. https://rocknblock.io/blog/how-prediction-markets-resolution-works-uma-optimistic-oracle-polymarket
5. Ethereum Research. “ETH-Staked Oracle for Prediction Markets.” ethresear.ch, February 21, 2026. https://ethresear.ch/t/eth-staked-oracle-for-prediction-markets/24169
6. Risk Labs. “UMA, Polymarket, and EigenLayer Research: A Next-Gen Prediction Market Oracle.” blog.uma.xyz, 2024. https://blog.uma.xyz/articles/uma-polymarket-and-eigenlayer-research-a-next-gen-prediction-market-oracle
7. Kleros. “Kleros and UMA: A Comparison of Schelling Point Based Blockchain Oracles.” blog.kleros.io. https://blog.kleros.io/kleros-and-uma-a-comparison-of-schelling-point-based-blockchain-oracles/
8. Goh, R.S.M. et al. “AiRacleX: Automated Oracle Manipulation Detection Using Multi-LLM Pipeline.” arXiv, February 2026. https://arxiv.org/abs/2502.06348
9. Orochi Network. “Oracle Manipulation in Polymarket 2025.” orochi.network, 2025. https://orochi.network/blog/oracle-manipulation-in-polymarket-2025
