HIP-3: Von Buildern bereitgestellte Perpetuals

Das Hyperliquid-Protokoll unterstützt erlaubnisfreie, von Buildern bereitgestellte Perps (HIP-3), einen wichtigen Meilenstein auf dem Weg zur vollständigen Dezentralisierung des Perp-Listings.

Der Deployer eines Perp-Marktes ist verantwortlich für

1. die Marktdefinition, einschließlich der Oracle-Definition und der Kontraktspezifikationen
2. den Marktbetrieb, einschließlich des Setzens von Oracle-Preisen, Hebel-Limits und ggf. der Abwicklung des Marktes

HIP-3 übernimmt den HyperCore-Stack einschließlich dessen hochperformanter Margin-Berechnung und Orderbücher. Beispielsweise ist die API für den Handel mit HIP-3-Perps mit den anderen HyperCore-Aktionen vereinheitlicht. Um HIP-3-Assets zu handeln, muss lediglich die Asset-ID gemäß dem Schema hier gesetzt werden.

Spezifikation

1. Die Staking-Anforderung für das Mainnet wird 500k HYPE betragen. Es wird erwartet, dass diese Anforderung mit zunehmender Reife der Infrastruktur sinkt. Jeder Betrag, der über die jeweils aktuelle Anforderung hinaus gestakt ist, kann unstaked werden. Die Staking-Anforderung wird mindestens 183 Tage nach dem Deployment der DEX aufrechterhalten.
2. Jeder Deployer, der die Staking-Anforderung erfüllt, kann eine Perp-DEX bereitstellen. Zur Erinnerung: Jede Perp-DEX verfügt über eine unabhängige Margin-Berechnung, eigene Orderbücher und eigene Deployer-Einstellungen. Ein künftiges Upgrade könnte mehrere DEX-Deployments unterstützen, die sich denselben Deployer und dieselbe Staking-Anforderung teilen.
3. Jedes Quote-Asset kann als Sicherheiten-Asset für eine DEX verwendet werden. Zur Erinnerung: Assets, die die Anforderungen für erlaubnisfreie Quote-Assets nicht erfüllen, verlieren ihren Quote-Asset-Status auf Basis einer On-Chain-Abstimmung der Validatoren. Eine solche Abstimmung würde auch Perp-DEXs deaktivieren, die dieses Asset als Sicherheit verwenden. Eine vom Deployer initiierte Deaktivierung des Quote-Assets deaktiviert die entsprechenden Perp-DEXs nicht.
4. HIP-3-Deployer unterliegen keinem Slashing im Zusammenhang mit Quote-Assets. Mit einem künftigen Upgrade würden DEXs mit deaktivierten Quote-Assets die Migration zu einem neuen Sicherheiten-Token unterstützen. Dies wird im Mainnet nicht erwartet, da Deployer von Quote-Tokens eigene Staking- und Slashing-Bedingungen haben. Zusammengefasst ist die Wahl des Quote-Assets für Handelsgebühren und Produktüberlegungen wichtig, stellt jedoch kein existenzielles Risiko für HIP-3-Deployer dar.
5. Die ersten 3 in einer Perp-DEX bereitgestellten Assets erfordern keine Teilnahme an einer Auktion. Weitere Assets durchlaufen eine niederländische Auktion mit denselben Hyperparametern (einschließlich Häufigkeit und Mindestpreis) wie die HIP-1-Auktion. Die HIP-3-Auktion für zusätzliche Perps wird über alle Perp-DEXs hinweg gemeinsam genutzt. Künftige Upgrades werden eine komfortablere Reservierung von Assets für zeitkritische künftige Deployments ermöglichen. Deployer erhalten außerdem 7 + 0.2 * n_auction_deployments Reservereployments, die zum aktuellen Auktionspreis genutzt werden können, jedoch den Auktions-Timer umgehen.
6. HIP-3-Märkte beinhalten die üblichen Quellen für Handelsgebührenrabatte, darunter Staking-Rabatte, Empfehlungsbelohnungen und den Rabatt für ausgerichtete Sicherheiten. HIP-3-Deployer können einen zusätzlichen Gebührenanteil zwischen 0-300% konfigurieren (0-100% im Growth Mode). Liegt der Anteil über 100%, wird auch die Protokollgebühr so erhöht, dass sie der Deployer-Gebühr entspricht.
7. Ausgerichtete Stablecoin-Sicherheiten erhalten automatisch reduzierte Gebühren, sobald die Ausrichtungsbedingung implementiert ist (die auf Grundlage von Feedback von Nutzern und Deployern überarbeitet wird).

