Merkle Tree Integration
Merkle Tree Integration
Verifying Proofs Without Leaking Vault Index
The design of SnarkSide’s vault and intent systems prioritizes cryptographic verification over traditional index-based state access. In particular, the integration of Merkle trees into the vault architecture enables the protocol to confirm the inclusion of a vault or position without ever revealing its precise index or ownership linkage. This provides the same assurance as an account-based system — verifiable state commitment — while removing the attack surfaces tied to position visibility, ordering, or reuse.
This section details how Merkle trees are used in SnarkSide to structure encrypted vault commitments, how inclusion is proven under zero knowledge, and how index obfuscation is achieved via selective path disclosure and hashing.
Motivation for Merkle Commitment Structures
SnarkSide operates in an environment where:
Vault commitments are private.
Nullifiers must be enforced.
Matching, funding, and liquidation must be provably correct.
No centralized sequencer or state exposure is allowed.
To achieve this, we need a verifiable but non-indexed data structure that supports:
Proofs of inclusion (vault exists in the system)
Proofs of non-reuse (nullifier not spent)
Efficient public verifiability without exposing vault ownership
Merkle trees are the canonical solution for this.
Tree Construction
SnarkSide maintains a Poseidon-based Merkle tree of vault commitments:
Fixed-depth (e.g., 2^20 leaves for scalability)
Zero-filled when empty
Root updated via off-chain relayers and on-chain batching
Each vault_commitment (a Poseidon hash of position data, margin, salt, and nullifier) is inserted as a leaf:
leaf = Poseidon(margin_amount, expiry, salt, nullifier)The resulting tree is committed to in the smart contract as vaultRoot.
Zero-Knowledge Inclusion Proofs
To prove a vault exists in the tree without revealing which one:
The user generates a standard Merkle path to their vault leaf.
This path is encoded into a zkSNARK circuit using
MerkleInclusionProof.The proof only outputs a boolean: “this commitment exists in this root.”
The zk circuit schema:
component proof = MerkleInclusionProof(depth);
proof.leaf <== vault_commitment;
proof.root <== public_vault_root;
proof.pathElements <== [hash1, hash2, ..., hashN];
proof.pathIndexBits <== [bit1, bit2, ..., bitN];
assert(proof.output == 1);This guarantees:
The vault is part of the committed global state.
The actual path index (location in tree) is never revealed.
Multiple users can prove inclusion without overlap or leakage.
Obfuscating Path Index
To prevent even statistical inference based on which paths are revealed:
Paths are randomized by inserting at pseudo-random locations using a client-controlled salt and PRNG seeded by stealth key.
When generating Merkle paths, users may pad with dummy branches to normalize path structure.
Circuit is constructed to ignore unused branches, and tree updates are batched.
This prevents timing analysis or path-pattern matching from revealing anything about user positioning.
Tree Update Protocol
Vault updates follow a structured process:
Old commitment is marked as spent via nullifier.
New commitment is inserted into the tree.
A new root is generated and published via batch posting.
Inclusion proofs in future circuits reference only this updated root.
The old commitment index is not reused, and the transition is cryptographically bound — but invisible.
Applications of Merkle Inclusion
Merkle inclusion proofs are used across the SnarkSide stack:
Vault Funding
Verify user has deposited capital
Position Creation
Prove margin availability
Liquidation
Prove position existed and was overexposed
Nullifier Burn
Enforce one-time state transition
Withdrawal Intent
Prove vault exists and is redeemable
All of these are executed without revealing which vault belongs to whom — or where in the tree it resides.
Summary
SnarkSide uses Merkle tree integration with zero-knowledge proofs to validate state transitions while maintaining complete index obfuscation. This allows:
Trustless proof of vault existence and validity
No leakage of account or position metadata
Public verifiability with no address or location exposure
In short, vault Merkle roots serve as the only public state anchor, while everything else remains private, untraceable, and provably correct. This is foundational to SnarkSide’s vision: a state machine where computation is public, but data is not.
Last updated