ETH-Staked Oracle for Prediction Markets

ethresear.ch

Motivation Prediction markets are scaling fast (~$9B volume on Polymarket in 2024, over $20B in 2025), but oracle security is not keeping up. Existing oracles (UMA, Kleros) rely on governance tokens for economic security. This has been exploited in practice : when $7M+ in bets depend on a token with $50M market cap, attack economics become favorable. The root vulnerabilities: linear stake-weighted voting (whales dominate), predictable voter sets (enables coordination), and security budgets capped by governance token market cap. I propose a different approach: an oracle where security is denominated in ETH and attack cost scales with ETH’s market cap rather than a governance token’s. Architecture ETH Deposit -> Liquid Staking (Lido/RocketPool/cbETH) -> ~2.8-3% APY | Validator Pool (global, single pool for all markets) | VRF Panel Selection (per market) / \ Panel A Panel B <- simultaneous, independent (commit-reveal) (commit-reveal) \ / Compare | A = B -> finalize (48h) A != B -> Panel C (VRF, disjoint set) -> 2-of-3 rule (96h) The protocol combines three primitives: quadratic voting weight, VRF-based random panels, and parallel multi-round resolution. Each is well-studied individually ( QV with sortition , QSort , Kleros appeals). The contribution is their synthesis into an oracle protocol where the weaknesses of each primitive are covered by the others. Protocol Design 1. ETH Staking with Quadratic Weight Validators deposit ETH (minimum 1 ETH) into the protocol. Deposits are routed through a liquid staking provider, so staked ETH generates yield (~2.8-3% APY). Distribution: 80% to validators, 20% to the rewards pool. Lock-up periods : 14-day entry lock (prevents flash attacks - an attacker cannot deposit and immediately participate), 14-day exit lock (ensures slashing can be applied before withdrawal). Voting weight : W_i = \sqrt{S_i} This is the key mechanism against whale dominance. The cost of influence is quadratic: Stake Linear Weight Quadratic Weight Cost per vote 1 ETH 1 1 1 ETH 4 ETH 4 2 2 ETH 25 ETH 25 5 5 ETH 100 ETH 100 10 10 ETH A rational actor will split stake across wallets: 100 wallets x 1 ETH = 100 votes for 100 ETH, versus 10,000 ETH for 100 votes in one wallet. This sybil strategy is expected and accounted for - it shifts the attacker’s problem from “buy enough tokens” to “register and lock thousands of wallets for 14 days,” which is both capital-intensive and detectable. See the attack analysis below for the full cost calculation. 2. VRF Panel Selection When a market needs resolution, the protocol selects a random panel from the global validator pool: \text{seed} = \text{VRF}(\text{marketId}, \text{roundNumber}, \text{blockHash}) Selection is weighted random sampling without replacement - each validator’s probability of selection is proportional to \sqrt{\text{stake}} . Panel sizing scales with market volume (higher stakes → larger panels → harder to manipulate): Market Volume Panel Size Range Min Pool Required < $100K 50-200 600 $100K-$1M 100-500 1,500 > $1M 300-2,000 6,000 The pool must contain at least 3 \times \text{maxPanelSize} eligible validators to ensure three disjoint panels are possible (for rounds 1, 2, and a potential round 3). Quorum : 30% of panel size. If quorum is not met within the reveal period, the deadline extends by 24h (once). If still not met, the round defaults to the other round’s outcome. If no round reaches quorum, the market is marked unresolvable and all stakes are returned without slashing. Exclusion between rounds : \text{Excluded}_{R2} = \text{Panel}_{R1} \text{Excluded}_{R3} = \text{Panel}_{R1} \cup \text{Panel}_{R2} A validator cannot vote twice in the same market. This guarantees each round is decided by a different set of validators. 3. Parallel Commit-Reveal Voting The core design choice: rounds 1 and 2 run simultaneously on independent panels . Panel A: [ Commit 24h ][ Reveal 24h ] -> Compare results Panel B: [ Commit 24h ][ Reveal 24h ] t=0 t=48h Commit phase : each validator submits a hash: \text{commitment} = \text{keccak256}(\text{vote} \| \text{salt} \| \text{address}) Reveal phase : validator reveals the plaintext vote and salt. The contract verifies the hash matches. Why parallel matters : in sequential systems, the R1 result is public before R2 starts. This leaks information - R2 voters can anchor on R1’s outcome instead of voting independently. Parallel panels are truly independent Schelling point games. Each panel reaches consensus without knowing what the other decided. Finalization (2-of-3 rule) : R1 R2 R3 Final Result Time YES YES - YES 48h NO NO - NO 48h YES NO vote 2-of-3 96h NO YES vote 2-of-3 96h When R1 and R2 agree, the result is final at 48h - no waiting for appeals. When they disagree, Panel C is drawn from the remaining pool (excluding R1 and R2 validators) and breaks the tie. 4. Tiered Slashing Validators who vote against the final result (across all rounds) are slashed. Rates scale with market volume - higher-value markets impose stronger penalties: Market Volume Slash Rate < $100K 2% $100K-$1M 5% $1M-$10M 10% > $10M 15% Slashed funds are distributed: 80% to majority voters (proportional to \sqrt{\text{stake}} ), 20% to the general rewards pool. In a 2-of-3 scenario (e.g. R1=YES, R2=NO, R3=YES → final YES), all NO voters across all three rounds are slashed equally. This incentivizes honest voting regardless of which round you’re assigned to. 5. Quality Index and Reputation Each validator maintains a cumulative quality score: Q_i^{(t+1)} = Q_i^{(t)} + \Delta Q, \quad \Delta Q = \begin{cases} +1 & \text{majority} \\ -1 & \text{minority} \end{cases} New validators start at Q_0 = 0 If Q < -20 : slash 10% + 90-day ban Return after ban: Q_0 = -10 , new 14-day lock-up Repeat offenders lose 10% each time - persistent bad behavior is progressively more expensive Inactivity slashing : validators selected to a panel but who don’t vote are slashed 0.1% of stake per miss . This eliminates free-riders who stake for yield but never participate in resolution. 6. Reward Structure Honest validators earn from three sources: Market fee : 0.5% of trading volume Slashed ETH : redistributed from minority voters Staking yield : 20% of liquid staking APY routed to rewards pool Distribution for validator i in the majority: \text{Reward}_i = \text{RewardPool} \times \frac{\sqrt{S_i}}{\sum_{j \in \text{majority}} \sqrt{S_j}} Reward conditions: voted (commit + reveal), in majority, Q \geq -20 . 7. Validator Lifecycle None --stake()--> LockIn (14d) --> Active | +--exit()--> ExitReq --> LockOut (14d) --> Exited | +-- Q < -20 --> Banned (10% slash, 90d) --> LockIn (Q=-10) The state machine ensures validators cannot enter or exit the system quickly enough to exploit timing. A validator must be Active for at least 14 days before they can be selected for panels, and must wait 14 days after requesting exit before withdrawing - during which pending slashing can still be applied. Attack Analysis Sybil Attack Cost The rational attacker uses minimum-stake wallets (1 ETH each, \sqrt{1} = 1 weight per wallet - best ratio). Assumptions : honest pool of 10,000 validators, average stake 5 ETH. Total honest weight: 10{,}000 \times \sqrt{5} \approx 22{,}360 To control >50% of expected panel weight, the attacker needs A > 22{,}360 sybil wallets: \text{Attacker share} = \frac{A}{22{,}360 + A} > 0.5 \implies A > 22{,}360 Cost : ~22,400 ETH (~$52M at $2,300/ETH), all locked for 14 days. ROI Calculation ($10M market) Value Potential profit (50% of market) $5M Capital required (stake) $52M Capital lock-up 28 days ROI on success 9.6% Loss on failure (15% slash) -$8M The expected value is negative: the attacker risks $8M to gain $5M, with capital locked for a month. The attack is also detectable - a sudden influx of 22K minimum-stake validators during a 14-day lock-in period is a clear anomaly. Why Governance Token Attacks Don’t Apply In this protocol, the attack asset is ETH - the most liquid asset in the ecosystem. You cannot meaningfully move ETH’s price by buying $52M worth. Compare this to governance token attacks where acquiring 25% of staked tokens can be enough to manipulate outcomes, and tokens can be sold back after voting. Here, failed attacks result in permanent ETH slashing. Detection and Response The 14-day entry lock creates a window for detection. If the protocol observes an anomalous spike in new minimum-stake registrations, it can: Increase panel sizes for pending markets Alert the community The honest validator pool has time to respond (stake more, recruit more validators) This is fundamentally different from flash-loan or same-block attacks - the attacker must commit capital and wait. Open Questions I’d appreciate feedback on these points: Sybil capital threshold : is $52M+ with 14-day lock sufficient deterrence, or are there cheaper attack paths I’m missing? Could an attacker profitably target only low-volume markets where panels are smaller? MEV and VRF seeds : the seed includes blockHash , which the block proposer controls. Could a proposer manipulate panel composition? What randomness source would provide sufficient protection? Parallel voting independence : the design assumes parallel panels produce independent Schelling point outcomes. Could validators on Panel B try to anticipate Panel A’s result? Does true independence require additional mechanism design? Quality index gaming : a validator could vote honestly on low-value markets (building Q score) and dishonestly on high-value ones. Should \Delta Q scale with market size? Parameters All numeric values are initial estimates for discussion. Production values should be determined through testnet experimentation and economic simulation. The design constraints: Minimum stake → sybil capital requirement stays high Lock-up duration → flash attacks remain impossible Panel sizes → scale with market value at risk Slash rates → dishonest voting is negative-EV at every tier Quality thresholds → filter persistent bad actors, tolerate honest mistakes Full specification: GitHub repository (MIT License). Prior Work This design builds on: QV with sortition (Vitalik, 2019) , QSort , oracle voting rules , Kleros (random juries + sequential appeals), and UMA DVM 2.0 (commit-reveal + slashing). 1 post - 1 participant Read full topic