Tiefblick in HIP-3: Eine entwicklerzentrierte Perspektive

Hyperliquid Improvement Proposal 3 (HIP-3) [1] führt eine grundlegende Änderung in der Art und Weise ein, wie Perpetual-Märkte auf Hyperliquid erstellt und skaliert werden. Indem der Prozess der Markteinführung für Drittentwickler geöffnet wird, verlagert HIP-3 die Notierung von einer diskretionären, plattformgesteuerten Aktion zu einer regelbasierten Schnittstelle auf Protokollebene.

Seit der Bereitstellung auf dem Mainnet haben von Entwicklern bereitgestellte Märkte in etwa drei Monaten ein Handelsvolumen von über 13 Milliarden US-Dollar generiert, was zeigt, dass HIP-3 die Skalierbarkeit und Flexibilität der Marktexpansion erheblich verbessern kann. Dieser Wandel dezentralisiert jedoch nicht nur die Macht; er ordnet auch die Verantwortung neu. Risiken, die zuvor von zentralisierten Plattformoperationen absorbiert oder gemindert wurden, werden nun direkt von den Entwicklern getragen.

Infolgedessen ist die Kernfrage unter HIP-3 nicht mehr, ob ein Markt gestartet werden kann, sondern ob er über einen längeren Zeitraum sicher betrieben werden kann. Dieser Bericht analysiert HIP-3 aus einer entwicklerzentrierten Perspektive und konzentriert sich darauf, wie Märkte definiert und betrieben werden, welche Risiken Entwickler eingehen und wie diese Risiken, insbesondere orakelbezogene Risiken, gemindert werden können.

0x0 Hintergrund

Die Architektur von Hyperliquid [2] weicht von diesem Modell ab, indem sie die Ausführungs- und Infrastruktureinfrastruktur von der Markdefinition entkoppelt. Ihr zweischichtiges Design besteht aus:

• HyperCore, einer speziell entwickelten Layer-1-Blockchain, die für den Derivathandel optimiert ist und einheitliches Matching, Liquidation und Abwicklung bietet.
• HyperEVM, eine EVM-kompatible Anwendungsebene, die erweiterbare Logik und Entwicklerinteraktion ermöglicht.

Da Ausführung und Liquidation auf Protokollebene einheitlich durchgesetzt werden, können neue Märkte dieselbe Kerninfrastruktur wiederverwenden, ohne kritische Sicherheitslogik neu implementieren zu müssen. Die Preisgestaltung kann jedoch nicht vollständig standardisiert werden. Orakel-Inputs, Hebendesign und Laufzeitoperationen variieren zwangsläufig je nach Markt, wodurch die Preisgestaltung zur primären Schnittstelle wird, an der die Dezentralisierung auf Risiko trifft.

Trotz dieser Architektur ähnelt der Listungsprozess für native Perpetual-Märkte von Hyperliquid, auch als Validator-verwaltete Perps bezeichnet, immer noch einem traditionellen CEX-Ansatz. Die Notierung neuer Kontrakte wird weitgehend vom Kernteam vorangetrieben, während Delistings über Validator-Abstimmungen bestimmt werden.

HIP-3 wurde eingeführt, um diesen Listungsprozess zu dezentralisieren, indem von Entwicklern bereitgestellte Perpetual-Märkte ermöglicht werden. Es formalisiert die Trennung zwischen Markdefinition und protokollgesteuerter Ausführung, indem es Entwicklern ermöglicht, Märkte zu definieren und zu betreiben, während das Protokoll harte Ausführungs- und Risikogrenzen durchsetzt. Als solches stellt HIP-3 einen wichtigen Meilenstein auf dem Weg zu einem vollständig dezentralen Perp-Listing-Prozess dar.

0x1 Verantwortlichkeiten der Entwickler: Definition und Betrieb

Unter HIP-3 übernehmen Entwickler die End-to-End-Verantwortung für das Lebenszyklusmanagement des Marktes. In diesem Abschnitt durchlaufen wir zunächst den Workflow des Marktstarts und konzentrieren uns dann auf die operativen Hebel, die die Marktstabilität in der Produktion am direktesten bestimmen.

0x1.1 Marktstart-Workflow: Definition und Betrieb

Unter HIP-3 ist der Start eines Marktes keine einzelne Aktion. Wie im vollständigen Marktstart-Workflow unten dargestellt, ist dies ein Prozess, der zwei separate Phasen umfasst: Marktdefinition (Schritte 1 bis 4) und Marktbetrieb (Schritt 5).

Während der Phase der Marktdefinition muss ein Entwickler zunächst 500.000 HYPE auf dem Mainnet staken. Nach Erfüllung der Staking-Anforderung kann der Entwickler einen Perpetual-DEX bereitstellen, der eine unabhängige Handelssphäre mit eigenem Margin-System, Orderbüchern und vom Deployer gesteuerten Einstellungen bildet. Auf DEX-Ebene wählt der Entwickler eine Quote-Asset aus, die als Sicherheit für alle Märkte auf diesem DEX verwendet wird. Das ausgewählte Quote-Asset muss den Status "erlaubnisfrei" beibehalten, da der Verlust dieses Status den entsprechenden DEX deaktiviert. Der Entwickler definiert dann Kernmarktparameter, einschließlich Orakelspezifikationen, Vertragsparameter wie Symbole und Hebelgrenzen sowie Margin-Tabellen. Die ersten drei Märkte können direkt bereitgestellt werden, während zusätzliche Märkte durch eine niederländische Auktion Plätze erwerben müssen.

