Hyperliquid Improvement Proposal 3 (HIP-3) [1] führt eine grundlegende Änderung der Art und Weise ein, wie Perpetual-Märkte auf Hyperliquid erstellt und skaliert werden. Indem der Prozess der Marktaufnahme für Drittanbieter-Builder geöffnet wird, verlagert HIP-3 die Marktaufnahme von einer diskretionären, plattformgesteuerten Aktion zu einer schnittstellenbasierten Protokollfunktion, für die eine Genehmigung erforderlich ist.

Seit seiner Einführung im Mainnet haben von Buildern 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 materiell verbessern kann. Dieser Wandel dezentralisiert jedoch nicht nur die Macht, sondern weist auch die Verantwortung neu zu. Risiken, die zuvor von zentralisierten Plattformbetrieben übernommen oder gemildert wurden, werden nun direkt von den Buildern getragen.

Infolgedessen ist die Kernfrage unter HIP-3 nicht mehr, ob ein Markt gestartet werden kann, sondern ob er über die Zeit sicher betrieben werden kann. Dieser Bericht analysiert HIP-3 aus der Perspektive der Builder und konzentriert sich darauf, wie Märkte definiert und betrieben werden, welche Risiken Builder eingehen und wie diese Risiken, insbesondere oraclebezogene Risiken, gemindert werden können.

0x1 Hintergrund

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

• HyperCore, einer speziell entwickelten Layer-1-Blockchain, die für den Derivatehandel optimiert ist und ein einheitliches Matching, eine einheitliche Liquidation und eine einheitliche Abrechnung bietet.
• HyperEVM, einer EVM-kompatiblen Anwendungsschicht, die erweiterbare Logik und Builder-Interaktion ermöglicht.

Trotz dieser Architektur ähnelt der Listing-Prozess für Hyperliquids native Perpetual-Märkte, auch als Validator-betriebene Perps bezeichnet, immer noch einem traditionellen CEX-Ansatz. Die Listung neuer Kontrakte wird weitgehend vom Kernteam vorangetrieben, während Delistings durch Validator-Abstimmungen bestimmt werden.

HIP-3 wurde eingeführt, um diesen Listing-Prozess zu dezentralisieren, indem von Buildern bereitgestellte Perpetual-Märkte ermöglicht werden. Es formalisiert die Trennung zwischen Marktdesign und protokollgesteuerter Ausführung, indem es Buildern 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.

0x2 Verantwortlichkeiten der Builder: Definition und Betrieb

Unter HIP-3 erstrecken sich die Verantwortlichkeiten eines Builders über zwei Phasen: Marktdesign und Marktbetrieb. Wir skizzieren zunächst den End-to-End-Launch-Workflow und heben dann die kritischen Fokusbereiche hervor, die darüber entscheiden, ob ein Markt in Produktion stabil bleibt.

0x2.1 Launch-Markt-Flow: Definition und Betrieb

Unter HIP-3 ist die Markteinführung keine einzelne Aktion. Wie im folgenden vollständigen Markteinführungs-Workflow veranschaulicht, handelt es sich um einen Prozess, der zwei unterschiedliche Phasen umfasst: Marktdesign (Schritte 1 bis 4) und Marktbetrieb (Schritt 5).

Während der Phase des Marktdesigns muss ein Builder zunächst 500.000 HYPE im Mainnet staken. Nach Erfüllung der Staking-Anforderung kann der Builder einen Perpetual-DEX bereitstellen, der eine unabhängige Handelsdomäne mit eigenem Marginsystem, Orderbüchern und vom Deployer gesteuerten Einstellungen bildet. Auf DEX-Ebene wählt der Builder eine Quote-Asset aus, die als Sicherheit für alle Märkte auf diesem DEX verwendet wird. Das ausgewählte Quote-Asset muss seinen erlaubnisfreien Status behalten, da der Verlust dieses Status den entsprechenden DEX deaktiviert. Anschließend definiert der Builder Kernmarktparameter, einschließlich Oracle-Spezifikationen, Vertragsparameter wie Symbol und Hebelgrenzen sowie Margin-Tabellen. Die ersten drei Märkte können direkt bereitgestellt werden, während für zusätzliche Märkte Slots über eine niederländische Auktion erworben werden 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 Builder in die Phase des Marktbetriebs ein. Diese Phase umfasst die kontinuierliche Aktualisierung von Oracle-Preisen über die setOracle-Schnittstelle, die Pflege von Hebel- und Margin-Konfigurationen, die Überwachung von Liquidität und offenem Interesse sowie die Ausführung von Notfallmaßnahmen wie dem Aussetzen des Handels und der Abrechnung von Positionen, wenn nötig.