Abwicklung

Der Deployer kann ein Asset mit der Aktion haltTrading abwickeln. Diese storniert alle Orders und wickelt Positionen zum aktuellen Mark-Preis ab. Mit derselben Aktion kann der Handel wieder aufgenommen werden, wodurch das Asset praktisch wiederverwendet wird. Dies kann genutzt werden, um datierte Kontrakte zu listen, ohne für jeden neuen Kontrakt an der Deployment-Auktion teilzunehmen.

Sobald alle Assets abgewickelt sind, kann der erforderliche Stake eines Deployers unstaked werden.

Oracle

Auch wenn das Oracle auf Protokollebene völlig allgemein ist, sind Perps mathematisch am sinnvollsten, wenn ein klar definierter Basiswert oder Daten-Feed vorhanden ist, der schwer zu manipulieren ist und eine zugrunde liegende wirtschaftliche Bedeutung hat. Die meisten Preisindizes eignen sich nicht als Oracle-Quellen für Perps. Deployer sollten Randfälle vor dem Listing von Märkten sorgfältig prüfen, da sie für alle auf ihrer DEX gelisteten Märkte dem Slashing unterliegen.

Slashing

Hinweis: In allen nachfolgenden Verwendungen bezieht sich „Slashing" ausschließlich auf HIP-3.

Um Märkte von hoher Qualität sicherzustellen und Nutzer zu schützen, müssen Deployer 500k gestaktes HYPE halten. Bei böswilligem Marktbetrieb sind Validatoren befugt, den Stake des Deployers durch eine stake-gewichtete Abstimmung zu kürzen. Selbst wenn der Deployer unstaked und eine Staking-Auszahlung eingeleitet hat, bleibt der Stake während der 7-tägigen Unstaking-Warteschlange slashingfähig.

Auch wenn über Slashing letztlich ein Validator-Quorum entscheidet, wurden die Protokollrichtlinien aus sorgfältigen Testnet-Analysen sowie Feedback von Nutzern und Deployern abgeleitet. Leitendes Prinzip ist, dass Slashing Verhalten verhindern soll, das die Korrektheit, Verfügbarkeit oder Leistung des Protokolls gefährdet. Eine nützliche Faustregel lautet, dass jedes slashingfähige Verhalten mit einem Bugfix in der Protokollimplementierung einhergehen sollte. Daher sollte HIP-3 in seinem Endzustand kein Slashing erfordern. Dennoch ist Slashing ein wichtiger Sicherheitsmechanismus für die praktische Einführung dieses umfangreichen Funktionsumfangs.

Slashing ist technischer Natur und unterscheidet nicht zwischen böswilligem und inkompetentem Verhalten. Ebenso unterscheidet Slashing nicht zwischen

1. einem Deployer, der von einer gut konzipierten Kontraktspezifikation abweicht
2. einem Deployer, der einer schlecht konzipierten Kontraktspezifikation getreu folgt
3. einem Deployer, dessen private Schlüssel kompromittiert sind

Der entscheidende Faktor ist die Auswirkung der Handlungen des Deployers auf das Protokoll. Hinweis: Alle entdeckten Bugs werden großzügig durch das Bug-Bounty-Programm vergütet, sofern solche Entdeckungen dessen Bedingungen erfüllen, einschließlich einer verantwortungsvollen Offenlegung ohne Ausnutzung. Diese Meldungen sind sehr willkommen.

Selbst versuchte böswillige Deployer-Eingaben, die keine Protokollprobleme verursachen, sind slashingfähig. Ebenso sind Eingaben, die zwar Protokollprobleme verursachen, aber nicht unregelmäßig sind, nicht slashingfähig. Insbesondere fallen Bugs im Normalbetrieb, die nicht mit den Deployer-Eingaben zusammenhängen, nicht in den Geltungsbereich des Slashings. Die Auslegung „unregelmäßiger" Eingaben wird durch eine Validator-Abstimmung bestimmt und umfasst Eingaben, die Randfälle oder Schlupflöcher ausnutzen, welche Systemlimits umgehen. Alle Deployer-Transaktionen sind On-Chain und können von jedem Interessierten unabhängig analysiert werden.

