Oracle Collusion Resistance

Oracle Collusion Resistance

Why We Don’t Trust Price Feeds Directly • Pyth + UMA + Future L2-Native Oracle Integrations

SnarkSide's oracle layer is designed from first principles to withstand collusion, manipulation, and latency games—even among “trusted” data providers. The protocol recognizes a foundational truth of DeFi: price feeds are not neutral infrastructure. Every feed, every publisher, and every relay is a potential actor in an adversarial environment.

Rather than trusting any single oracle—whether decentralized or centralized—SnarkSide implements a collusion-resistant aggregation model that enforces price integrity through cryptography, not trust assumptions. This includes multi-source price commitment, time-separated reveal mechanics, and zk-verifiable aggregation logic.

This section explains:

  • Why traditional oracle trust is insufficient for perp DEXs

  • How SnarkSide utilizes providers like Pyth and UMA in a non-trusting architecture

  • How future L2-native oracles will be integrated

  • Why no single actor can move the price on SnarkSide

Why We Don’t Trust Oracles Directly

Perpetual futures DEXs are especially vulnerable to oracle price distortion, because:

  1. Liquidations are price-bound. A small price deviation can trigger massive forced unwind cascades.

  2. Funding depends on mark-vs-oracle delta. Misaligned or manipulated prices distort incentives.

  3. On-chain observability leaks signals. Even correct prices can cause MEV and frontrunning if seen too early.

Thus, trusting oracles directly — even if they’re decentralized — opens up attack surfaces:

  • Flash price manipulation

  • Selective reporting

  • Front-running the price publication

  • Consensus collusion between oracle publishers

SnarkSide’s design assumes these threats are not only possible but inevitable.

Defense Strategy: Oracle Aggregation via zkSNARKs

SnarkSide accepts data from multiple providers (e.g., Pyth, UMA), but doesn’t trust their output. Instead, it applies:

  • Delayed commitment

  • Hashed attestations

  • Epoch-bound aggregation

  • Zero-knowledge proof of median

At the end of each epoch, a zk circuit proves that:

  • A set of valid commitments were published

  • All values were revealed within the time window

  • The final oracle price used for settlement is the median of trusted inputs

This price is:

  • Bound to a specific epoch

  • Anchored in public commitment hashes

  • Proven in zero-knowledge

No party can alter, override, or retroactively influence the result.

Example: Multi-Oracle Aggregation Circuit

Inputs:

  • commitments[PYTH, UMA, L2-Oracle]

  • reveals[PYTH, UMA, L2-Oracle]

  • timestamps

  • block_ts_now

Outputs:

  • oracle_median_price

  • Proof that each reveal matches the original commitment

  • Proof that all prices fall within Δmin–Δmax window

  • Proof that median(price[]) == oracle_median_price

Only the median price is surfaced to downstream circuits.

Oracle Providers

1. Pyth Network

  • High-frequency, publisher-verified oracle

  • Commitments submitted via SnarkSide relayers

  • Integrated via zk-reveal contract and oracle module

2. UMA Optimistic Oracle

  • Used for fallback and dispute resolution

  • Slow, but robust and dispute-aware

  • Provides challenge window for high-risk events (e.g. halts, forks)

3. L2-Native Oracles (Future)

  • Rollup-native price feeds (e.g. Arbitrum Orbit, OP Stack oracles)

  • Committed to on the L2, bridged with delay, then zk-revealed

  • Enables true chain-local data integrity without third-party feeds

Trust-Minimized Assumptions

The only trust assumptions in SnarkSide’s oracle layer are:

  • At least one honest oracle source per epoch

  • Correct execution of Poseidon hash

  • On-chain finality of Merkle root updates

All other behavior (timing, price value, proof validity) is enforced inside SNARKs.

Resistance to Oracle Collusion

Even if multiple oracles collude:

  • They cannot preemptively influence price effects, due to delayed reveal

  • They cannot alter already-committed hashes

  • They cannot inject prices outside of valid time windows

  • They cannot influence funding or liquidation without detection

At worst, collusion delays price publication. It cannot falsify a valid epoch median.

Summary

SnarkSide treats oracles as inputs to constrain, not authorities to trust. By aggregating multiple feeds, requiring delayed zk-verified reveals, and enforcing tight circuit constraints, it prevents:

  • Feed manipulation

  • Collusive bias

  • Early signal leakage

  • Trust-based attack vectors

This architecture ensures that the oracle layer, like the rest of the protocol, is minimally trusted, maximally verifiable, and entirely opaque to front-runners and attackers.

PreviousCircuit ConstraintsNextZK Tookit

Last updated