zPerps

Private perpetuals,
explained.

How zPerps keeps collateral, positions and liquidations invisible while settling at exchange speed.

01

Overview

A perpetual futures protocol where the account layer is private by construction.

Collateral is held as Zcash Orchard notes. Positions are Pedersen commitments. Matching and settlement run on Solana. The protocol never learns a trader's balance, position size, entry price or liquidation level, it only verifies zero-knowledge proofs that each action is solvent.

0
Visible positions
None
Trusted setup
400ms
Settlement
Public order flow is a liability. On every other perp DEX, liquidation levels are clustered by bots, entries are copied, and flow is sold. zPerps removes the data instead of hiding it behind a UI.
02

Architecture

Three layers: a shielded vault, client-side proofs, and a public matcher that only sees aggregates.

Zcash · Orchardshielded notesOrchard vaultthreshold keyTraderHalo 2 · client proofsSolana programmatch · settle · verifyshield / unshieldnote commitmentsproofs + commitmentsfills · fundingpublic state: aggregated OI only
Orchard vault
Zcash

A shielded address controlled by a threshold key. Deposits create notes the vault can spend only with a valid proof, and can never attribute to a trader.

Halo 2 circuits
Client

No trusted setup. Three circuits, open, close and liquidate, each proving solvency without revealing amounts.

Solana program
Settlement

Verifies proofs, maintains the commitment tree and nullifier set, and runs price-time matching over blinded orders.

03

Positions & commitments

Every position looks identical on-chain.

circuit.open
C = Com(market, side, size, entry, lev, r)
open(note, C, π):
  assert note ∈ OrchardTree          // membership
  assert nullifier(note) ∉ Spent     // unspent
  assert note.value ≥ size / lev + fee
  publish C, nullifier               // never size, side, entry

The program stores the commitment C and a nullifier derived from the funding note. Because all commitments look identical, an observer sees only the number of open positions per market and total open interest, never their distribution.

04

Liquidations

A liquidator proves a position is underwater without learning whose it is.

Long
liq = entry × (1 − 1/lev + mm)
Short
liq = entry × (1 + 1/lev − mm)

Maintenance margin mm = 0.5% is committed at open. Anyone holding a trader's outsourced viewing key, typically their own keeper, can generate a liquidate proof once the oracle price crosses the level. The proof reveals which commitment was closed, but not its size, side or owner.

  1. 01
    Oracle tick
    Index crosses the committed level.
  2. 02
    Proof
    Keeper builds a liquidate proof against the commitment.
  3. 03
    Settle
    Program burns the note; 40% of mm to liquidator, 60% to insurance.
05

Oracle & funding

Median of aggregated spot venues, published every 400ms.

Funding is paid every 8 hours between longs and shorts, based on the premium of the mark over the index and clamped to ±0.75%. Transfers are batched into a single Orchard transaction with per-position amounts encrypted to each owner's key.

400ms
Index cadence
8h
Funding interval
±0.75%
Funding clamp
06

Markets

Four perpetuals at launch, ZEC-collateralised.

MarketMax leverageMaint. marginTakerMaker
ZEC-PERP20×0.5%0.05%0.01%
SOL-PERP50×0.5%0.05%0.01%
BTC-PERP100×0.5%0.05%0.01%
ETH-PERP100×0.5%0.05%0.01%
07

FAQ

Can the team see my positions?+

No. The vault key can spend notes only with a valid proof, and proofs do not reveal amounts.

What if I lose my viewing key?+

Your positions cannot be closed by anyone, including us. Back it up.

Why Zcash and not a mixer?+

Orchard is a production shielded pool with native encrypted value, Halo 2 proofs and no trusted setup. A mixer only breaks address links; it does not hide amounts inside an active position.

Why Solana for settlement?+

400ms slots and cheap proof verification. Zcash is the vault, not the matching engine.