In der Praxis treten die meisten schwerwiegenden Fehler unter HIP-3 nicht während der Marktdesignphase auf, sondern während des langfristigen Betriebs unter Stressbedingungen. Wichtig ist, dass die Verantwortung des Builders nicht unmittelbar nach dem Aussetzen von Märkten endet. Das Entstaken ist erst möglich, nachdem alle Märkte abgerechnet sind, und der Stake bleibt während der obligatorischen Entstake-Periode einstichbar.

0x2.2 Kritische Fokusbereiche: Preisgestaltung und Solvenz

Builder stehen über die Marktdesign- und Marktbetriebsphasen hinweg zwei gekoppelte Fokusbereiche gegenüber: Oracle-Konfiguration und Preisbildung sowie Markt-Solvenz unter Stress. Diese beiden Bereiche sind eng miteinander verknüpft, da Preisgestaltungsfehler durch protokollweite Risikokontrollen schnell in Solvenzstress ausarten können.

0x2.2.1 Oracle-Konfiguration und Preisbildung

Hyperliquid definiert zwei Preise:

• Oracle-Preis: ein gewichteter Median der Spot-Mid-Preise von großen externen Börsen, der unabhängig von Hyperliquids internen Marktdaten ist und hauptsächlich zur Verankerung der Finanzierung dient.
• Marktpreis: ein interner Risikopreis, der aus mehreren Eingaben abgeleitet wird, einschließlich des Oracle-Preises und lokaler Marktdaten, der für unrealisierte PnL (Gewinn und Verlust) und Risikokontrollen verwendet wird.

Kurz gesagt, der Oracle-Preis 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 Oracle-Preis und Marktpreis nicht, aber der Berechnungsmechanismus ändert sich:

1. Eingaben für setOracle
   • oraclePx (erforderlich): gleiche Definition wie in HyperCore.
   • markPx (optional): 0–2 extern berechnete Marktpreis-Kandidaten.
   • externalPerpPx (erforderlich): ein Referenzwert zur Verhinderung plötzlicher Marktpreisabweichungen.

Builder stellen typischerweise Relayer-Knoten bereit, um Preise einzuspeisen: oraclePx wird aus mehreren externen Quellen berechnet, markPx wird vom Relayer mit einem benutzerdefinierten Algorithmus berechnet, und externalPerpPx vom gewichteten Median der Perp-Mid-Preise von mehreren CEXs.

2. Tatsächlicher Marktpreis
   • Lokalen Markt berechnen: median(best bid, best ask, last trade).
   • Lokalen Markt und markPx (0–2 Werte) zusammennehmen und den Median ermitteln, um den neuen Marktpreis zu erhalten.
3. setOracle-Beschränkungen
   • Aktualisierungsfrequenz: mindestens 2,5 s zwischen den Aufrufen; wenn markPx 10 s lang nicht aktualisiert wird, greift er auf den lokalen Marktpreis zurück.
   • Amplitudenbegrenzungen: markPx kann sich pro Aktualisierung um maximal ±1 % ändern; alle Preise werden innerhalb des 10-fachen des Startpreises des Tages begrenzt.

Warum der Anlagentyp für die Preisgestaltung in HIP-3 wichtig ist

Unter HIP-3 können Perpetual-Märkte für jede Art von Anlage gestartet werden. Diese Anlagen lassen sich im Allgemeinen in 24/7-Anlagen (rund um die Uhr handelbar) und Nicht-24/7-Anlagen (nur während bestimmter Marktöffnungszeiten handelbar, ohne Spot-Handel außerhalb dieser Zeiten) unterteilen. Der Unterschied bei den Handelszeiten bestimmt grundlegend, wie Preise bezogen und beibehalten werden.

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

Für Nicht-24/7-Anlagen (z. B. Aktien) sind ausreichende Liquidität und zuverlässige externe Marktpreise nur während der offiziellen Handelszeiten verfügbar. Um solche Anlagen in HIP-3 kontinuierlich handeln zu können, muss während der Nicht-Handelszeiten ein separater Preisbildungsmechanismus verwendet werden.

