Execution Pipeline

Execution Pipeline

The execution pipeline of SnarkSide is a deterministic, multi-phase flow that translates a user's encrypted trade intent into a finalized, zero-knowledge-verified state transition on-chain. Unlike traditional DEX pipelines, which expose critical operations (order submission, price movement, slippage, position state) in a fully observable mempool-to-contract flow, SnarkSide redefines execution as a non-interactive constraint resolution process — one that occurs across four cryptographically-bound stages: Intent Generation, Private Matching, ZK Settlement, and Vault Transition.

This section dissects each phase of that pipeline in rigorous detail, mapping the lifecycle of a trade from the moment a trader composes an intent to the final insertion of their position into the shielded vault tree.

Step-by-Step Lifecycle of a SnarkSide Trade

Below is a high-level view of how the SnarkSide execution pipeline unfolds, followed by in-depth breakdowns of each phase.

1. User: Define trade parameters and local proof generation
2. Intent: Construct ZK-valid trade intent with nullifier protection
3. Matching: Off-chain MPC-based intent resolution into match proof
4. Settlement: On-chain SNARK proof verification, margin enforcement
5. Vault: Encrypted state commitment and position root update

Each step is cryptographically bound to the prior through hash-based linkage and circuit-constrained validity. No external trust assumption is required.

1. User Phase: Encrypted Trade Composition

The user begins by composing a trade locally using the SnarkSide zkWallet SDK. Unlike a typical DEX, this process does not involve signing a transaction or interacting with a contract. Instead, the user generates a ZK-valid intent commitment, defined by the following fields:

Field
Description

side

Long (1) or Short (0)

notional_value

Trade size (blinded, committed via Poseidon)

slippage_limit

Optional entry tolerance

leverage

Multiplicative factor, private to user

expiry_block

Expiration epoch for intent validity

salt

Unique randomness to prevent correlation

nullifier

Prevents replay and double-submit scenarios

These values are then passed into a local circom circuit, which outputs a zkSNARK proof that validates:

  • All field constraints are within safe operational bounds

  • The user has computed a unique nullifier for anti-collision

  • The commitment hash derived from the above is consistent

The output of this step is:

  • A proof.json

  • A witness.wtns

  • An intentCommitment hash

This commitment is submitted to the relayer network over encrypted WebSocket without revealing intent data or wallet linkage.

2. Intent Layer: Stateless Submission to Relayer Mesh

Once the encrypted intent has been generated, it is submitted to the DarkMatch intent pool, a decentralized relayer mesh operating a real-time encrypted intent aggregation service. Each intent arrives as a pure hash commitment with a blinded origin, no wallet address, no signature, and no value transferred.

Internally, each relayer validates:

  • Proof correctness using the verification key and public inputs

  • Duplicate nullifier detection

  • Expiry compliance

Valid intents are indexed by:

  • commitmentHash: Poseidon(side, notional, slippage, salt)

  • expiryBlock

  • intentID: derived from proof + internal state

This results in a distributed ledger of encrypted trade capability, not trade requests. This distinction is essential. The network does not yet know whether a trade will happen — it merely knows that a user is capable of executing a valid trade under the specified constraints.

3. Matching Phase: Off-Chain Constraint Resolution

Relayers in the DarkMatch engine continuously scan for intent pairs that satisfy mutual constraint intersections. A valid match must satisfy the following at minimum:

  • Opposing directions (long vs short)

  • Compatible notional ranges within tolerances

  • Compatible expiry windows

  • Matched slippage delta within bounds

  • Non-conflicting nullifiers

When two intents meet all conditions, they are matched privately via an MPC handshake and embedded into a match commitment hash.

Matching Circuit Constraint Example:

assert(slippageA + slippageB >= abs(priceA - priceB))
assert(intentA.side != intentB.side)
assert(intentA.expiry >= current_block)
assert(intentB.expiry >= current_block)

The matched pair is then inserted into a batch ledger, with each batch composed of up to N matches per epoch.

A MatchProof.circom circuit generates a zkSNARK that validates:

  • Intent hashes are well-formed

  • Inputs are ordered by expiry

  • Output commitment hash corresponds to inputs

  • Matching criteria were satisfied within the constraint system

The output is a single SNARK commitment that encodes every matched pair for that epoch.

4. Settlement Phase: On-Chain Proof Verification

The MatchProof is now ready for submission to the SnarkSide Settlement Contract, which performs the following atomic operations:

  1. Validates SNARK proof using verifier.sol

  2. Updates Merkle root of matched commitments

  3. Processes all margin inputs by verifying separate VaultProofs for each user

  4. Nullifies prior intents to prevent resubmission or replay

  5. Inserts encrypted position state into the CipherVault Merkle tree

At no point is the notional size, leverage, or direction of the trade revealed. The only observable artifact is:

  • matchRoot: global Merkle commitment of all intent matches in the epoch

  • vaultRoot: global Merkle commitment of updated vault state

No TradeExecuted, OrderFilled, or PositionOpened event is emitted. There is no event to front-run, no log to parse, no state to simulate.

5. Vault Phase: CipherVault State Finalization

The final step is insertion of the user’s position into the CipherVault, a zero-knowledge vault architecture based on UTXO commitments. Each position exists as a leaf in a Merkle tree, defined by:

{
  "owner": "stealth_pubkey",
  "position_hash": "Poseidon(entry_price, direction, leverage, salt)",
  "notional_commitment": "...",
  "nullifier": "...",
  "expiry_block": 1820000
}

This data is not stored directly. Only the root of the tree is ever exposed on-chain. Every update modifies the tree root, allowing users to independently track their UTXO existence and validity.

To close a position, the user presents:

  • Merkle path to their leaf

  • Proof of ownership (stealth key match)

  • ZK proof of close condition (e.g. profit exit or expiry met)

At all times, position ownership remains unlinkable, unreadable, and untraceable.

Summary

The SnarkSide execution pipeline is a formal cryptographic proof system, not a transaction log model. It fully redefines what it means to "trade" on-chain:

  • No mempool interaction

  • No public calldata exposure

  • No signature-linked operations

  • No transaction receipts revealing size, direction, or result

The chain simply verifies proofs. The market exists entirely as a cryptographically valid shadow state, observable only by those who created it, provable to those who need to trust it, and opaque to all others.

In the next section, we will explore the structure, constraints, and commitment logic of a SnarkSide Encrypted Intent, the first object in this pipeline.

PreviousSystem DesignNextComparison with Traditional DEXs

Last updated