System Design
SnarkSide is a fully modular, cryptographically-enforced perpetual futures protocol composed of decoupled privacy-preserving subsystems, each built around a singular assumption: on-chain transparency is not a neutral substrate — it is adversarial by default. In response, every core component of SnarkSide is constructed to function under the premise of non-disclosure by design, with interoperability facilitated through verifiable constraint satisfaction rather than transaction sequencing.
This section presents a comprehensive overview of SnarkSide’s system architecture, focusing on the three principal phases of encrypted trading — trade declaration, match computation, and state settlement — and explains how each layer enforces correctness through cryptographic proofs, not public traceability.
Modular Privacy: Trade, Match, Settle
The protocol is structured into three autonomous, cryptographically-linked modules:
1. Trade: Encrypted Intent Declaration
A user wishing to interact with SnarkSide does not submit a transaction to the network. Instead, they locally construct an intent, which is a zero-knowledge commitment to a set of trade constraints. These constraints include:
Direction:
longorshortNotional size (encrypted)
Entry conditions: price or slippage bounds
Expiry window
Maximum leverage
Nullifier commitment (to prevent replay)
Position salt (to prevent correlation)
The intent is submitted to a private relayer network. It never enters a public mempool. It is not a transaction. It is a provable declaration of admissibility, independent of address or current market state. No external observer can deduce the content or ownership of the intent.
Internally, the intent is validated by a circom-based circuit which asserts the structure and internal coherence of the constraint set. The constraint output is posted to the relayer pool as a blinded object, indexed by a unique intent commitment hash.
2. Match: MPC-Based Dark Matching
Once submitted, encrypted intents enter the DarkMatch engine, an off-chain multi-party computation (MPC) relay protocol. The matching engine does not function like an orderbook. It does not require observable depth, tick prices, or trade history. It is stateless in terms of public liquidity representation.
Instead, the MPC nodes compute matches based on the intersection of constraint surfaces. An intent A and intent B are matchable if:
Their slippage tolerances overlap
Their direction vectors are opposite
Their sizes are compatible within circuit tolerance
Their expiry blocks are valid at match time
Their hashes pass a joint proof of semantic compatibility
The result is a ZK-valid match commitment: a Poseidon hash of both intent hashes, salted with a per-batch root. This match is posted to the chain only once — as a SNARK-verified settlement batch.
The off-chain match phase creates a non-enumerable, non-replayable, and non-targetable match environment. No MEV actor can observe it. No execution simulator can anticipate it. No latency game can front-run it.
3. Settle: Constraint-Proven State Transitions
The final stage of a SnarkSide trade is settlement, not execution. In traditional DEXes, trade execution is synonymous with on-chain state mutation. In SnarkSide, settlement is equivalent to constraint resolution.
Each matched trade pair generates:
A proof of valid match (from DarkMatch circuit)
A proof of valid margin coverage (from CipherVault circuit)
A nullifier update for both users
A new encrypted vault UTXO for each party
Optional funding fee commitments based on matched skew
Settlement occurs via a single smart contract verifier call, which:
Validates SNARK proofs from both circuits
Updates vault Merkle roots
Increments the global nullifier tree
Posts zero logs revealing trade size, direction, or outcome
The result is verifiable state progression without market-readable output. No DEX trace exists for the trade. No position is queryable. Yet correctness is enforced by circuit constraints and publicly verifiable proofs.
Constraint Satisfaction vs. Transaction Logs
Most DeFi systems are log-driven: every transaction generates a publicly readable series of state mutations, events, and internal storage deltas. This data is indexed, aggregated, and modeled by bots and adversarial traders in real time. From this telemetry, they reconstruct market topology and systematically extract profit from informed users.
SnarkSide replaces this log-centric model with constraint-centric computation. This philosophical divergence transforms protocol design in three critical ways:
1. Logless Proofs
Instead of logging event flows, SnarkSide asserts that a transition is valid under a constraint system:
assert(
PoseidonHash(intentA) ⊕ PoseidonHash(intentB) == match_commitment,
"Match hash mismatch"
)Only the output commitment is published, not the operands.
The log is the proof. The trace is the constraint. The chain state is bounded by what can be shown — not by what was observed.
2. Stateless Position Tracking
There is no account-based balance system. No wallet holds a position. Instead, every margin state is a shielded UTXO with no direct address binding:
{
"owner": "stealth_pubkey",
"commitment": "Poseidon(entry_price, size, expiry, leverage)",
"nullifier": "Poseidon(stealth_key, salt)"
}The vault contains no readable state. Each update occurs via a root change, not a mapping update.
3. Match Finality Without Disclosure
In an orderbook, trade finality is achieved by a publicly posted fill. In SnarkSide, finality is attained by jointly verified settlement proofs — producing state transitions that are irrefutable, yet unobservable.
This allows SnarkSide to retain all essential financial correctness properties:
Price-time fairness (enforced by MPC sequence)
Match validity (proven via ZK)
Margin sufficiency (proven via encrypted vault check)
Skew-aware funding (computed over encrypted OI sums)
…without requiring a single log line that reveals position, direction, or actor.
Implications
The system design choices outlined above make SnarkSide resistant to:
Sandwich attacks
Liquidation hunting
Replayable intent spoofing
Oracle baiting via visible skew
Cross-position correlation attacks
They also enable a fundamentally different application model — one where intent, match, and state are separated by computation boundaries, not coupled through shared transaction space.
SnarkSide’s architecture is not a variant of known DEX designs. It is a clean departure. One where visibility is replaced by validity, and state is emergent from cryptographic truth, not external consensus.
This modularity — trade, match, settle — allows each component to evolve independently, with alternative proof systems, matching engines, or vault models pluggable so long as constraints are satisfied.
It is not a marketplace. It is a proof system with economic semantics.
Proceed to the next section for a detailed breakdown of the encrypted trade intent lifecycle.
Last updated