Nehmen Sie die Aktien-Perp-Märkte auf trade.xyz als Beispiel:

1. Während der Marktöffnungszeiten werden stabile Oracle-Preise von externen Oracle-Diensten wie Pyth bereitgestellt.
2. Während der Nicht-Handelszeiten 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 begrenzt, dass er innerhalb von ±1 / max_leverage des letzten Schlusskurses schwankt (z. B. Tesla: 10-fache Hebelwirkung → ±10 %).

0x2.2.2 Markt-Solvenz unter Stress

Hyperliquid wendet zwei Mechanismen an, Liquidation und ADL (Auto-Deleveraging), um die Markt-Solvenz aufrechtzuerhalten. Unter HIP-3 folgen sowohl die Liquidation als auch ADL weitgehend dem Design von HyperCore. Der Hauptunterschied ist eine protokollweite Beschränkung: HLP (Hyperliquidity Provider), der als Protokolltresor dient, kann keine riskanten Positionen in HIP-3-Märkten übernehmen. Infolgedessen fehlt der Zwischen-Tresorpuffer, der Positionen zwischen Marktliquidation und ADL in HyperCore aufnehmen kann, in HIP-3.

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

1. Liquidation

Die Liquidation wird ausgelöst, wenn der Positionsnettowert (isolierter Positionsneuwert) nicht ausreicht, um die Mindestmarginanforderung 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 Mindestmarginquote

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

Bei der Konfiguration von Margin-Stufen wird der mmr der Stufe angewendet, die dem notariellen Wert der Position zum Liquidationspreis entspricht.

• margin_available (isolated): isolated_margin - maintenance_margin_required

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

Bei unzureichender Orderbuchtiefe oder Preislücken kann der tatsächliche durchschnittliche Ausführungspreis jedoch deutlich schlechter sein als der Marktpreis, was zu einem "Liquidations-Defizit" führt.

Isolierter Positionsneuwert bezieht sich auf den Nettowert einer isolierten Position zum aktuellen Marktpreis, der die dieser Position zugewiesene Marge nach Berücksichtigung unrealisierter PnL darstellt.

ADL (Auto-Deleveraging)

In extremen Szenarien fungiert der ADL-Mechanismus (Auto-Deleveraging) als letzte Absicherung.

ADL wird ausgelöst, wenn der isolierte Positionsneuwert negativ wird. Das System sortiert profitable Kontrahenten nach PnL und Hebelwirkung und reduziert oder schließt dann zwangsweise diese Positionen zum vorherigen Marktpreis (dem zuvor aufgezeichneten Marktpreis vor Auslösung von ADL). Durch die Verwendung der Gewinne der gewinnenden Seite, um das Defizit auszugleichen, bleibt das Protokoll zahlungsfähig und trägt keine uneinbringlichen Schulden.

Der Sortierindex wird wie folgt berechnet:

Hier bezieht sich notional_position auf den absoluten Marktwert der Position zum vorherrschenden Marktpreis, berechnet als |position_size| × mark_price. account_value bezeichnet das Eigenkapital des Kontos zum Marktpreis, d. h. den Wert der Sicherheiten plus unrealisierte PnL.

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 Liquidation-Market-Orders das Buch treffen, beträgt der tatsächliche durchschnittliche Ausführungspreis = 2.910 (−3 % im Verhältnis zu 3.000).
• Verluste auf Long-Positionen werden zu 2.910 abgerechnet, wodurch der isolierte Positionsneuwert unter Null fallen und ein Defizit entstehen kann, das ADL auslöst.
• ADL wählt dann entgegengesetzte (profitable Short-) Positionen aus und reduziert/schließt diese zwangsweise zum vorherigen Marktpreis = 3.000, wodurch das Defizit in "die gewinnende Seite verdient passiv weniger" verschoben wird.

0x3 Risiko-Landschaft für Builder

Unter HIP-3 ist Risiko für Builder nicht mehr abstrakt oder rein theoretisch. Durch Staking und von Validatoren gesteuertes Slashing können operative Ausfälle und Fehlkonfigurationen direkt in wirtschaftliche Strafen umgewandelt werden. Daher wird das Verständnis, wie Slashing ausgelöst wird und welche Arten von Builder-Verhalten dazu führen können, zentral für das Risikomodell des Builders. Folglich erklärt dieser Abschnitt zunächst den Slashing-Mechanismus als Verantwortlichkeitsrahmen und analysiert dann die beiden Hauptrisikoquellen für Builder unter HIP-3.