Niederländische Auktion: Jede Runde dauert 31 Stunden, der Startpreis ist jedes Mal das 2-fache des vorherigen Endpreises (letzter Gewinnpreis / niedrigster Preis).

Sobald die Märkte live sind, tritt der Entwickler in die Marktbetriebsphase ein. Diese Phase umfasst die kontinuierliche Aktualisierung von Orakelpreisen über die setOracle-Schnittstelle, die Aufrechterhaltung von Hebel- und Margin-Konfigurationen, die Überwachung von Liquidität und offenen Interessen sowie die Ausführung von Notfallmaßnahmen wie dem Stoppen des Handels und der Abwicklung von Positionen bei Bedarf.

In der Praxis treten die schwerwiegendsten Ausfälle unter HIP-3 nicht während der Marktdefinition auf, sondern während des anhaltenden Betriebs unter angespannten Marktbedingungen. Wichtig ist, dass die Verantwortung des Entwicklers nicht unmittelbar nach dem Stoppen der Märkte endet. Das Entsperren ist erst möglich, nachdem alle Märkte abgerechnet sind, und der Stake bleibt während der obligatorischen Entsperrungsperiode slashingfähig.

0x1.2 Kritische Fokusbereiche: Preisbildung und Solvenz

Entwickler stehen in den Bereichen Marktdefinition und Marktbetrieb vor zwei gekoppelten Fokusbereichen: Orakelkonfiguration und Preisbildung sowie Marktfinanzielle Stabilität unter Belastung. Diese beiden Bereiche sind eng miteinander verknüpft, da Preisfehler durch protokollweite Risikokontrollen schnell zu finanziellen Belastungen eskalieren können.

1. Orakelkonfiguration und Preisbildung

Hyperliquid definiert zwei Preise:

• Orakelpreis: Ein gewichteter Median der Spot-Mittelkurse von großen externen Börsen, der unabhängig von den internen Marktdaten von Hyperliquid sein soll und hauptsächlich zur Verankerung von Finanzierungen verwendet wird.
• Marktpreis: Ein interner Risikopreis, der sich aus mehreren Eingaben ableitet, einschließlich des Orakelpreises und lokaler Marktdaten, der für nicht realisierte Gewinne und Verluste (PnL) und Risikokontrollen verwendet wird.

Kurz gesagt: Der Orakelpreis verankert die Finanzierung, während der Marktpreis Margin-Prüfungen, Liquidationen und TP (Take Profit) und SL (Stop Loss) Trigger antreibt.

Unter HIP-3 ändern sich die Rollen von Orakelpreis und Marktpreis nicht, aber der Berechnungsmechanismus ändert sich:

a) Eingaben für setOracle

• oraclePx (erforderlich): gleiche Definition wie in HyperCore.
• markPx (optional): 0–2 extern berechnete Marktpreis-Kandidaten.
• externalPerpPx (erforderlich): ein Referenzwert, um plötzliche Abweichungen des Marktpreises zu verhindern.

Entwickler setzen typischerweise Relaisknoten ein, um Preise zu übermitteln: oraclePx wird aus mehreren externen Quellen berechnet, markPx wird vom Relais mit einem benutzerdefinierten Algorithmus berechnet und externalPerpPx aus dem gewichteten Median von Perp-Mittelkursen mehrerer CEXs.

b) Tatsächlicher Marktpreis

• Berechnen Sie lokalen Markt: median(best bid, best ask, last trade).
• Nehmen Sie lokalen Markt und markPx (0–2 Werte) zusammen und nehmen Sie den Median, um den neuen Marktpreis zu erhalten.

c) setOracle-Beschränkungen

• Update-Frequenz: mindestens 2,5 s zwischen Aufrufen; wenn markPx für 10 s nicht aktualisiert wird, fällt es auf den lokalen Marktpreis zurück.
• Amplitudenbeschränkungen: markPx kann pro Update um maximal ±1% geändert werden; alle Preise werden innerhalb des 10-fachen des Start-Tages-Preises geklemmt.

Warum der Anlagetyp für die Preisbildung in HIP-3 wichtig ist

Unter HIP-3 können Perpetual-Märkte für jede Art von Vermögenswert gestartet werden. Diese Vermögenswerte können im Allgemeinen in 24/7-Vermögenswerte (rund um die Uhr handelbar) und Nicht-24/7-Vermögenswerte (nur während spezifischer Marktstunden handelbar, ohne Spot-Handel außerhalb dieser Stunden) unterteilt werden. Der Unterschied bei den Handelszeiten bestimmt grundlegend, wie Preise bezogen und aufrechterhalten werden.

Für 24/7-Vermögenswerte (z.B. BTC) können durch Aggregation von Daten von CEXs, DEXs oder vertrauenswürdigen Orakeldiensten relativ stabile Preise kontinuierlich bezogen werden.

Für Nicht-24/7-Vermögenswerte (z.B. Aktien) sind ausreichende Liquidität und zuverlässige externe Marktpreise nur während der offiziellen Handelszeiten verfügbar. Um solche Vermögenswerte auf HIP-3 kontinuierlich handeln zu lassen, muss während der außerbörslichen Stunden ein separater Preisbildungsmechanismus verwendet werden.

