Relayer Engine
Relayer Design
In SnarkSide’s architecture, relayers are non-trusted, off-chain nodes responsible for coordinating encrypted trade intents, performing secure multiparty constraint matching, and facilitating proof-based settlement — all without access to the underlying trade parameters or trader identity.
Unlike centralized match engines or decentralized validators, relayers do not own or execute trades, and they never see slippage, size, direction, or wallet addresses. Their role is narrow but essential: they serve as private ZK routers that connect constraint-satisfiable intents and generate zero-knowledge proofs for settlement.
This section outlines the architecture, responsibilities, and security model of SnarkSide relayers, as well as how they manage and match intent pools in a verifiably private and adversary-resistant manner.
Role of Relayers
Relayers in SnarkSide perform three essential functions:
1. Intent Reception and Verification
Relayers accept encrypted trade intents from users through a secure submission interface (e.g., HTTPS, Noise-based P2P mesh, or a wallet-integrated RPC layer). Each submission includes:
A
intent_commitment: Poseidon hash of intent fieldsA
proof.wtns: Zero-knowledge witness proving the intent's internal constraintsMetadata:
expiry,submission timestamp, and an optional user-supplied token
Before accepting any intent into the pool, the relayer:
Verifies the SNARK proof using a precompiled verification key
Confirms the intent is not expired
Ensures the nullifier does not appear in the relayer’s local nullifier cache
No wallet signature or authentication is required or stored — the ZK proof and hash are sufficient.
2. Intent Pool Management
Each relayer maintains an ephemeral, in-memory intent pool. This pool contains all valid, unmatched, unexpired intents the relayer has verified.
Key features of the intent pool:
Data stored
Intent hash, proof pointer, expiry
Lifetime
Typically 30–90 seconds (epoch-based)
Access scope
Local to relayer (no public exposure)
Ordering
Randomized or intent-score based
Match attempts
Pairwise MPC negotiation with other relayers
Deletion policy
On expiry or successful match
Intent pools are never broadcast publicly, and relayers do not sort or index intents by size, direction, or price. All matching occurs via opaque constraint validation.
3. MPC Match Negotiation
Once an intent is accepted, relayers initiate pairwise match negotiations with other relayers across the mesh. These negotiations use a minimal, constant-bandwidth MPC handshake protocol:
Two relayers (say, R₁ and R₂) exchange intent commitments and salt-based authentication tokens
They initialize a private MPC circuit to test match validity (see “DarkMatch Engine”)
If a match is found:
Both relayers jointly construct a
MatchProofThe matched intent pair is dropped from their local pool
A match commitment is generated and queued for settlement
This handshake ensures:
Each relayer only sees its own intent's private fields
No slippage, size, or wallet is leaked in transit
Only valid proofs can be emitted
MPC match outcomes are always symmetric — both relayers output the same commitment hash and SNARK proof. No unilateral settlement is possible.
How Intent Pools Are Matched
Unlike orderbooks or AMMs, SnarkSide does not perform “best price” matching. Instead, intents are matched only if their constraint sets are mutually satisfiable.
Constraint Matching Logic
An intent A matches intent B if:
They have opposite trade directions
Their notional sizes are close within tolerance
εTheir slippage windows overlap
Both are unexpired
Both provide valid ZK proofs of collateral
Their nullifiers are unique and unconsumed
This model shifts market logic from price discovery to cryptographic feasibility.
Pool Management Strategy
Relayers typically adopt one of the following matching strategies:
Greedy Matching: Attempt to match each incoming intent with the first compatible one in the pool
Epoch-Based Matching: Aggregate all intents in a time window, then perform batch matching at the end of the epoch
Intent Scoring: Use local heuristics (e.g., proof strength, margin depth) to prioritize intents for matching
Relayers are economically incentivized to match valid pairs because they receive:
Settlement fees upon proof verification
Protocol reputation or score in the P2P relayer mesh
Intent Eviction Policy
To keep pools clean and performant, relayers drop intents if:
They expire (i.e., current block >
expiry)The match proof is already finalized for the nullifier
The user resubmits a new intent (previous one is invalidated)
This ensures high churn, low latency, and resilience against denial-of-service spam or staleness.
Fault Tolerance and Security
SnarkSide assumes that not all relayers are honest, and designs its system so that:
Malicious relayers cannot forge proofs (due to SNARK verification)
Malicious relayers cannot front-run or copy user data (no observable fields)
Intent leakage is impossible without access to ZK witness data
All relayer actions are auditable by design:
Each successful match produces a public SNARK
The settlement contract logs match_commitment and nullifiers
Failed matches or replay attempts are detected at the verifier level
Summary
SnarkSide relayers are private, stateless, non-custodial computation agents that replace traditional orderbooks with ZK-driven match logic. They:
Accept encrypted trade intents and verify proofs
Maintain short-lived, private intent pools
Perform MPC-based handshake matches with other relayers
Generate valid match proofs for on-chain settlement
Never touch user assets, read private data, or execute transactions
Their design ensures high-throughput, censorship-resistant, fully-anonymous market coordination — laying the foundation for an invisible yet verifiable global derivatives exchange.
Last updated