0x3.1 Slashing-Mechanismus und Verantwortlichkeit

HIP-3 erzwingt die Verantwortlichkeit durch Staking und von Validatoren gesteuertes Slashing. Slashing basiert ausschließlich auf Ergebnissen. Hyperliquid unterscheidet nicht zwischen bösartigem Verhalten, operativen Fehlern, Kompromittierung privater Schlüssel oder dem Ausfall von Drittanbieter-Abhängigkeiten.

Staking-Anforderung: Im Mainnet müssen Builder 500.000 HYPE gestaket halten. Selbst wenn ein Builder alle seine Märkte aussetzt, muss er diese 30 Tage lang weiter unterhalten (die Verantwortung verschwindet nicht sofort, weil der Handel eingestellt ist).

Wenn die Aktionen eines Builders 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 hin zu einem vollständigen Stake-Burn reichen. Dieses Design macht Builder wirtschaftlich für das vollständige Laufzeitverhalten ihrer Märkte verantwortlich.

Der Slash-Prozentsatz wird durch Validator-Abstimmung mit Referenzobergrenzen bestimmt:

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

Gelashte Token werden verbrannt, nicht umverteilt.

Unter HIP-3 stammen die Risiken für Builder hauptsächlich aus zwei Quellen: interne Parameter-Fehlkonfiguration und externe Oracle-Abhängigkeiten. Die folgenden Abschnitte untersuchen diese beiden Quellen im Detail und erklären, wie sie zu Slashing-Ergebnissen führen können.

0x3.2 Risiken durch interne Parameter-Fehlkonfiguration

Fehlkonfigurationsrisiken umfassen übermäßige Hebelwirkung in 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 Notfallsteuerungen wie dem Aussetzen des Handels.

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

1. setOracle

Oracle-Preise stammen typischerweise von den Relayer-Servern des Builders, was ein Zentralisierungsrisiko mit sich bringt. Wenn der private Schlüssel leckt oder der Relayer einer DDoS-Attacke ausgesetzt ist, kann der Oracle-Preis des Marktes böswillig manipuliert werden oder lange Zeit abweichen.

2. haltTrading

Der Builder kann alle Orders 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 zu einem Marktpreis zu schließen, kann dies direkt den unrealisierten Gewinn des Angreifers realisieren (wo der Angreifer sonst Schwierigkeiten hätte, genügend gegnerische Orders zu finden) und auch zu uneinbringlichen Schulden führen.

3. setMarginTableIds & InsertMarginTable

• InsertMarginTable: definiert eine neue Margin-Tabelle, die Margin-Anforderungen und maximale Hebelwirkung für eine Anlageklasse festlegt.
• setMarginTableIds: bindet einen Markt an eine angegebene marginTableId.

Bei einem Markt mit geringer Liquidität / unzureichendem Market-Making erhöht die zu hohe Einstellung der maximalen Hebelwirkung die Wahrscheinlichkeit, ADL auszulösen.

Das plötzliche Umschalten von marginTableId entspricht der Änderung der Mindestmarginquote von Benutzerpositionen, 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-Margin. Innerhalb eines DEX, der sowohl Märkte mit hoher als auch mit geringer Liquidität beherbergt, kann Cross-Margin ein Risiko für Kontamination ermöglichen, bei dem Verluste in illiquiden Märkten auf liquide Märkte übergreifen. Daher wird davon abgeraten, dass Builder Cross-Margin einführen, bis das offizielle Team eine ausgereifte Lösung anbietet.

0x3.3 Risiken aus externen Oracle-Abhängigkeiten

Für 24/7-Anlagen liegen die Hauptrisiken in der Genauigkeit und Stabilität externer Oracle-Dienste sowie in den zuvor diskutierten Zentralisierungsrisiken von Relayer-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-Anlagen ist die Risikofläche deutlich breiter und konzentriert sich hauptsächlich darauf, wie Oracle-Preise während der Nicht-Handelszeiten bezogen oder berechnet werden.

