Vault State Transition Logic
Vault State Transition Logic
Deposit → Position → Update → Settle → Close
The Vault State Transition Logic in SnarkSide defines the lifecycle of a trader's capital in a fully shielded, cryptographically enforced perpetual futures environment. Unlike account-based protocols that mutate balances directly on-chain with transparent events, SnarkSide models vault state as a series of commitment transitions, each validated through zero-knowledge proofs, and linked via one-time-use nullifiers.
Each vault represents a snapshot of encrypted margin state, tied to a specific trading action. As the user deposits, opens positions, adjusts leverage, or exits, they move through a deterministic transition pipeline that preserves privacy, ensures solvency, and eliminates leakage.
1. Deposit → Vault Initialization
The lifecycle begins with a private margin deposit. Rather than crediting a wallet with funds, SnarkSide users generate a vault commitment:
vault_commitment = Poseidon(
margin_amount,
expiry,
vault_salt,
nullifier_owner
)The corresponding zkSNARK proves:
The user owns the deposited funds.
The deposit amount equals
margin_amount.The vault is bound to a one-time-use nullifier.
No prior vault state is reused.
On-chain effects:
The
vault_commitmentis stored in a Merkle tree.The
nullifier_owneris not revealed.No address or token balance changes are visible.
2. Vault → Position Creation
When a user matches a trade intent, they construct a new position commitment using encrypted values:
position_commitment = Poseidon(
entry_price,
direction,
leverage,
margin_amount,
expiry_slot,
salt,
nullifier_owner
)The vault_commitment is consumed via a SNARK, which:
Proves knowledge of the vault preimage.
Proves sufficient margin exists to collateralize the position.
Burns the nullifier associated with the vault.
Creates a new vault with embedded position state.
The old vault commitment is marked as spent via its nullifier. The new position-bearing vault commitment is inserted into the vault tree.
The chain sees only:
A valid transition.
A new hash.
A burned nullifier.
3. Position → Update
Once a position is open, a user may:
Extend or reduce notional size.
Change leverage (subject to constraints).
Update funding payment deltas.
Realize partial PnL.
Each such update is modeled as a new transition:
position_commitment_new = Poseidon(updated_fields)A zero-knowledge proof demonstrates:
Knowledge of the previous position’s data.
Validity of the update (e.g. new LTV within range).
Net solvency maintained.
Correct adjustment of any internal funding rates or deltas.
Nullifier of old state not reused.
Again, no on-chain addresses or balances are touched. The SNARK output is the new vault root and proof of validity.
4. Position → Settlement
Settlements occur either:
Upon user-triggered closure.
Upon expiry (if the intent specified).
Via liquidator challenge.
The settlement SNARK proves:
The position commitment existed and is unspent.
The position has reached expiry or matched market exit criteria.
Margin and PnL are reconciled correctly.
New commitments (e.g. released funds, fees) are valid.
This allows:
Safe withdrawal of margin.
Recomposition of funds into a new vault or L2 withdrawal intent.
Update of the vault Merkle root.
No price, position size, or wallet identity is disclosed.
5. Vault → Close
Closing a vault (with or without an open position) is the act of:
Fully consuming the vault commitment.
Burning its nullifier.
Generating a spend proof.
Optionally initiating withdrawal routing (e.g. to L1 or other shielded account).
Withdrawals are batched and delay-released to obscure timing, unless user requests immediate release via an auxiliary relay circuit with dynamic fee adjustment.
The vault closure SNARK enforces:
Non-replay.
Valid ownership.
Optional balance commitment proof.
Summary: State Transition Diagram
[Deposit]
↓
[vault_commitment_0]
↓ Match ZK
[position_commitment_1]
↓ Update ZK
[position_commitment_2]
↓ Settle ZK
[vault_commitment_3]
↓ Withdraw ZK
[Exit]Each step is an opaque cryptographic transition, unlinkable to users or prior state, yet fully verifiable by any third-party verifier using the chain’s vault Merkle root and nullifier registry.
In short, Vault State Transitions in SnarkSide model financial activity as private proofs of constraint-satisfaction, not as observable state changes — enforcing capital correctness without surveillance.
Last updated