Third-Party Liquidators
Third-Party Liquidators
Anonymous Liquidation Triggers • Reward Claims Without Trace
The liquidation architecture of SnarkSide departs radically from traditional on-chain enforcement models. In existing perpetual DEXs, liquidations are triggered through transparent surveillance of user positions, followed by deterministic, traceable liquidation transactions — often executed by bots that front-run or race to extract profits from failing accounts.
SnarkSide inverts this model: any third party may submit a zero-knowledge proof that a vault is insolvent, without knowing who owns the vault, what it contains, or even where it lives in the Merkle tree. In return, they receive a cryptographically verifiable reward, disbursed without ever linking their wallet or address to the liquidation event.
This section outlines how SnarkSide enables anonymous liquidation triggers, how it guards the liquidation game from abuse, and how third parties can claim incentives without revealing themselves — preserving privacy even for those who enforce it.
The Role of Third-Party Liquidators
Third-party liquidators serve a crucial role:
Monitoring market conditions
Scanning vault trees (public roots) and oracle price feeds
Constructing liquidation proofs under zk constraints
Posting proofs on-chain to remove risk from the system
Claiming rewards that are embedded in the vault transition
Unlike traditional MEV bots or liquidation daemons, these actors are not privileged by latency or address visibility — only by computational work and cryptographic capability.
Anonymous Liquidation Triggers
To perform a liquidation, a third party must construct a zkSNARK that satisfies the Liquidation Proof Circuit, which ensures:
The vault exists in the committed vault Merkle root.
The position it contains is insolvent, based on current oracle price and funding delta.
The nullifier has not been used before.
A valid new vault is created, representing the redistribution of remaining funds.
Critically, this proof:
Requires no knowledge of the vault's owner
Requires no direct transaction from the victim's wallet
Reveals nothing but the fact that the proof is sound
This makes SnarkSide the first protocol where liquidations are not acts of surveillance, but of pure cryptographic attestation.
Reward Structure
To ensure that third-party liquidators are incentivized to enforce solvency, SnarkSide includes a reward commitment model:
A portion of the liquidated margin (after penalties and protocol fees) is allocated to the prover of the liquidation proof.
This is embedded as a field in the new vault commitment created during the transition.
The reward commitment is formatted as:
liquidation_reward_commitment = Poseidon(
liquidator_reward_amount,
salt,
nullifier_liquidator
)The liquidator must generate a fresh nullifier of their own, tied to a stealth key or funding script, that entitles them to claim the reward later.
How Rewards Are Claimed
There are two primary paths:
1. Encrypted Vault Accrual (Default)
The reward is committed as a new vault leaf under the liquidator’s control. This leaf can later be proven as:
Part of the Merkle tree
Owned via a private nullifier
Spendable in a withdrawal proof or to fund further trades
This approach keeps the liquidator fully anonymous — they never send a claim transaction, only zk proofs of spend rights.
2. One-Time Public Payout (Optional)
Alternatively, liquidators may opt to:
Bind a withdrawal address in their nullifier.
Prove the reward amount and nullifier validity in a separate SNARK.
Withdraw to a public wallet or relay address.
This reduces privacy but may be preferred for centralized services or validator-operated bots.
Anti-Replay and Abuse Protections
SnarkSide includes several layers of protection:
Nullifier registry: each nullifier (for liquidated vault or reward claim) may only be used once.
Merkle root consistency: proofs must match the currently committed state tree.
Oracle timestamp matching: liquidation must use recent price, not historical or stale data.
Verifier challenge: any user may challenge a proof with a superior one, if fraud is suspected (future feature).
These mechanics ensure that the liquidation game is fair, permissionless, and abuse-resistant.
Integration with Off-Chain Liquidation Bots
While the protocol is permissionless, SnarkSide encourages the creation of off-chain scanning agents that:
Monitor oracle feeds in real time
Scan vault trees and attempt proof construction
Maintain a mempool of pending liquidation proofs
Execute successful proofs via RPC or custom relayers
These agents do not require any privileged API keys or sequencer status. All data is public, and the only competitive edge is proof efficiency, not network position.
Summary
Third-party liquidators on SnarkSide are:
Incentivized
Anonymous
Cryptographically provable
Unlinkable to the traders they liquidate
This design restores fairness to a process that in most DEXs is riddled with asymmetries and public exploitation. By embedding liquidation enforcement into the protocol’s zero-knowledge fabric, SnarkSide ensures that even enforcement is private — the final frontier of DeFi integrity.
Last updated