Nehmen wir trade.xyz als Beispiel: Während der Nicht-Handelszeiten werden die Preise aus einer Kombination des zuletzt verfügbaren externen Oracle-Preises 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 ihre Kurse –, während keine externen Oracle-Preise zur Verankerung zur Verfügung stehen. Obwohl eine harte Obergrenze für Preisbewegungen festgelegt ist (z. B. 1 / max_leverage), kann diese Beschränkung für gering volatile Anlagen 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 nachbildet – manipuliert. Ein Angreifer shortete 398 XYZ100 (etwa 10 Millionen US-Dollar USDC an notariellem Engagement) und verursachte eine starke Preiskorrektur. Eine große Anzahl von Long-Positionen wurde liquidiert, und die Liquidationen selbst drückten die Preise weiter nach unten, was letztendlich zu Long-Seite-Liquidationen von etwa 13 Millionen US-Dollar USDC führte.

this is probably the first such move under the ‘growth mode’ regime on the weekend. Someone slammed the market, dropping the price of XYZ100 by more than 3% in a minute and liquidating roughly $3M worth of positions pic.twitter.com/XttBHfTB0D

— bart.hl (equity perps era) (@bartdothl) December 14, 2025

Andererseits sind während der Nicht-Handelszeiten die fehlenden kontinuierlichen und extern verankerten Oracle-Preise gezwungen, dass sich Märkte auf ein begrenztes internes Preisband stützen, das durch den "letzten externen Preis + internes Orderbuch" gebildet wird (z. B. trade.xyz begrenzt die maximale Schwankung auf 1/max_leverage).

Das kritischste Risiko tritt beim Übergang zur Wiedereröffnung des Marktes auf. Externe Märkte können plötzlich einen klaren und maßgeblichen Referenzpreis liefern. Wenn dieser Preis eine erhebliche Lücke im Vergleich zur internen Preisgestaltung außerhalb der Geschäftszeiten aufweist, steht das System vor zwei ungünstigen Pfaden: Entweder bleiben die Preise eingefroren, was zu einer erheblichen Divergenz zwischen dem externen fairen Wert und den handelbaren Preisen führt, oder das System wechselt schnell zurück zur externen Verankerung und löst eine abrupte Neubewertung aus. Beide Szenarien können den Liquidationsdruck in einem kurzen Zeitfenster konzentrieren und in extremen Fällen zu einem Anstieg von ADL-Ereignissen führen.

0x4 Risikokontrollen für Builder

Disziplin bei der Konfiguration allein kann Risiken nicht beseitigen. Die effektivsten Minderungsstrategien konzentrieren sich auf die Reduzierung der Abhängigkeit von Oracle-Ausfällen.

0x4.1 Auswahl stabiler Oracles

Für nicht 24/7 gehandelte Vermögenswerte wie Aktien liegt die Hauptaufgabe darin, die Preisgestaltung während der Nicht-Handelszeiten sicherzustellen. Während dieser Zeit sind stabile und extern verankerte Preisreferenzen knapp, was Märkte anfälliger für Manipulationen oder endogenes Abdriften bei dünner Liquidität macht.

Derzeit gibt es in der Branche hauptsächlich zwei Ansätze:

• 1. Aussetzen von Oracle-Aktualisierungen und Beschränken des Handels während der Nicht-Handelszeiten. Zum Beispiel akzeptiert das Lighter-Protokoll nur Reduzierungs-Orders, wenn der zugrunde liegende Markt geschlossen ist. Protokolle wie Ostium reduzieren die maximale Hebelwirkung während der Nicht-Handelszeiten weiter und liquidieren zwangsweise Positionen, die die neuen Grenzen überschreiten.
• 2. Übernahme eines "internen Preisbildungsmechanismus", wie bei trade.xyz gesehen, bei dem das Protokoll während der Nicht-Handelszeiten weiterläuft, indem es sich auf interne Liquidität und Preisalgorithmen verlässt, wenn externe Daten nicht verfügbar sind.

Diese beiden Ansätze spiegeln einen fundamentalen Kompromiss zwischen Sicherheit und Benutzererfahrung wider. Der erste Ansatz priorisiert strenge Risikokontrollen, verschlechtert jedoch die Handelskontinuität und die Benutzererfahrung erheblich. Der zweite bewahrt den kontinuierlichen Handel, erhöht jedoch aufgrund des Mangels an externen Referenzen das Risiko, dass interne Preise vom fundamentalen Wert des Vermögenswerts abweichen.

