ETH-Staked Oracle for Prediction Markets

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}Wi=Si

This is the key mechanism against whale dominance. The cost of influence is quadratic:

StakeLinear WeightQuadratic WeightCost per vote
1 ETH111 ETH
4 ETH422 ETH
25 ETH2555 ETH
100 ETH1001010 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})seed=VRF(marketId,roundNumber,blockHash)

Selection is weighted random sampling without replacement - each validator’s probability of selection is proportional to \sqrt{\text{stake}}stake.

Panel sizing scales with market volume (higher stakes → larger panels → harder to manipulate):

Market VolumePanel Size RangeMin Pool Required
< $100K50-200600
$100K-$1M100-5001,500
> $1M300-2,0006,000

The pool must contain at least 3 \times \text{maxPanelSize}3×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}ExcludedR2=PanelR1
\text{Excluded}_{R3} = \text{Panel}_{R1} \cup \text{Panel}_{R2}ExcludedR3=PanelR1PanelR2

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 resultsPanel 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})commitment=keccak256(votesaltaddress)

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):

R1R2R3Final ResultTime
YESYES-YES48h
NONO-NO48h
YESNOvote2-of-396h
NOYESvote2-of-396h

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 VolumeSlash Rate
< $100K2%
$100K-$1M5%
$1M-$10M10%
> $10M15%

Slashed funds are distributed: 80% to majority voters (proportional to \sqrt{\text{stake}}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}Q(t+1)i=Q(t)i+ΔQ,ΔQ={+1majority1minority

  • New validators start at Q_0 = 0Q0=0
  • If Q < -20Q<20: slash 10% + 90-day ban
  • Return after ban: Q_0 = -10Q0=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:

  1. Market fee: 0.5% of trading volume
  2. Slashed ETH: redistributed from minority voters
  3. Staking yield: 20% of liquid staking APY routed to rewards pool

Distribution for validator ii in the majority:

\text{Reward}_i = \text{RewardPool} \times \frac{\sqrt{S_i}}{\sum_{j \in \text{majority}} \sqrt{S_j}}Rewardi=RewardPool×SijmajoritySj

Reward conditions: voted (commit + reveal), in majority, Q \geq -20Q20.

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} = 11=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{,}36010,000×522,360

To control >50% of expected panel weight, the attacker needs A > 22{,}360A>22,360 sybil wallets:

\text{Attacker share} = \frac{A}{22{,}360 + A} > 0.5 \implies A > 22{,}360Attacker share=A22,360+A>0.5A>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-up28 days
ROI on success9.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:

  1. 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?

  2. 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?

  3. 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?

  4. Quality index gaming: a validator could vote honestly on low-value markets (building QQ score) and dishonestly on high-value ones. Should \Delta QΔ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).


Source
Disclaimer: The content above is only the author's opinion which does not represent any position of Followin, and is not intended as, and shall not be understood or construed as, investment advice from Followin.
Like
51
Add to Favorites
11
Comments