Am Beispiel der Aktien-Perp-Märkte auf trade.xyz:

• Während der Marktstunden werden stabile Orakelpreise von externen Orakeldiensten wie Pyth bereitgestellt.
• Außerhalb der Marktstunden werden die Preise basierend auf dem letzten Schlusskurs des Vermögenswerts in Kombination mit dem internen Kauf-/Verkaufsdruck des Orderbuchs angepasst. Der Marktpreis ist so eingeschränkt, dass er innerhalb von ±1 / max_leverage des letzten Schlusskurses schwankt (z. B. Tesla: 10-fache Hebelwirkung → ±10 %).

2. Marktfinanzielle Stabilität unter Belastung

Hyperliquid verwendet zwei Mechanismen, Liquidation und ADL (Auto-Deleveraging), um die Marktfinanzielle Stabilität aufrechtzuerhalten. Unter HIP-3 folgen sowohl Liquidation als auch ADL weitgehend dem Design von HyperCore. Der Hauptunterschied ist eine Beschränkung auf Protokollebene: HLP (Hyperliquidity Provider), der als Protokoll-Tresor dient, kann keine risikoreichen Positionen in HIP-3-Märkten übernehmen. Infolgedessen fehlt der Zwischen-Tresor-Puffer, der Positionen zwischen Marktliquidierung und ADL in HyperCore aufnehmen kann, in HIP-3.

Angesichts der Bedeutung dieses Liquidierungs-zu-ADL-Pfades unter angespannten Marktbedingungen überprüfen wir Liquidation und ADL im Detail unten. Alle hier diskutierten Solvenzmechanismen gehen von isolierter Marge aus, dem einzigen Margin-Modus, der derzeit in HIP-3-Märkten unterstützt wird.

a) Liquidation

Die Liquidation wird ausgelöst, wenn der Netto-Positions-Wert (isolierter Positions-Wert) nicht ausreicht, um die Erhaltungs-Margin-Anforderung zu erfüllen; er wird liquidierbar. Alle liquidationsbezogenen Prüfungen basieren auf dem Marktpreis, nicht auf einem bestimmten Ausführungspreis.

Die Formel für den Liquidationspreis ist wie folgt definiert:

Dabei gilt:

• side: 1 für Long-Positionen, -1 für Short-Positionen
• l ist die Erhaltungs-Margin-Quote

Der Wert von MAINTENANCE_LEVERAGE wird durch die Margin-Stufe bestimmt, die der Position entspricht. Aus dieser Stufe wird die Erhaltungs-Margin-Quote mmr ermittelt:

Wenn Margin-Stufen konfiguriert sind, wenden Sie die mmr der Stufe an, die dem Nominalwert der Position zum Liquidationspreis entspricht.

• margin_available (isoliert): isolierte_margin - erforderliche_erhaltungs_margin

Sobald eine Position liquidierbar wird, versucht das System zunächst, sie über Market-Orders im Orderbuch zu schließen. Wenn die Ausführung erfolgreich dazu führt, dass das Risiko wieder innerhalb sicherer Grenzen liegt, wird jede verbleibende Marge an den Händler zurückgegeben.

In Fällen von unzureichender Orderbuchtiefe oder Preislücken kann der tatsächliche durchschnittliche Ausführungspreis jedoch deutlich schlechter sein als der Marktpreis, was zu einem ''Liquidation-Shortfall'' führt.

Isolierter Positions-Wert bezieht sich auf den Netto-Wert einer isolierten Position zum aktuellen Marktpreis und repräsentiert die Marge, die dieser Position nach Berücksichtigung nicht realisierter Gewinne und Verluste zugewiesen wird.

b) ADL (Auto-Deleveraging)

In extremen Szenarien fungiert der ADL (Auto-Deleveraging) Mechanismus als letzte Rückfalloption.

ADL wird ausgelöst, wenn der isolierte Positions-Wert negativ wird. Das System sortiert profitable Gegenparteien nach PnL und Hebelwirkung und reduziert oder schließt diese Positionen dann zwangsweise zum vorherigen Marktpreis (dem zuvor aufgezeichneten Marktpreis, bevor ADL ausgelöst wird). Durch die Verwendung der Gewinne der Gewinnerseite zum Ausgleich des Defizits bleibt das Protokoll zahlungsfähig und erleidet keine Wertverluste.

Der Sortierindex wird wie folgt berechnet:

Hier bezieht sich notional_position auf den absoluten Marktwert der Position zum geltenden Marktpreis, berechnet als |position_size| × mark_price. account_value bezeichnet das Eigenkapital des Kontos zum Marktpreis, d.h. den Collateralwert plus nicht realisierte Gewinne und Verluste.

Beispiel:

• Bevor ADL ausgelöst wird, beträgt der Marktpreis des Systems 3.000.
• Aufgrund von setOracle-Beschränkungen kann der neue Marktpreis nur auf 2.970 (−1 %) aktualisiert werden.
• Die Angebotsseite des Orderbuchs ist jedoch sehr dünn. Nachdem die Market-Orders ausgeführt wurden, beträgt der tatsächliche durchschnittliche Ausführungspreis = 2.910 (−3 % im Vergleich zu 3.000).
• Verluste bei Long-Positionen werden zu 2.910 abgerechnet, was den isolierten Positions-Wert möglicherweise unter Null drückt und einen Fehlbetrag erzeugt, der ADL auslöst.
• ADL wählt dann Gegenpositionen (profitable Shorts) aus und reduziert/schließt diese zwangsweise zum vorherigen Marktpreis = 3.000, wodurch der Fehlbetrag in ''die passive geringere Verdienst des Gewinnerseite'' verschoben wird.