Während der Nicht-Handelszeiten sollte die Protokollpreisgestaltung vermeiden, vollständig in einen rein internen Preis abzugleiten. Stattdessen kann die Einführung von externen Referenzankern die Divergenz und Lückenrisiken reduzieren. Mögliche Referenzen umfassen:

• Blue Ocean ATS. Als Handelsplatz außerhalb der Geschäftszeiten/über Nacht kann er während der Schließungen einen gewissen Grad an kontinuierlicher Preisreferenz bieten (zeitnaher als "letzter Schlusskurs"), um zur Erstellung von Oracle-Preisen während der Schließungsperiode beizutragen oder als Überwachungsbasis für Divergenzen zu dienen.
• IG Weekend CFD-Kurse. Wochenend-CFD-Kurse können ein alternatives Preissignal liefern, das "Erwartungen des Wochenendmarktes" widerspiegelt, geeignet als externer Anker oder zur Vergleichsüberwachung während der Schließungen, um die wahrscheinliche Richtung und das Ausmaß einer "Eröffnungs-Gap" im Voraus zu erkennen.

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

0x4.2 Preisüberprüfung

Unter HIP-3 stammen Oracle-Preise von von Buildern betriebenen Relayer-Servern, was Bedenken hinsichtlich der Zentralisierung aufwirft. Um dies zu mildern, werden Builder ermutigt, ein Preisüberprüfungs-Framework zu implementieren, das es jedem Benutzer oder jeder Institution ermöglicht, die Korrektheit und Fairness der Preise außerhalb der Kette zu überprüfen – ähnlich wie RedStone, das Preise zusammen mit Datenquellen und kryptografischen Beweisen bündelt.

1. Datentransparenz

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

2. Preisbeweise

Für jeden setOracle-Aufruf generieren Sie einen entsprechenden Beweis, der enthält:

• Eingaben: Rohe (oder normalisierte) Antworten von jeder Datenquelle zum Abtastzeitpunkt.
• Berechnung: Reproduzierbare Zwischenwerte in jedem Berechnungsschritt.
• Ausgaben: Der auf der Kette übermittelte Oracle-Preis.

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

3. On-Chain-Verpflichtungen

• Pflegen Sie eine sequentielle Liste von proofHash-Einträgen in einem Merkle-Baum.
• Veröffentlichen Sie periodisch (z. B. stündlich oder täglich) den MerkleRoot auf der Kette.

4. Verifizierung

• Stellen Sie Open-Source-Tools oder eine Webseite bereit, auf der Benutzer einen Zeitbereich oder einen setOracle-Transaktions-Hash eingeben können.
• Verifizieren Sie Signaturen, Zeitstempel und MerkleRoot usw.
• Berechnen Sie die Oracle-Preise mit dem öffentlichen Algorithmus zum Vergleich neu.

0x4.3 Risikoüberwachung

Die Preisüberprüfung macht setOracle neu berechenbar und prüfbar, wodurch festgestellt wird, ob Preis-Feeds vertrauenswürdig sind. Sie kann jedoch nicht vor einer Verschlechterung des Live-Marktes schützen. Feed-Unterbrechungen, Preisabweichungen und Liquiditätsverschlechterung können – in Kombination mit hohem Open Interest (OI) – 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 behandelt werden, um das Risiko innerhalb beherrschbarer Grenzen zu halten.

Um die Überwachung handlungsfähig und nicht fragmentiert zu gestalten, organisieren wir Signale in drei Ebenen, die jeweils einem unterschiedlichen Fehlermodus und einer unterschiedlichen Reaktionspriorität zugeordnet sind.

• Preis-seitige Überwachung erkennt Oracle-Feed-Ausfälle und Depegging, die Risikokontrollen an der Quelle ungültig machen können, daher wird sie als höchste Priorität behandelt und typischerweise über Relayer-Failover, Open Interest-Obergrenzen und Hebelreduktionen adressiert.
• Orderbuch-seitige Überwachung erfasst Liquiditätsabzug und gefälschte Tiefe, die das Liquidations-Slippage und das Defizitrisiko verstärken, daher konzentrieren sich Eingriffe auf die Begrenzung der inkrementellen Exposition und die Erzwingung von De-Leveraging, wenn die Fragilität zunimmt.
• Positions-seitige Überwachung verfolgt den schnellen Aufbau von Open Interest und die einseitige Konzentration, die Märkte anfällig für Kaskaden machen, und ist im Allgemeinen von geringerer Priorität als Preis- und Liquiditätssignale und dient hauptsächlich als Frühwarnsystem, das engere Obergrenzen und erhöhte Warnmeldungen informiert.

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

