Oracle Commit-Reveal Flow

How SnarkSide Avoids Price Leakage

Oracles are critical infrastructure for on-chain derivatives. Yet in most decentralized exchanges, oracle data — especially real-time prices — represents a major surface for exploitation. When prices are posted transparently, traders and bots can pre-position around them, trigger liquidation cascades, or even manipulate thin oracles with low-latency trades.

SnarkSide fundamentally reimagines oracle integration. Instead of posting prices directly, it introduces a commit-reveal system, where price updates are committed cryptographically before they're revealed for verification in zk circuits. This design preserves price integrity, minimizes timing attacks, and allows oracle data to be verified without immediate public exposure.

This section outlines the full mechanics of SnarkSide’s oracle layer, its trust assumptions, data commitment structure, reveal timing, and the role of zero-knowledge in securing price feeds.

The Problem with Transparent Oracles

In most DEXs:

  • Oracle prices are posted on-chain each block.

  • Trades and liquidations use this price immediately.

  • Attackers can manipulate thin markets just before oracle snapshots.

  • Liquidation bots front-run public oracle updates.

This creates a perpetual race condition where the most informed (or fastest) actor always wins — undermining fairness, especially in leveraged perp systems.

SnarkSide’s Approach: Delayed Verifiable Oracles

SnarkSide uses a two-phase oracle posting model, anchored in zkSNARKs and commit-reveal design:

Phase 1: Commit (Price Hash)

At block t, an oracle publisher posts:

commitment = Poseidon(price, timestamp, oracle_secret)

This is included in the next Merkle root for OracleRoot[t].

Phase 2: Reveal (Price + Proof)

At block t+n, the oracle publisher submits:

  • price

  • timestamp

  • oracle_secret

  • ZK proof that Poseidon(price, timestamp, oracle_secret) == commitment

This proves the price was known at t, not generated after seeing market activity.

Only once the reveal proof is accepted can the price be used in:

  • Liquidation circuits

  • Funding index updates

  • Position constraint validation

OracleCommit Data Structure

struct OracleCommit {
  bytes32 priceCommitment;
  uint64  commitTimestamp;
  address publisher;
}

Public Inputs in Circuit:

  • price_commitment

  • oracle_timestamp

Private Witness:

  • raw_price

  • oracle_secret

Constraint:

assert(Poseidon(raw_price, oracle_timestamp, oracle_secret) == price_commitment)

This constraint is verified inside all SNARKs that rely on oracle data.

Pricing in Circuits

Once the price is revealed and verified:

  • It is injected into circuits for liquidation, funding, and price-bound matching.

  • It is referenced only as a bound constraint, not an absolute value.

  • The oracle price commitment hash is included in batch attestations, preserving immutability.

Preventing Manipulation & Front-Running

SnarkSide’s commit-reveal design:

  • Introduces a delay buffer between price knowledge and price usage.

  • Breaks real-time prediction of liquidation triggers.

  • Prevents bots from acting between price posting and trade submission.

  • Avoids oracle spoofing by anchoring price provenance in a verifiable hash.

Additionally, no user can act on unrevealed oracle data, as circuits will reject proofs without a revealed commitment.

Multi-Oracle Aggregation

SnarkSide supports aggregation of:

  • Pyth

  • Switchboard

  • Chainlink

  • Custom institutional feeds

Each oracle commits individually. At reveal time, a weighted median proof circuit is run that:

  1. Verifies each commitment.

  2. Confirms reveal within delay bounds.

  3. Computes secure median from n-of-m submissions.

This design is:

  • Sybil-resistant

  • Latency-neutral

  • Chain-agnostic

Attestation Timers

Every oracle commit includes a required reveal window:

  • Minimum delay (Δmin): prevents reveal in same block

  • Maximum delay (Δmax): expires commitment if too late

assert(block.timestamp ∈ [commit + Δmin, commit + Δmax])

This is enforced at circuit level for all price-sensitive state transitions.

Summary

SnarkSide’s oracle system provides:

  • Cryptographically delayed oracle data

  • SNARK-verified integrity of historical prices

  • Attack-resistance against liquidation and skew front-running

  • Aggregation of multiple oracle feeds without leaking which feed was used

This system ensures that prices are known, but not gameable — enabling fair, predictable execution even in adversarial environments. On SnarkSide, price truth is enforced by cryptographic time anchoring, not blind trust in feeds.

PreviousFunding Rate ModelNextCircuit Constraints

Last updated