0x2 Risikolandschaft für Entwickler

Unter HIP-3 sind Risiken für Entwickler nicht mehr abstrakt oder rein theoretisch. Durch Staking und Validatoren-gesteuertes Slashing können operative Ausfälle und Fehlkonfigurationen direkt zu wirtschaftlichen Strafen führen. Daher wird das Verständnis, wie Slashing ausgelöst wird und welche Arten von Entwicklerverhalten dazu führen können, zentral für das Risikomodell des Entwicklers. Daher erklärt dieser Abschnitt zunächst den Slashing-Mechanismus als Rechenschaftsrahmen und analysiert dann die beiden Hauptquellen für Entwicklerrisiken unter HIP-3.

0x2.1 Slashing-Mechanismus und Rechenschaftspflicht

HIP-3 erzwingt Rechenschaftspflicht durch Staking und Validatoren-gesteuertes Slashing. Slashing basiert streng auf Ergebnissen. Hyperliquid unterscheidet nicht zwischen bösartigem Verhalten, operativen Fehlern, Kompromittierung von privaten Schlüsseln oder Ausfällen von Drittanbietern.

Staking-Anforderung: Auf dem Mainnet müssen Entwickler 500.000 HYPE gestaked halten. Selbst wenn ein Entwickler alle seine Märkte stoppt, muss er sie für 30 Tage weiter vorhalten (die Verantwortung verschwindet nicht sofort, nur weil der Handel gestoppt ist).

Wenn die Aktionen eines Entwicklers zu einem ungültigen Zustand, einer längeren Ausfallzeit oder einer erheblichen Leistungsverschlechterung führen, kann Slashing ausgelöst werden. Je nach Schweregrad kann Slashing von einer teilweisen Stake-Reduzierung bis zu einem vollständigen Stake-Burn reichen. Dieses Design macht Entwickler wirtschaftlich für das gesamte Laufzeitverhalten ihrer Märkte verantwortlich.

Der Slashing-Prozentsatz wird durch Validator-Abstimmung mit Bezugsobergrenzen festgelegt:

• Ungültiger Zustand / längere Ausfallzeit: bis zu 100 %
• Kurze Ausfallzeit: bis zu 50 %
• Leistungsverschlechterung: bis zu 20 %

Gecrosste Token werden verbrannt, nicht neu verteilt.

Unter HIP-3 ergeben sich die Risiken für Entwickler hauptsächlich aus zwei Quellen: interne Fehlkonfiguration von Parametern und externe Orakelabhängigkeiten. Die folgenden Abschnitte untersuchen diese beiden Quellen im Detail und erklären, wie sie zu Slashing-Ergebnissen führen können.

0x2.2 Risiken durch interne Fehlkonfiguration von Parametern

Zu den Risiken von Fehlkonfigurationen gehören übermäßiger Hebel bei Märkten mit geringer Liquidität, unsachgemäßes Design von Margin-Tabellen, plötzliche Parameteränderungen, die eine große Anzahl von Positionen liquidierbar machen, und unangemessene Nutzung von Notfallkontrollen wie dem Stoppen des Handels.

Diese Risiken sind weitgehend deterministisch und vermeidbar. Mit ausreichender Sorgfalt, Überprüfung und operativer Disziplin können die meisten internen Konfigurationsfehler vermieden werden. Obwohl wichtig, sind sie nicht die strukturell herausforderndsten Risiken unter HIP-3.

1. setOracle

Orakelpreise stammen typischerweise von den Relais-Servern des Entwicklers, was ein Zentralisierungsrisiko mit sich bringt. Wenn der private Schlüssel kompromittiert wird oder der Relais-Server von einem DDoS-Angriff betroffen ist, kann der Orakelpreis des Marktes böswillig manipuliert werden oder über einen langen Zeitraum abweichen.

2. haltTrading

Der Entwickler kann alle Aufträge im Markt über haltTrading stornieren und Positionen zum aktuellen Marktpreis schließen. Diese Operation sollte mit Vorsicht angewendet werden. Wenn beispielsweise erkannt wird, dass der Markt von einem Angreifer böswillig manipuliert wird und haltTrading aufgerufen wird, um zum Marktpreis zu schließen, kann dies direkt die nicht realisierten Gewinne des Angreifers realisieren (wo der Angreifer sonst Schwierigkeiten hätte, genügend Gegenaufträge zu finden) und kann auch zu Wertverlusten führen.

3. setMarginTableIds & InsertMarginTable

• InsertMarginTable: definiert eine neue Margin-Tabelle, die Margin-Anforderungen und maximalen Hebel für eine Klasse von Vermögenswerten festlegt.
• setMarginTableIds: bindet einen Markt an eine angegebene marginTableId.

Für einen Markt mit geringer Liquidität / unzureichender Market-Making erhöht die Festlegung eines zu hohen maximalen Hebels die Wahrscheinlichkeit, ADL auszulösen.

