Hyperliquid testet HIP-3-Wallet-Allowlists für Builder-Perps

Hyperliquid testet HIP-3*, eine optionale Erweiterung seines von Buildern betriebenen Perpetuals-Frameworks, mit der einzelne Marktbetreiber den Zugang zu ihren eigenen Handelsplätzen über Wallet-Allowlists beschränken können. Die Funktion wurde in einem Entwickler-Update vom 3. September im Kanal Hyperliquid API Announcements vorgestellt und ist derzeit nur im Testnet verfügbar. Ein Mainnet-Termin wurde nicht angekündigt. Ein HIP-3*-Deployer kann im Namen eines Nutzers in fünf klar begrenzten Fällen handeln: eine Allowlist-Freigabe erteilen oder entziehen, bestimmte offene Orders stornieren, offene Orders und TWAPs auf dem Handelsplatz gesammelt stornieren, reduce-only-Orders platzieren und Collateral auf ein anderes Konto desselben Handelsplatzes übertragen. Über einen Proxy ausgeführte Orders müssen reduce-only sein. Ein Betreiber kann eine Position über die Proxy-Funktion daher verkleinern, aber nicht vergrößern.

Warum das wichtig ist

HIP-3* ist das erste von Hyperliquid für sein Builder-Deployer-Modell veröffentlichte Werkzeug zur Zugriffskontrolle. Die Einordnung ist ebenso wichtig wie die Funktion selbst. Betreiber eines HIP-3-Marktes tragen bereits die wirtschaftliche und operative Last: Sie definieren Kontrakte, pflegen Oracles, legen Hebelgrenzen fest, wickeln Märkte ab und müssen 500.000 HYPE staken. Validatoren können diesen Stake wegen irregulärer Eingaben slashen, die Korrektheit, Verfügbarkeit oder Leistung des Protokolls gefährden. HIP-3* ergänzt dieses Betreibermodell um eine Wallet-basierte Zugangskontrolle, ohne die Verantwortung für den Handelsplatz auf das Kernprotokoll zu verlagern oder KYC im übrigen Netzwerk zu erzwingen. Nach eigener Aussage will Hyperliquid unabhängigen Betreibern helfen, die für sie geltenden Anforderungen zu erfüllen, und nicht selbst als Compliance-Schicht fungieren.

Diese Trennung macht die Funktion für institutionelle Gegenparteien nachvollziehbar. Ein Unternehmen mit Anforderungen für das Kunden-Onboarding, dem Ausschluss sanktionierter Jurisdiktionen oder Beschränkungen bei Partnerströmen verfügt nun über ein Onchain-Tool, um den Zugang zum eigenen Handelsplatz zu beschränken, während offene Betreiber weiterhin erlaubnisfreie Orderbücher führen. Das ist weder eine regulatorische Genehmigung noch ein Mainnet-Launch. Es ist aber genau die Art von Infrastruktur, die ein Treasury-Desk oder ein Prime Broker verlangen würde, bevor Orderflow an eine Builder-Deployer-DEX weitergeleitet wird.

Auswirkungen auf den Markt

Die unmittelbare Einordnung fällt eher strukturell als reaktiv aus.