Manches böswillige Verhalten ist nach Protokolldefinition gültig, nach bestimmten subjektiven Auslegungen jedoch falsch. Das Slashing-Prinzip besagt, dass das Protokoll nicht in subjektive Angelegenheiten eingreifen soll. Der Grund dafür ist, dass Proof-of-Stake-Blockchains zwar bei unerwünschten Zustandsübergängen einen Hard Fork durchführen könnten, dies aber sehr selten tun. Die Neutralität der Plattform ist ein äußerst wichtiges zu bewahrendes Merkmal. Ebenso wird der gekürzte Stake des Deployers verbrannt, statt an betroffene Nutzer verteilt zu werden. Auch dies beruht auf Proof-of-Stake-Prinzipien und verhindert bestimmte Formen fehlausgerichteter Anreize zwischen Nutzern und Deployern. Während die Protokollebene subjektive Unregelmäßigkeiten nicht durchsetzt, können dies die nachgelagerten Anwendungs- und sozialen Ebenen tun. Letztlich stehen der Ruf des Deployers und sein künftiger Erfolg immer auf dem Spiel.

Der im Einzelfall gekürzte Betrag ist letztlich ein stake-gewichteter Median der Validator-Stimmen. Als allgemeine Richtlinie gilt jedoch: Unregelmäßige Eingaben, die ungültige Zustandsübergänge oder längere Netzwerkausfälle verursachen, können zu einer Kürzung um bis zu 100% führen. Unregelmäßige Eingaben, die kurze Netzwerkausfälle verursachen, können zu einer teilweisen Kürzung um bis zu 50% führen. Ungültige Eingaben, die eine Verschlechterung des Netzwerks oder Leistungsprobleme verursachen, können zu einer teilweisen Kürzung um bis zu 20% führen.

Schließlich sind die Slashing-Bedingungen unabhängig von der Zusammensetzung der Staker. Daher sollten LST-Betreiber Deployer sorgfältig prüfen. LST-Betreiber sollten ihren Nutzern die Slashing-Risiken außerdem sorgfältig und klar kommunizieren. Eine Anforderung an die Selbstbindung (Self-Bonding) für Deployer könnte sinnvoll sein.

Im wahrscheinlichsten Fall kommt es im Mainnet nie zu Slashing. Es wurde erheblicher technischer Aufwand investiert, um HIP-3 zu einem in sich geschlossenen und technisch robusten System zu machen. Abgesehen von Implementierungsproblemen übernimmt HIP-3 die sorgfältig konzipierten mathematischen Solvenzgarantien von Hyperliquid.

Cross-Margin

WICHTIG: Das Aktivieren von Cross-Margin für ein Asset ist unumkehrbar. Deployer sollten die nachstehenden Bedingungen vor der Aktivierung sorgfältig prüfen.

Trotz des systemweiten Schutzes gehen Nutzer ein höheres Risiko ein, wenn sie Cross-Margin über DEXs mit unterschiedlichen Deployern hinweg nutzen. Zum besseren Schutz der Nutzer werden Mainnet-Validatoren durchsetzen, dass HIP-3-Deployer Cross-Margin nur für Assets aktivieren, die definierte Zulassungskriterien erfüllen, darunter: ausreichend beobachtbare Liquidität, eine zuverlässige externe Oracle-Quelle und Widerstandsfähigkeit gegen Preismanipulation. Insbesondere werden Validatoren jedes Mal, wenn sich der `externalPerpPx` eines Assets um mehr als 50% gegenüber dem Tagesbeginnpreis bewegt, eine Prüfung durchführen, um zu entscheiden, ob der Deployer aufgrund von Manipulation einem Slashing unterzogen werden soll. Assets, bei denen 50%ige Tagesbewegungen mehr als einmal pro Monat erwartet werden, sind für Cross-Margin nicht zugelassen und unterliegen dem Deployer-Slashing.

Backstop-Liquidator

Jede HIP-3-DEX ist mit einer vollständig On-Chain-Strategie unter 0x400..00 + {dex_index} verknüpft, die Backstop-liquidierbare Positionen der jeweiligen HIP-3-DEX übernimmt. Die On-Chain-Backstop-Liquidatoren akzeptieren nur Assets, für die Cross-Margin aktiviert ist, wodurch diese Assets bei künftigen Ereignissen mit hoher Volatilität deutlich seltener von ADL betroffen sind. Der On-Chain-Backstop-Liquidator jeder DEX ist ein unabhängiger Nutzer und greift auf ADL zurück, um die Solvenz der DEX mathematisch zu garantieren.

Für Nutzer besteht kein Handlungsbedarf. Nach vollständiger Skalierung werden die Backstop-Liquidatoren unterbesicherte Positionen aufnehmen und dabei zugleich uneinbringliche Schulden vermeiden und den Bedarf an ADL verringern.