Das plötzliche Wechseln von marginTableId entspricht einer Änderung der Erhaltungs-Margin-Quote von Nutzerpositionen, was viele Konten gleichzeitig von sicher zu liquidierbar machen kann und kaskadierende Liquidationen auslöst.

4. setMarginModes

HIP-3 erlaubt derzeit nur isolierte Margen und unterstützt möglicherweise in Zukunft Cross-Margen. Innerhalb eines DEX, der sowohl Märkte mit hoher als auch mit geringer Liquidität beherbergt, kann Cross-Margen eine Risiko-Kontamination ermöglichen, bei der Verluste in illiquiden Märkten auf liquide Märkte übergreifen. Daher wird es Entwicklern nicht empfohlen, Cross-Margen einzuführen, bis das offizielle Team eine ausgereifte Lösung anbietet.

0x2.3 Risiken aus externen Orakelabhängigkeiten

Für 24/7-Vermögenswerte liegen die Hauptrisiken in der Genauigkeit und Stabilität externer Orakeldienste sowie in den bereits erwähnten Zentralisierungsrisiken von Relais-Servern. Jede Unterbrechung, Verzögerung oder Manipulation dieser externen Abhängigkeiten kann die Preisintegrität und nachgelagerte Risikokontrollen direkt beeinträchtigen.

Für Nicht-24/7-Vermögenswerte ist die Risikofläche deutlich breiter und konzentriert sich hauptsächlich darauf, wie Orakelpreise während der Nicht-Handelszeiten bezogen oder berechnet werden.

Am Beispiel von trade.xyz werden außerhalb der Marktzeiten die Preise aus einer Kombination des zuletzt verfügbaren externen Orakelpreises und der internen Marktpreise abgeleitet. An Wochenenden leiden Aktien-Perp-Märkte oft unter stark reduzierter Liquidität – Orderbücher werden dünn und Market Maker reduzieren das Quoting – während keine externen Orakelpreise zur Verankerung zur Verfügung stehen. Obwohl eine harte Grenze für Preisbewegungen auferlegt wird (z. B. 1 / max_leverage), kann diese Beschränkung für Vermögenswerte mit geringer Volatilität immer noch zu locker sein. Preisbewegungen innerhalb dieses Bereichs können dennoch groß angelegte Liquidationen oder sogar ADL-Ereignisse auslösen.

Am 14. Dezember 2025 wurde der XYZ100-USDC-Markt auf trade.xyz – ein Perpetual-Kontrakt, der den NASDAQ-100 abbildet – manipuliert. Ein Angreifer verkaufte 398 XYZ100 (ungefähr 10 Millionen US-Dollar an nominalem Engagement) short und verursachte eine starke Preisentkopplung. Eine große Anzahl von Long-Positionen wurde liquidiert, und die Liquidationen selbst drückten die Preise weiter nach unten, was schließlich zu Long-seitigen Liquidationen von rund 13 Millionen US-Dollar führte.

Auf der anderen Seite zwingt die Abwesenheit eines kontinuierlichen und extern verankerten Orakelpreises während der Nicht-Handelszeiten die Märkte, sich auf ein eingeschränktes internes Preisband zu verlassen, das sich aus dem "letzten externen Preis + internem Orderbuch" zusammensetzt (z. B. trade.xyz begrenzt die maximale Schwankung auf 1/max_leverage).

Das kritischste Risiko entsteht beim Übergang zur Wiedereröffnung des Marktes. Externe Märkte können plötzlich einen klaren und autoritativen Referenzpreis liefern. Wenn dieser Preis eine signifikante Lücke im Vergleich zur internen Preisgestaltung außerhalb der Marktzeiten aufweist, steht das System vor zwei ungünstigen Wegen: Entweder bleiben die Preise eingeklemmt, was zu einer erheblichen Divergenz zwischen dem externen fairen Wert und den handelbaren Preisen führt, oder das System schaltet schnell zurück zur externen Verankerung, was zu einer abrupten Neubewertung führt. Beide Szenarien können den Liquidationsdruck in einem kurzen Zeitfenster konzentrieren und in extremen Fällen zu einem Anstieg der ADL-Ereignisse führen.

0x3 Risikokontrollen für Entwickler

Konfigurationsdisziplin allein kann das Risiko nicht eliminieren. Die effektivsten Minderungsstrategien konzentrieren sich auf die Reduzierung der Abhängigkeit von Orakelabhängigkeitsausfällen.

0x3.1 Auswahl stabiler Orakel

Für nicht rund um die Uhr gehandelte Vermögenswerte wie Aktien liegt die Hauptherausforderung in der Preisbildung außerhalb der Marktzeiten. In diesen Perioden sind stabile und extern verankerte Preisreferenzen rar, was Märkte anfälliger für Manipulationen oder endogenes Driften unter dünner Liquidität macht.

Derzeit fallen branchenübliche Ansätze im Allgemeinen in zwei Richtungen:

• Aussetzung von Orakelaktualisierungen und Beschränkung des Handels außerhalb der Marktzeiten. Zum Beispiel akzeptiert das Lighter-Protokoll nur auf Reduzierung beschränkte Orders, wenn der zugrunde liegende Markt geschlossen ist. Protokolle wie Ostium reduzieren den maximalen Hebel weiter außerhalb der Marktzeiten und liquidieren zwangsweise Positionen, die die neuen Limits überschreiten.
• Annahme eines ''internen Preisbildungsmechanismus'', wie er bei trade.xyz zu sehen ist, bei dem das Protokoll während der Ausfallzeiten durch Nutzung interner Liquidität und Preisalgorithmen weiterarbeitet, wenn externe Daten nicht verfügbar sind.

