Circuit Constraints
Circuit Constraints
Valid Price Update Range • Finality via ZK-Verifiable Time Delay
The cryptographic integrity of SnarkSide’s oracle layer depends not only on the validity of the price data, but on its temporal correctness: that is, the guarantee that an oracle value was committed before it was revealed, used, and acted upon — and that this occurred within a deterministic and unforgeable time window.
This is enforced through a series of ZK-enforced circuit constraints that bind each oracle value to a commitment timestamp and apply strict rules for minimum latency (preventing premature reveals) and maximum staleness (ensuring time-bounded relevance). The goal is to enable fully trustless oracle usage without exposing real-time price data to adversaries or manipulators.
This section details the constraint logic used inside SnarkSide’s circuits to enforce price update validity, finality, and determinism.
Oracle Commitments and Temporal Guarantees
When an oracle publishes a price, it does so in two stages:
Commit phase:
C_t = Poseidon(price_t, timestamp_t, oracle_secret)Included in OracleRoot[t] as a Merkle leaf.
Stored off-chain or in a registry smart contract.
No price value revealed.
Reveal phase:
The oracle submits:
price_ttimestamp_toracle_secretZK proof:
Poseidon(price_t, timestamp_t, oracle_secret) == C_t
Once verified, the price is usable for epoch t.
Valid Price Update Range
To ensure oracle data is neither too old nor leaked too early, we define a bounded time interval for usage:
Minimum delay (Δmin): Prevents immediate reveal after commit.
Maximum window (Δmax): Prevents reuse of stale price data.
Let block_time_now be the current time during proof generation.
Constraint 1: Delay enforcement
assert(timestamp_t + Δmin ≤ block_time_now ≤ timestamp_t + Δmax)This ensures:
No oracle value is revealed before the minimum delay has elapsed.
No oracle value is used after it has expired.
These bounds are parameterized per asset (e.g., 30s ≤ Δ ≤ 5m) to balance latency and security.
Finality via ZK-Verifiable Time Delay
ZK circuits cannot observe real time directly. Instead, block timestamps or slot heights are passed as public inputs, and must match:
The timestamp in the oracle reveal
The epoch during which the price is being applied
Constraint 2: Timestamp inclusion
Each price is applied inside a proof that includes:
epoch_idoracle_priceoracle_timestamporacle_commitmentcurrent_block_timestamp(public input)
The circuit enforces:
assert(epoch_id * EPOCH_SIZE ≤ oracle_timestamp ≤ (epoch_id + 1) * EPOCH_SIZE)This binds each price to its intended epoch, and ensures that revealed prices are final: they cannot be altered, revoked, or overwritten after being applied.
Circuit Snippet (Pseudocode)
signal input price;
signal input ts_price;
signal input block_ts_now;
signal input commit_hash;
signal private oracle_secret;
signal computed_hash;
computed_hash <== Poseidon(price, ts_price, oracle_secret);
assert(computed_hash == commit_hash);
assert(ts_price + MIN_DELAY <= block_ts_now);
assert(block_ts_now <= ts_price + MAX_WINDOW);This basic constraint set can be extended to multi-oracle aggregation, price curve validation, and funding index anchoring.
Resistance to Manipulation
SnarkSide’s time-bound constraint model ensures that:
Prices cannot be backdated or pre-committed after-the-fact.
Traders cannot use future knowledge to game funding or liquidation.
Relayers cannot selectively reveal prices that favor their trades.
Because the price becomes usable only after a verifiable time delay — and only if it was committed correctly — the system enforces temporal integrity via cryptography, not trust in network actors.
Summary
The circuit constraints that govern SnarkSide’s oracle system turn real-time market data into final, tamper-proof inputs:
Bounded by strict, verifiable time ranges
Proven with zero-knowledge constraints
Applied without trust in oracle sequencing or honesty
These mechanisms remove the possibility of price manipulation, race conditions, or selective reveal — making price truth a cryptographically constrained event, not an exploitable mechanism.
Last updated