0x4.3.1 Preis-seitige Überwachung

1. Oracle-Feed-Ausfall

Metriken:

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

Schwellenwerte:

• Stufe 1: ( ∆t > 5 s ) — Relayer-Prozess kann blockiert oder gestoppt sein
• Stufe 2: ( ∆t > 15 s ) — On-Chain-Preise können stark depeggt und zunehmend marktgesteuert sein

Aktionen:

• Stufe 1: Führen Sie Relayer-Gesundheitsprüfungen durch, wechseln Sie zu Backup-Relayern und geben Sie Warnmeldungen mit Gesundheitsdiagnosen aus.
• Stufe 2: Rufen Sie setOpenInterestCaps auf, um die OI-Obergrenze zu reduzieren.

2. Preis-Depegging

Metriken:

• Signal A (d1): Abweichung zwischen Marktpreis und Oracle-Preis.

• Signal B (d2): Abweichung zwischen Orderbuch-Mid-Preis und Oracle-Preis.

• Signal C (d3): Abweichung zwischen Marktpreis und Mid-Preis.

• Signal D (ext_diff): Abweichung zwischen Oracle-Preis und externem Referenzpreis.

Schwellenwertlogik:

• Stufe 1: mindestens 2 von A, B, D überschreiten Schwellenwerte.
• Stufe 2: mindestens 3 von A, B, C, D überschreiten Schwellenwerte für X Sekunden.

Aktionen:

• Stufe 1: OI-Obergrenze über setOpenInterestCaps reduzieren.
• Stufe 2: Margin-Tabellen schrittweise aktualisieren, um die maximale Hebelwirkung nach Stufen zu reduzieren, und Clamp-Mechanismen bei Relayer aktivieren.
• Stufe 3: Anhaltende Warnungen unter Stufe 2 Bedingungen. Der Builder prüft dann, ob haltTrading aufgerufen werden soll.

0x4.3.2 Orderbuch-seitige Überwachung

1. Liquiditätsabzug

Metriken:

• depth_band(±x%): Orderbuch-Liquidität innerhalb von ±x % des Mid-Preises.
• spread = bestAsk - bestBid: Preisspanne zur Messung der Spread-Erweiterung.
• aggressiveVolume_Δt: Taker-Volumen innerhalb von Δt (aggregiert nach Handelsseite).
• impact_ratio: Indikator für Marktfragilität (höhere Werte deuten auf größere Anfälligkeit für Preisbeeinflussung hin).

Risikomuster:

• depth_band nimmt ab, während spread und impact_ratio zunehmen.

Aktionen:

• Stufe 1: OI cap = current OI über setOpenInterestCaps setzen, um inkrementelle Positionen zu begrenzen.
• Stufe 2: De-Leveraging erzwingen über setMarginTableIds, während hoch gehebelte, hochriskante Positionen liquidiert werden.

2. Gefälschte Liquidität

Risikomuster:

• Plötzliche Spitzen im depth_band, gefolgt von einem Zusammenbruch in einem kurzen Zeitfenster.

Aktionen:

• Stufe 1: Rufen Sie setOpenInterestCaps auf, um OI cap = current OI zu setzen.
• Stufe 2: Wenn kombiniert mit starkem Depegging, erwägen Sie das Aussetzen des Marktes.

0x4.3.3 Positions-seitige Überwachung

Die positions-seitige Überwachung versucht nicht, die Preisrichtung vorherzusagen. Stattdessen identifiziert sie Übergänge von ausgeglichener Handelsaktivität zu einseitiger Positionsanhäufung. Wenn sich OI schnell anhäuft, Positionen stark konzentriert sind und die PnL der Mehrheitsseite extreme Werte erreicht, können selbst geringfügige exogene Schocks zu Liquidationskaskaden oder ADL-Ereignissen führen.

Daher haben positions-seitige Aktionen typischerweise eine geringere Priorität als preis- und orderbuch-seitige Eingriffe.

1. Überschüssiges kurzfristiges OI

Metriken:

• OI_notional: Open Interest Notional.
• Volume_24h_notional: 24-Stunden-Notional-Volumen.