Diese beiden Ansätze spiegeln einen grundlegenden Kompromiss zwischen Sicherheit und Benutzererfahrung wider. Der erste Ansatz priorisiert strenge Risikokontrollen, verschlechtert aber die Handelskontinuität und das Benutzererlebnis erheblich. Der zweite bewahrt den kontinuierlichen Handel, birgt aber aufgrund des Fehlens externer Referenzen das Risiko, dass interne Preise vom fundamentalen Wert des Vermögenswerts abweichen.

Außerhalb der Marktzeiten sollte die Protokollpreisgestaltung vermeiden, vollständig zu einer rein internen Preisgestaltung zu degenerieren. Stattdessen kann die Einführung von externen Referenzankern die Entkopplung und Lückenrisiken reduzieren. Mögliche Referenzen umfassen:

• Blue Ocean ATS. Als Handelsplatz außerhalb der Marktzeiten/über Nacht kann er während der Schließzeiten ein gewisses Maß an kontinuierlicher Preisreferenz bieten (zeitnaher als "letzter Schlusskurs"), um die Orakelpreise für die Schließungsperiode zu generieren oder als Überwachungsbasis für die Entkopplung zu dienen.
• IG Weekend CFD-Notierungen. Wochenend-CFD-Notierungen können ein alternatives Preissignal liefern, das ''Erwartungen des Wochenendmarktes'' widerspiegelt, geeignet als externer Anker oder zur Überwachung im Vergleich während der Schließzeiten, um die wahrscheinliche Richtung und Größe einer ''Eröffnungs-Gap'' im Voraus zu erkennen.

Das gemeinsame Merkmal dieser Quellen ist ihre Fähigkeit, Preissignale während der Ausfallzeiten zu liefern. Sie teilen jedoch nicht dieselbe Marktstruktur wie der zugrunde liegende Spot-Markt und eignen sich daher besser als Anker, Referenzen oder Frühwarnsignale als bedingungslose Ersatzstoffe.

0x3.2 Preisüberprüfung

Unter HIP-3 werden Orakelpreise von von Entwicklern betriebenen Relais-Servern bezogen, was Bedenken hinsichtlich der Zentralisierung aufwirft. Um dies zu mildern, werden Entwickler ermutigt, ein Preisüberprüfungs-Framework zu implementieren, das es jedem Benutzer oder jeder Institution ermöglicht, die Preisgenauigkeit und -fairness off-chain zu überprüfen – ähnlich wie bei RedStone, das Preise zusammen mit Datenquellen und kryptografischen Beweisen bündelt.

1. Datentransparenz

• Algorithmus-Spezifikation: Veröffentlichung von Preisalgorithmen und Berechnungslogik.
• Liste der Datenquellen: Alle Quellen sollten öffentlich, manipulationssicher durch den Entwickler und mit detaillierten Schnittstellen und Parametern dokumentiert sein.
• Regeln für die Preisübermittlung: Berechtigungen, Auslösebedingungen, Aktualisierungsfrequenz und Volatilitätsbeschränkungen für setOracle.

2. Preisbeweise

Für jeden setOracle-Aufruf wird ein entsprechender Beweis generiert, der Folgendes enthält:

• Eingaben: Rohdaten (oder normalisierte) Antworten von jeder Datenquelle zum Abtastzeitpunkt.
• Berechnung: Reproduzierbare Zwischenwerte bei jedem Berechnungsschritt.
• Ausgaben: Der auf der Blockchain eingereichte Orakelpreis.

Jeder Beweis wird in einen proofHash serialisiert, der dann vom oracleUpdater signiert wird.

3. On-Chain-Verpflichtungen

• Beibehalten einer sequentiellen Liste von proofHash-Einträgen in einem Merkle-Baum.
• Periodisches (z. B. stündlich oder täglich) Veröffentlichen des MerkleRoot auf der Blockchain.

4. Verifizierung

• Bereitstellung von Open-Source-Tools oder einer Webseite, auf der Benutzer einen Zeitbereich oder eine setOracle-Transaktions-ID eingeben können
• Überprüfung von Signaturen, Zeitstempeln und MerkleRoot usw.
• Erneute Berechnung der Orakelpreise anhand des öffentlichen Algorithmus zum Vergleich.

0x3.3 Risikomonitoring

Preisüberprüfung macht setOracle reproduzierbar und auditiertbar, wodurch festgestellt wird, ob Preisfeeds vertrauenswürdig sind. Sie schützt jedoch nicht vor der Verschlechterung des Live-Marktes. Feed-Unterbrechungen, Preisabweichungen und Liquiditätsverschlechterung – in Kombination mit großen offenen Interessen (OI) – können lokalisierte Anomalien leicht zu systemischen Risiken wie kaskadierenden Liquidationen oder sogar ADL-Ereignissen eskalieren lassen.

Daher müssen Markt-Anomalien so früh wie möglich erkannt und in beobachtbare Signale umgewandelt und innerhalb eines Zeitfensters behoben werden, um das Risiko innerhalb beherrschbarer Grenzen zu halten.

