Overview
Encrypted Trade Intents: Overview
At the core of SnarkSide's architecture is a departure from the traditional transaction-based model of on-chain interaction. Rather than viewing user activity as a series of signed state mutations submitted directly to a smart contract, SnarkSide treats every user interaction as a private declaration of capability — an assertion that the user intends to participate in the system within a defined set of cryptographic constraints.
This is the function of a trade intent. It is not a transaction. It is not an order. It is not a message to the network. It is a zero-knowledge–verifiable object that expresses a trader’s desired outcome, bounded by conditions they privately enforce and publicly prove.
This page defines what an intent is, why it is necessary in the context of adversarial markets, and how it allows SnarkSide to operate without the mempool, without leaks, and without on-chain order flow.
What Is an Intent?
An intent is a cryptographic commitment to a set of trade constraints, expressed as a proof that:
The trader has a specific directional preference (e.g. long or short)
They are willing to transact a specific size (notional value)
They are operating under a defined slippage tolerance
They have a maximum leverage threshold
Their margin is sufficient to collateralize the position
The declaration expires at a predefined block height
It is uncorrelated with past or future declarations
Every intent is constructed locally by the user using a proving system — generally a SNARK-compatible circuit executed in-browser or inside a dedicated zkWallet client. The output is a succinct proof and a commitment hash, both of which are submitted to a private relayer network. These components are sufficient to verify the intent without disclosing its contents or origin.
An intent is therefore both non-executable and non-informational. It does not mutate state and does not inform external actors of the user’s direction, size, or preferences. It is provable participation without disclosure.
This design removes the need for a mempool, eliminates front-running vectors, and severs the link between wallet identity and trade behavior.
ZK-Bound vs Transaction-Based Interaction
The standard model of on-chain interaction looks like this:
User signs a transaction (e.g. a swap, a perp order)
Transaction is broadcast to the mempool
Validators select and reorder transactions
The transaction executes, mutating state and emitting logs
This flow exposes everything: who signed the transaction, what it does, the size of the operation, the slippage tolerance, the destination, and the associated execution risk. Even before confirmation, a transaction is a source of extractable signal. The mempool is not a network component — it is a threat surface.
SnarkSide removes this interaction model entirely. The alternative looks like this:
User locally defines a set of trade constraints
User proves that these constraints are internally consistent
A blinded commitment to these constraints is submitted off-chain
Matching and settlement occur if a compatible counterparty is found
The result is posted on-chain as a proof of match and proof of margin validity
At no point does the user submit a transaction or reveal trade parameters. There is no mempool, no signature trace, no visible state change that can be attributed to the user until the final match is settled. Even then, the position is inserted into a vault as a cryptographic leaf, not as a wallet-bound balance.
The key distinction is this:
In transaction-based systems, participation is observable. In SnarkSide, participation is provable.
This eliminates not just MEV, but a deeper category of market manipulation: strategic state anticipation. Because intents are not correlated to address, timestamp, or order size, it becomes impossible for observers to reconstruct market state from user behavior. And because matching is performed off-chain, there is no deterministic sequence of interactions that could be exploited by latency-sensitive actors.
Intent as a Constraint Object
Every intent is a proof of eligibility, not of execution. It says:
“I can enter a long position up to X size”
“I am collateralized up to Y leverage”
“I will accept a price within Z tolerance”
“I am valid until block N”
But it does not say:
“Here is my wallet”
“Here is my slippage setting”
“Here is the exact notional I’m trying to fill”
This difference is not semantic — it is architectural. The proof asserts that the user has the right to act, under their own constraints, and that any valid match produced from this proof will not break protocol invariants.
In this model, intent becomes the API boundary between the trader and the market. It is not a call to mutate state — it is an encrypted statement that can be resolved only by finding a counterpart constraint that proves compatible.
Matching two intents becomes an act of mutual constraint resolution — and nothing more.
Statelessness by Default
Because intents are not transactions and do not mutate state, they can be submitted in parallel, withdrawn silently, or allowed to expire without ever interacting with a smart contract. The system is designed so that no intent exists on-chain unless it is part of a finalized match proof.
This means:
No footprint for expired or unfilled intents
No address-level order history
No matching pressure from resting orders
No visible unfilled size for adversarial analysis
It also means the protocol can handle a far greater volume of off-chain activity than any traditional contract-bound matching engine. The relayer network is limited only by compute and bandwidth — not by gas, block space, or calldata constraints.
Intent-based interaction enables a trading architecture where intentions are bounded by mathematics, not by trust or exposure. In SnarkSide, encrypted trade intents are not just safer — they are fundamentally more composable, more expressive, and more difficult to game than any observable transaction model. They form the foundation of a market that cannot be front-run, cannot be simulated, and cannot be selectively surveilled.
Last updated