Architecture

DarkMatch Engine: Architecture

The DarkMatch Engine is the off-chain computation layer responsible for aggregating, matching, and proving compatibility between encrypted trade intents in SnarkSide. Unlike traditional DEX match engines that rely on transparent orderbooks and stateful matching logic, DarkMatch operates entirely off-chain, in a zero-trust, non-observable environment. It provides privacy-preserving counterpart resolution using a distributed relayer network that performs constraint resolution, not visibility-based matching.

This page outlines the architecture of the DarkMatch Engine, including its off-chain intent aggregation system and the MPC (Multi-Party Computation) handshake model used to match encrypted intents without disclosing their parameters or origin.

Design Objective

SnarkSide’s goal is to enable anonymous, encrypted trading at scale. The central challenge in this architecture is how to find counterparties for trade intents that:

  • Do not reveal size, direction, or price

  • Are unlinkable to wallet addresses

  • Cannot be ordered or compared via on-chain state

The DarkMatch Engine solves this by shifting market coordination to a multi-relayer environment where matching happens via cryptographic constraint satisfaction, not reactive sequencing.

Off-Chain Intent Aggregation

Trade intents in SnarkSide are not posted on-chain. Instead, they are submitted to a distributed mesh of DarkMatch relayers that form the outer layer of the protocol’s privacy-preserving coordination stack.

Properties of the Intent Pool

Each relayer maintains a local intent pool, composed of:

  • intent_commitment (Poseidon hash)

  • proof.wtns (private witness data)

  • expiry (block number validity limit)

  • nullifier (used at settlement to prevent replay)

  • submission timestamp (optional, local-only)

  • ephemeral submission token (for coordination only)

Relayers do not have access to:

  • Wallet addresses

  • Actual notional sizes

  • Slippage tolerances

  • Price targets

  • Margin data

This is made possible because all trade constraints are verified inside the ZK proof submitted alongside the commitment.

Each intent is just a point in cryptographic space: verifiable, unlinked, and constrained.

Relayers accept intents by verifying the SNARK proof associated with the commitment. If the proof is valid, the intent is cached and indexed. No state mutation occurs. The intent can expire without ever being used or revealed.

Aggregation Protocol

Relayers gossip new intents across the mesh via encrypted channels (e.g. libp2p noise sessions, WebSocket tunnels, or custom QUIC implementations). Each relayer:

  • Locally verifies proof correctness

  • Stores the intent commitment in an in-memory ledger

  • Periodically rebroadcasts unexpired, unmatched intents

Intent lifetimes are short — measured in epochs (e.g. ~30s–60s) — after which they are purged unless matched. This ensures state liveness and resistance to latency-based attacks.

MPC Handshake Layer

The heart of DarkMatch is the MPC handshake protocol, a pairwise computation model for matching two encrypted intents using constraint resolution, without either party learning the other's parameters.

Problem Statement

Given two encrypted trade intents A and B, neither of which reveal:

  • Direction

  • Notional size

  • Slippage

  • Leverage

Determine whether:

  • A.side is opposite of B.side

  • A.slippage is compatible with B.slippage

  • A.size ≈ B.size ± ε

  • A.expiry ≥ current_block, B.expiry ≥ current_block

  • A and B have valid margin commitments

This must be done without revealing the values, while still generating a proof that the match was valid under protocol rules.

Secure MPC Model

Each relayer is equipped with an MPC client that executes a pairwise match evaluation using preprocessed encrypted inputs. The handshake flow looks like this:

  1. Relayer R1 receives new intent A.

  2. Relayer R2 has cached intent B.

  3. R1 and R2 initiate an MPC session over a secure channel.

  4. Each relayer inputs their side of the match (A or B) into a shared circuit.

  5. The joint circuit computes a boolean match_valid output:

    • Enforces direction symmetry

    • Computes relative notional bounds

    • Checks expiry bounds

    • Verifies joint slippage window

  6. If match_valid == true, the MPC circuit emits:

    • Combined match_commitment = Poseidon(intentA, intentB, epoch_salt)

    • ZK witness tuples for on-chain proof

The relayers discard input data and only retain:

  • Final commitment hash

  • Epoch ID

  • Proof data

MPC Circuit Design (Constraint Sketch)

template MatchCheck() {
    signal input sideA;
    signal input sideB;
    signal input notionalA;
    signal input notionalB;
    signal input slippageA;
    signal input slippageB;
    signal input expiryA;
    signal input expiryB;
    signal output match_valid;

    signal direction_ok;
    direction_ok <== sideA * (1 - sideB) + (1 - sideA) * sideB;

    signal size_diff;
    size_diff <== abs(notionalA - notionalB);

    signal slippage_overlap;
    slippage_overlap <== (slippageA + slippageB >= size_diff);

    signal expiry_ok;
    expiry_ok <== min(expiryA, expiryB) >= current_block;

    match_valid <== direction_ok * slippage_overlap * expiry_ok;
}

This match constraint is executed privately. No party knows the other’s input. All match results are posted publicly only as hash commitments.

Proof Construction

Once a match is validated by the MPC layer, the relayers jointly construct a match proof using the following data:

  • intent_commitment_A

  • intent_commitment_B

  • match_epoch

  • salt

  • Final match_commitment = Poseidon(A, B, salt)

A MatchProof.circom circuit is used to:

  • Reconstruct and validate the match commitment

  • Enforce symmetric binding of A/B

  • Output a Groth16-compatible SNARK

This proof is submitted during settlement on-chain, where it is verified by the global MatchVerifier.sol.

Summary

The DarkMatch Engine performs a role typically reserved for public, centralized matching systems — but it does so:

  • Without an orderbook

  • Without public orderflow

  • Without address-based identity

  • Without mempool visibility

It is a private, distributed, cryptographically verifiable coordination layer, capable of aggregating encrypted trade intents from anonymous actors and producing valid settlement proofs without compromising directional signal, position size, or trader identity.

DarkMatch is not merely a matching engine. It is the execution surface for a decentralized, proof-based derivatives system, and it forms the backbone of SnarkSide’s architecture.

PreviousReplay ProtectionNextRelayer Engine

Last updated