Um das Monitoring umsetzbar und nicht fragmentiert zu gestalten, organisieren wir Signale in drei Ebenen, die jeweils einem unterschiedlichen Ausfallmodus und einer unterschiedlichen Reaktionspriorität zugeordnet sind.

• Preisseitiges Monitoring erkennt Orakel-Feed-Ausfälle und Preisentkopplungen, die Risikokontrollen an der Quelle ungültig machen können, und wird daher als höchste Priorität behandelt und typischerweise durch Relais-Failover, Open-Interest-Caps und Hebelreduzierungen adressiert.
• Orderbuchseitiges Monitoring erfasst Liquiditätsentzug und gefälschte Tiefe, die Slippage und Shortfall-Risiken bei der Liquidation verstärken, so dass sich Interventionen auf die Begrenzung der inkrementellen Exposition und die erzwungene De-Leverage bei zunehmender Fragilität konzentrieren.
• Positionsseitiges Monitoring verfolgt schnelle Open-Interest-Aufbauten und einseitige Konzentrationen, die Märkte anfällig für Kaskaden machen, und hat generell eine niedrigere Priorität als Preis- und Liquiditätssignale, dient aber hauptsächlich als Frühwarnschicht, die engere Obergrenzen und erhöhte Warnungen informiert.

Die folgenden Abschnitte beschreiben jede Ebene im Detail zusammen mit den entsprechenden Überwachungspunkten und empfohlenen Maßnahmen.

1. Preisseitiges Monitoring

a) Ausfall des Orakel-Feeds

Metriken:

• Verwenden Sie On-Chain-Beobachtbare, um zu beurteilen, ob der Feed blockiert ist:

Schwellenwerte:

• Level 1: ( ∆t > 5s ) — Relais-Prozess kann blockiert oder unterbrochen sein
• Level 2: ( ∆t > 15s ) — On-Chain-Preise können stark entkoppelt und zunehmend marktgesteuert sein

Maßnahmen:

• Level 1: Durchführung von Relais-Integritätsprüfungen, Wechsel zu Backup-Relais und Ausgabe von Warnungen mit Integritätsdiagnosen
• Level 2: Aufruf von setOpenInterestCaps, um die OI-Obergrenze zu senken

b) Preis-Entkopplung

Metriken:

• Signal A (d1): Abweichung zwischen Marktpreis und Orakelpreis.

• Signal B (d2): Abweichung zwischen Orderbuch-Mittelpreis und Orakelpreis.

• Signal C (d3): Abweichung zwischen Marktpreis und Mittelpreis.

• Signal D (ext_diff): Abweichung zwischen Orakelpreis und externem Referenzpreis.

Schwellenwertlogik:

• Level 1: mindestens 2 der A, B, D überschreiten die Schwellenwerte.
• Level 2: mindestens 3 der A, B, C, D überschreiten die Schwellenwerte für X Sekunden.

Maßnahmen:

• Level 1: OI-Obergrenze über setOpenInterestCaps reduzieren.
• Level 2: Margin-Tabellen schrittweise aktualisieren, um den maximalen Hebel nach Stufen zu reduzieren, und Klemmmechanismen an Relais aktivieren.
• Level 3: Anhaltende Warnungen unter Level 2 Bedingungen. Der Entwickler bewertet dann, ob haltTrading aufgerufen werden soll.

2. Orderbuchseitiges Monitoring

a) Liquiditätsentzug

Metriken:

• depth_band(±x%): Orderbuch-Liquidität, die innerhalb von ±x% des Mittelpreises verfügbar ist.
• spread = bestAsk - bestBid: Preisspanne zur Messung der Spannenverbreiterung.
• aggressiveVolume_Δt: Taker-Volumen innerhalb von Δt (aggregiert nach Handelsseite).
• impact_ratio: Indikator für Marktfragilität (höhere Werte zeigen eine größere Anfälligkeit für Preisbeeinflussung).

Risikomuster:

• depth_band sinkt, während spread und impact_ratio steigen.

Maßnahmen:

• Level 1: OI cap = current OI über setOpenInterestCaps festlegen, um inkrementelle Positionen zu begrenzen.
• Level 2: Zwangsweise Hebelreduktion über setMarginTableIds, während hoch gehebelte, hoch riskante Positionen liquidiert werden.

b) Gefälschte Liquidität

Risikomuster:

• Plötzliche Spitzen bei depth_band, gefolgt von einem Zusammenbruch innerhalb eines kurzen Zeitfensters.

Maßnahmen:

• Level 1: Aufruf von setOpenInterestCaps, um OI cap = current OI festzulegen.
• Level 2: Wenn kombiniert mit starker Preisentkopplung, Erwägung des Stoppens des Marktes.

3. Positionsseitiges Monitoring

Positionsseitiges Monitoring versucht nicht, die Preisrichtung vorherzusagen. Stattdessen identifiziert es Übergänge von ausgeglichener Handelsaktivität zu einseitiger Positionsakkumulation. Wenn OI schnell ansteigt, sich Positionen stark konzentrieren und die Gewinne der Mehrheitsseite extreme Werte erreichen, können selbst geringfügige exogene Schocks zu Liquidationskaskaden oder ADL-Ereignissen führen.

Daher haben positionsseitige Aktionen typischerweise eine niedrigere Priorität als preis- und orderbuchseitige Interventionen.