Ein sich schnell erhöhendes Verhältnis zeigt eine Verschiebung von aktivem Turnover zu spekulativer Positionsbildung an und geht oft scharfer Volatilität voraus.

Aktionen:

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

2. Mehrheits-Seite PnL

Mehrheits-Seite bezieht sich auf die Seite (Long oder Short) mit mehr Positionsinhabern innerhalb des Beobachtungsfensters.

Metriken:

• avgEntry_major: Durchschnittlicher Einstiegspreis der Mehrheitsseite-Positionen.
• size_major: Gesamtpositionsgröße der Mehrheitsseite.
• equity_major: Gesamteigenkapital der Mehrheitsseite.

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

Aktionen:

• Stufe 1: Warnung bei Überschreitung von Schwellenwerten.
• Stufe 2: Wenn dies anhält, erwägen Sie den Aufruf von setOpenInterestCaps, um die OI-Obergrenze zu reduzieren.

0x5 Schlussfolgerung

Die Kernbotschaft von HIP-3 ist einfach. Es wandelt Markteinführungen von einem diskretionären Prozess, der von wenigen kontrolliert wird, in eine protokollbasierte Funktion, die jeder qualifizierte Builder aufrufen kann, sobald die Anforderungen erfüllt sind. Durch Staking können Builder ihre eigenen Perp-DEXs auf HyperCore starten, eine anfängliche Reihe von Märkten kostenlos auflisten und zusätzliche Slots über Auktionen erwerben. Dies verschiebt die Marktexpansion von "auf Genehmigung warten" zu regelbasierter, erlaubnisfreier Skalierung.

Ebenso klar ist, dass HIP-3 Risiken nicht eliminiert. Es positioniert und gestaltet sie neu. Verantwortlichkeiten, die zuvor von plattformweiten Risikokontrollen übernommen wurden, werden nun größtenteils von den Buildern durch ihre Eingaben und operative Qualität getragen. Dazu gehören Oracle-Preisgestaltung und Aktualisierungstaktung über setOracle, die Auswahl und Einschränkungen von markPx, gestaffeltes Hebeldesign über Margin-Tabellen, Preise außerhalb der Geschäftszeiten für Nicht-24/7-Assets und leistungsstarke Steuerungen wie haltTrading, die Verluste eindämmen oder verstärken können. Bei dünner Liquidität kann Fehlkonfiguration oder operativer Ausfall zu Liquidationskaskaden, Gap-Verlusten und schließlich ADL-Ereignissen führen. Die Frage ist nicht mehr "Kann ein Markt gelistet werden?", sondern vielmehr "Kann er nach der Listung stabil bleiben?"

Auf Protokollebene adressiert Hyperliquid diese Umverteilung von Risiken, indem es Berechtigungen in rechenschaftspflichtige Berechtigungen umwandelt. Staking, kombiniert mit von Validatoren gesteuertem Slashing, schafft klare wirtschaftliche Konsequenzen für Fehloperationen von Buildern. Beschränkungen bei der Preisgestaltung und Hebelwirkung, einschließlich Clamps, Aktualisierungsintervallen, Volatilitätsgrenzen und isolierten Margin-Anforderungen, zielen darauf ab, die gefährlichsten Extremrisiken in beherrschbare Grenzen zu bringen. 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 Listings nicht freier. Es macht sie standardisierter, bereitstellbarer, bedienbarer und slashable. Ob diese Standardisierung in großem Maßstab funktionieren kann, hängt letztendlich von der realen Qualität des Oracle-Designs, der Hebel- und Risikoparameter sowie der Laufzeitüberwachung ab. Wenn Sie Regeln für den Marktzugang, Parameter-Vorlagen, Alarmierungssysteme oder Notfall-Workflows über HIP-3 entwerfen oder wenn Sie Auditing und kontinuierlichen Sicherheits-Support benötigen, wenden Sie sich gerne an BlockSec unter [email protected].

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 bei Code-Audits (einschließlich Smart Contracts, Blockchain und Wallets), Echtzeit-Angriffsabfangung, Vorfallanalysen, Rückverfolgung illegaler Gelder und Erfüllung von AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg unterstützen.

BlockSec hat mehrere Blockchain-Sicherheitsarbeiten auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks zur Rettung von über 20 Millionen US-Dollar blockiert und Milliarden von Kryptowährungen gesichert.

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

• Offizieller Twitter-Account: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance