ZKPerp 1/4: perpetual futures waar niemand je positie kan zien
Deel 1 van een vierdelige serie. Een privacy-first perpetuals-DEX op Aleo — wat het is, wat werkt en wat niet.
ZKPerp won in vier buildathon-rondes een prijs en draait vandaag op Aleo-testnet. Dit is het overzicht; de rest van de serie gaat dieper.
Elke perpetual-DEX die op een transparante chain draait, publiceert je volledige handelsleven. Positie-openingen, sluitingen, liquidaties, LP-stortingen — weggeschreven naar publieke opslag en binnen enkele seconden na settlement geïndexeerd door een tiental dataproviders.
Dit wordt doorgaans onder "transparantie" geschaard. Het is accurater om het een structureel aanvalsoppervlak te noemen, want er volgen drie concrete dingen uit:
Front-running. Een whale opent een grote long. Bots zien de pending transactie, kopen ervoor, verkopen er direct na en steken de prijsimpact in eigen zak — ten koste van de whale.
Liquidation hunting. De liquidatieprijs van elke open positie is te berekenen uit publieke data — entry, collateral en size staan allemaal on-chain. Gecoördineerde traders duwen de prijs richting bekende liquidatieclusters om cascades te triggeren.
Strategieën kopiëren. Elke trade van een vaardige trader is zichtbaar op het moment dat hij settelt. Concurrenten kopiëren in realtime. Een instelling kan geen betekenisvolle omvang verhandelen zonder haar these aan de hele markt te verklappen.
Dit zijn geen randgevallen. Het is een beschrijving van waarom professionele flow grotendeels niet naar on-chain perp-venues gaat, en geen enkele MEV-mitigatie op sequencer-niveau pakt de kern aan: de posities zelf zijn leesbaar.
De aanpak
ZKPerp is natively gebouwd op Aleo, een Layer-1 die vanaf de grond rond zero-knowledge proofs is ontworpen. Dat is van belang omdat Aleo's programmeermodel twee soorten state onderscheidt:
- Publieke mappings — leesbaar voor iedereen, opgeslagen on-chain
- Private records — UTXO-achtige versleutelde objecten, alleen leesbaar met de viewing key van de eigenaar
ZKPerp bewaart alle positiedata in private records. Size, entry price, collateral, leverage, richting, PnL en liquidatieniveau zijn standaard versleuteld — niet als opt-in-modus, maar als de enige modus.
Wat dit meer maakt dan versleutelde opslag is het volgende: een Aleo-transition kan verifiëren dat een berekening correct is — dat een positie is geopend tegen een geldige prijs met geldige collateral, met een geldige PnL als resultaat — volledig via een ZK-proof, zonder dat het contract ooit de waarden leert. De verifier leert dat de berekening klopte, niet waarover hij rekende.
Dit is geen privacylaag over een transparant systeem. Het is geschreven in Leo, Aleo's eigen taal, en de privacy is een eigenschap van het uitvoeringsmodel in plaats van een functie die er bovenop is gelegd.
Wat publiek is, en waarom
Hier specifiek over zijn is nuttiger dan beweren dat alles verborgen is.
- Oracle-prijzen. Nodig voor correcte settlement. Onvermijdelijk publiek.
- Pool-aggregaten. Totale liquiditeit, geaggregeerde long- en short-open interest.
- Commitment-hashes.
position_commits[id]is een BHP256-hash. Hij onthult niets over de parameters van de positie, maar zijn bestaan is zichtbaar. - Transactieaantallen. Hoeveel posities per block worden geopend of gesloten — niet de inhoud ervan.
Al het andere — size, entry, collateral, leverage, richting, PnL, liquidatieniveau — is versleuteld in records die alleen de trader kan ontsleutelen.
Wat live is
Perpetual-markten — BTC, ETH, SOL. Elk is een apart programma met een eigen LP-pool en slot-records. Tot 20× leverage, 0,10% openingsfee, 5% maintenance margin, gesetteld in USDCx (de officiële Aleo-testnet-stablecoin) via echte private token-transfers.
Positie-commitment-schema. Bij openen worden alle gevoelige parameters gehasht tot één on-chain field-element. Elk beëindigingspad — close, take-profit, stop-loss, liquidatie — herberekent die hash uit de aangeleverde inputs en dwingt gelijkheid af vóór er wordt uitbetaald. Geen enkele partij kan een positie beëindigen met andere parameters dan bij het openen zijn vastgelegd. Een trader kan geen uitbetaling opblazen; een keeper kan geen beloning opblazen of op de verkeerde size liquideren.
Keeper-auth-liquidatie. Bij het openen van een positie worden atomair authorisatie-records aan een keeper-set gemint, zodat liquidatie werkt zonder dat de trader online is en zonder dat iemand de positie van de trader leest. Elke afzonderlijke keeper kan handelen; ze racen om een deterministische beloning in plaats van samen te spannen. Correctheid wordt on-chain afgedwongen door vijf finalize-gates, ongeacht welke keeper indient.
On-chain 2-of-3 oracle-quorum. Drie onafhankelijke relayers lezen Chainlink-feeds en dienen in onder hun eigen Aleo-keys. Het quorum wordt afgedwongen door het Leo-contract zelf — er is geen off-chain coördinator. Prijzen ouder dan 150 blocks (ongeveer vijf minuten) worden door elk prijslezend pad afgewezen.
Circuit-level KYC. Een BHP256 Merkle-allowlist van diepte 10. Alleen de root wordt on-chain gepubliceerd; adressen nooit. Gebruikers bewijzen lidmaatschap één keer en houden een privé compliance-record dat tot 180 dagen geldig is. Revocatie is onmiddellijk via een on-chain boolean, zonder de boom te herbouwen. De off-chain allowlist koppelt wallet aan identiteit onder gerechtelijk bevel — waardoor audit en sanctiescreening mogelijk zijn zonder iemands identiteit te publiceren.
ZK dark pool. Sealed-bid batch-veilingen die settelen tegen een uniforme clearingprijs. Geen enkele order is publiek vóór of na settlement, en dat is precies de eigenschap die front-running werkelijk nodig heeft. Live op testnet met bevestigde on-chain settlements.
Geavanceerde ordertypes. Limit orders, take-profit en stop-loss — uitgevoerd door keepers, met triggercondities die worden geverifieerd tegen de live on-chain oracle in plaats van een door de keeper aangeleverde prijs. Het enige on-chain spoor van een pending order is een boolean met een commitment-hash als sleutel.
Cross-chain collateral. USDCx gebridged vanaf Ethereum via Circle's bridge. Live test: ~81 USDC in minder dan 15 minuten.
Wat niet
Ik hoor dit liever van mij dan van een audit. Elk hiervan krijgt later in de serie een volledige post; hier de korte versie.
De concentrated-liquidity-AMM is een prototype. Een Uniswap v3-achtige USDCx/ALEO-spotvenue, onderhouden als losstaand subproject — niet de liquiditeitsmotor van de perps. Hij verifieert elke swap tegen de curve, maar de bedragberekeningen draaien in inline u128, wat de aantoonbaar veilige marge begrenst. Hij is niet on-chain gevalideerd of geaudit. Onderzoeksprototype, geen bruikbare venue.
Pool-state-aggregatie is trusted. Omdat positie-sizes private witnesses zijn, kan open interest niet on-chain worden afgeleid zonder de sizes te publiceren. Een off-chain orchestrator berekent en schrijft de aggregaten, en zijn huidige schrijfoppervlak is breder dan nodig. Wat hij niet kan, is de uitbetaling van welke trader dan ook opblazen of meer bewegen dan het echte token-saldo van de pool — maar de volledige grens verdient meer dan een bullet point, en die krijgt hij in deel 3.
De liquidator-set is permissioned. Non-custodial en gebonden aan regels — keepers kunnen geen prijzen zetten, geen posities verzinnen of een solvente positie aanraken — maar decentraal is het niet. Permissionless liquidatie onder privacy is een open onderzoeksprobleem, geen roadmap-item, om redenen die ik volgende week uiteenzet.
Geen funding rate, geen partial close. Voorlopig een vlak borrow-model; posities sluiten volledig.
Niet geaudit. Alleen testnet. Niet voor echt geld.
Waar het heen gaat
Op korte termijn: multi-orchestrator-rotatie, hardening van de pool-state-writes, een gedeelde core-library zodat per-markt-contracten dunne wrappers worden, en AMM-hardening richting devnet-validatie.
Verder weg: dynamische funding rates, partial close, verifieerbare performance-proofs die copy trading mogelijk maken zonder trades te onthullen, en een ZK-orderbook gebouwd op de primitives van de dark pool.
Vóór welke mainnet-deployment dan ook: formele verificatie van de circuit-soundness en de in-circuit/finalize-grenzen, een externe ZK-audit en een bug bounty. Mainnet zelf is afhankelijk van audit-goedkeuring en, realistisch gezien, van een gelicentieerde operator-partner — perpetual futures zijn MiFID II-instrumenten in de EU, een vergunning die een individuele ontwikkelaar niet bezit en niet binnen een projecttijdlijn kan verkrijgen.
Die beperking heeft de architectuur gevormd in plaats van er achteraf uit voort te komen. De compliancelaag bestaat omdat een systeem als dit alleen via een gereguleerde venue echte gebruikers bereikt, en het hoort daar vanaf het begin op gebouwd te zijn. Deel 4 gaat over wat dat in de praktijk werkelijk betekent.
Deze serie
Vier posts, één per week. Het overzicht is de makkelijke; de rest gaat over de delen die zich verzetten.
- Wat ZKPerp is — deze post
- Hoe liquideer je een positie die je niet kunt zien? — het lastigste probleem in private perps, en het patroon dat het oploste
- Wat zero-knowledge niet kan — elke trust-aanname in het systeem, benoemd en begrensd
- Vier buildathons en een regelgevingsmuur — wat brak, wat ik verkeerd deed, en waarom ik dit niet zelf kan draaien
Technische whitepaper: ZKPerp-whitepaper (PDF). Contracten en broncode: github.com/hwdeboer1977/ZKPerp. Netwerk: Aleo-testnet. MIT-gelicentieerd.
Werk je aan privacy-behoudende markten, ZK-uitvoeringsmodellen, of exploiteer je een gelicentieerde venue en klinkt de zin "settlement-laag waar order flow niet zichtbaar is voor de markt" als een product in plaats van een slogan — dan hoor ik graag van je.