a) Übermäßiges kurzfristiges OI

Metriken:

• OI_notional: Nominale offene Zinsen.
• Volume_24h_notional: 24-Stunden-Nominalvolumen.

Ein sich schnell erhöhendes Verhältnis zeigt eine Verschiebung von aktiver Umschlagshäufigkeit hin zu spekulativer Positionsbildung an und geht oft einer starken Volatilität voraus.

Maßnahmen:

• Level 1: Auslösen von Warnungen, wenn Schwellenwerte überschritten werden.

b) PnL der Mehrheitsseite

Mehrheitsseite bezieht sich auf die Seite (Long oder Short) mit den meisten Positionsinhabern innerhalb des Beobachtungsfensters.

Metriken:

• avgEntry_major: Durchschnittlicher Einstiegspreis der Mehrheitsseite.
• size_major: Gesamte Positionsgröße der Mehrheitsseite.
• equity_major: Gesamtes Eigenkapital der Mehrheitsseite.

Die Gewinne und Verluste der Mehrheitsseite und ihr Verhältnis sind wie folgt definiert:

Maßnahmen:

• Level 1: Warnung bei Schwellenwertverletzung.
• Level 2: Wenn anhaltend, Erwägung des Aufrufs von setOpenInterestCaps, um die OI-Obergrenze zu reduzieren.

0x4 Fazit

Die Kernbotschaft von HIP-3 ist einfach. Es verwandelt Marktlistungen von einem diskretionären Prozess, der von wenigen kontrolliert wird, in eine protokollbasierte Funktion, die jeder qualifizierte Entwickler aufrufen kann, sobald die Anforderungen erfüllt sind. Durch Staking können Entwickler ihre eigenen Perp-DEXs auf HyperCore starten, eine anfängliche Anzahl von Märkten kostenlos listen und zusätzliche Slots durch Auktionen erwerben. Dies verlagert die Marktexpansion von der Wartezeit auf Genehmigung zur regelbasierten, erlaubnisfreien Skalierung.

Ebenso klar ist, dass HIP-3 das Risiko nicht eliminiert. Es positioniert und gestaltet es neu. Verantwortlichkeiten, die zuvor von plattformweiten Risikokontrollen übernommen wurden, werden nun größtenteils von Entwicklern durch ihre Inputs und operative Qualität getragen. Dies umfasst die Orakelpreisbildung und Aktualisierungsfrequenz über setOracle, die Auswahl und Einschränkungen von markPx, gestaffelte Hebelgestaltung durch Margin-Tabellen, Preisbereiche außerhalb der Marktzeiten für Nicht-24/7-Vermögenswerte und leistungsstarke Steuerungen wie haltTrading, die Verluste eindämmen oder verstärken können. Unter dünner Liquidität kann Fehlkonfiguration oder operativer Fehler zu Liquidationskaskaden, Lückenverlusten und schließlich ADL-Ereignissen eskalieren. Die Frage ist nicht mehr ''Kann ein Markt gelistet werden?'', sondern eher ''Kann er nach der Listung stabil bleiben?''

Auf Protokollebene begegnet Hyperliquid dieser Umverteilung von Risiken, indem es Berechtigungen in rechenschaftspflichtige Berechtigungen umwandelt. Staking, kombiniert mit Validatoren-gesteuertem Slashing, schafft klare wirtschaftliche Konsequenzen für Fehlbedienungen durch Entwickler. Beschränkungen bei Preisgestaltung und Hebelwirkung, einschließlich Klemmmechanismen, Aktualisierungsintervallen, Volatilitätsgrenzen und isolierten Margin-Anforderungen, zielen darauf ab, die gefährlichsten Extremrisiken innerhalb beherrschbarer Grenzen zu halten. In diesem Rahmen wird das Wertversprechen von HIP-3 deutlich: Skalierung durch Offenheit, Sicherheit durch Einschränkungen und langfristige Nachhaltigkeit durch Überprüfbarkeit und Rechenschaftspflicht.

HIP-3 macht Listungen nicht freier. Es macht sie standardisierter, bereitstellbarer, betriebsfähiger und slashable. Ob diese Standardisierung in großem Maßstab funktionieren kann, hängt letztendlich von der Qualität des Orakeldesigns, den Hebel- und Risikoparametern sowie dem Laufzeit-Monitoring in der realen Welt ab. Wenn Sie Regeln für den Marktzugang, Parameter-Vorlagen, Alarmierungssysteme oder Notfall-Workflows auf Basis von HIP-3 entwerfen oder eine Prüfung und kontinuierliche Sicherheitsunterstützung benötigen, können Sie sich gerne unter [email protected] an BlockSec wenden.

Referenz

[1] https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-3-builder-deployed-perpetuals

[2] https://hyperliquid.gitbook.io/hyperliquid-docs

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei helfen, Code-Audits (einschließlich Smart Contracts, Blockchains und Wallets) durchzuführen, Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zu verfolgen und AML/CFT-Verpflichtungen während des gesamten Lebenszyklus von Protokollen und Plattformen zu erfüllen.

BlockSec hat mehrere Blockchain-Sicherheitsarbeiten auf angesehenen Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Milliarden von Kryptowährungen gesichert.

• Offizielle Website: https://blocksec.com/

• Offizielles Twitter-Konto: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Anfrage senden

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance