Architektur
Hypercall verwendet ein hybrides Ausführungsmodell: Off-Chain-Matching für Geschwindigkeit, mit On-Chain-Settlement und Kontoverwaltung für Sicherheit.
Vertrauensgrenzen
Off-Chain (Hypercall-Backend)
Zuständigkeiten:
- Order-Matching und Ausführung
- Orderbuch-Verwaltung
- Pre-Trade-Margin-Prüfungen
- Liquidations-Orchestrierung
- Marktdaten und Preisbildung
- WebSocket-Streams
Vertrauensannahme: Nutzer vertrauen darauf, dass das Hypercall-Backend:
- Orders fair matcht (Preis-Zeit-Priorität)
- Margin-Prüfungen korrekt durchsetzt
- Konten überwacht und bei Bedarf Liquidationen auslöst
- Genaue Marktdaten bereitstellt
Einschränkungen: Off-Chain-Operationen sind in der Mainnet Alpha nicht vollständig kryptografisch verifizierbar. Nutzer müssen dem Backend-Betreiber beim Matching, bei der Marktdatenaufnahme, bei Margin-Prüfungen und bei der Ausgabe von RSM-Befehlen vertrauen.
Weiterer Weg: Hypercall arbeitet auf die Dezentralisierung des RSM und stärkere Trustlessness-Garantien hin. Die Roadmap wird festlegen, wie State Commitments, Signer-Rollen, Streitbeilegungswege und Betreiber-Kontrollen im Laufe der Zeit besser verifizierbar werden. Die Mainnet Alpha ist die eingeschränkte erste Phase, nicht das endgültige Vertrauensmodell.
On-Chain (Smart Contracts)
Zuständigkeiten:
- Kontoeigentum und Manager-Kontrolle
- Einzahlungen und Auszahlungen
- Liquidationsauktionen (Positionsübertragung)
- RSM-Befehle (Risikomanagement-Operationen)
- Veröffentlichung von Settlement-Preisen
- Hyperliquid-Integration (Perp-Orders über ActionCaster)
Vertrauensannahme: On-Chain-Operationen sind kryptografisch verifizierbar. Nutzer können Contract-Code und -Zustand überprüfen.
Sicherheit: Das Kontoeigentum kann nicht ohne On-Chain-Transaktion geändert werden. Eine Liquidation erfordert eine On-Chain-Auktion.
Ablauf der Orderausführung
1. Orderübermittlung
Nutzeraktion: Übermitteln Sie eine Order über POST /order mit EIP-712-Signatur.
Backend-Validierung:
- Signaturprüfung (EIP-712)
- Pre-Trade-Margin-Prüfungen (szenariobasiert)
- Orderzulassung (Tier, Verfall, Rate-Limits)
Ergebnis: Die Order wird akzeptiert (ACKED) und für das Matching in die Warteschlange gestellt oder mit Begründung abgelehnt.
2. Order-Matching
Prozess: Orders werden im Orderbuch nach Preis-Zeit-Priorität gematcht.
Ausführung: Wenn Orders gematcht werden, werden Fills erstellt und Positionen in der Backend-Datenbank aktualisiert.
Nicht on-chain: Einzelne Order-Matches werden nicht on-chain aufgezeichnet. Der Kontostatus wird über Margin-Root-Aktualisierungen synchronisiert.
3. Positionsaktualisierungen
Prozess: Positionen werden in der Backend-Datenbank verfolgt und in Echtzeit aktualisiert.
Nutzerzugriff: Fragen Sie Positionen über GET /portfolio oder den WebSocket-Kanal portfolio ab.
On-Chain-Synchronisierung: Der Margin-Root (kryptografisches Commitment zum Kontostatus) wird periodisch und bei kritischen Ereignissen on-chain aktualisiert.
4. Settlement
Settlement bei Verfall: Optionen verfallen zum Verfallszeitpunkt des Kontrakts und werden in bar auf Basis des Settlement-Preises abgerechnet. Mainnet-SPCX verfällt um 16:00 Uhr ET; das Testnet verfällt derzeit um 08:00 UTC.
Settlement-Preis: 30-Minuten-TWAP des Hyperliquid-Oracle-Indexpreises, on-chain veröffentlicht über SimpleOracle.setExpiryPrice().
Prozess:
- Das Oracle berechnet den 30-Minuten-TWAP mit Ende zum Verfallszeitpunkt
- Der Settlement-Preis wird on-chain veröffentlicht
- Der innere Wert wird für jede Position berechnet
- Barsalden werden aktualisiert
- Positionen werden geschlossen
Kontoverwaltung
Kontoerstellung
Prozess: Konten werden bei der ersten Einzahlung oder auf explizite Anfrage erstellt.
On-Chain: Der Account-Contract wird als BeaconProxy bereitgestellt (gaseffizientes Minimal-Proxy-Muster).
Manager: Jedes Konto hat einen Manager (EOA), der das Konto kontrolliert und Agenten autorisieren kann.
Einzahlungen und Auszahlungen
Einzahlungen:
- USDC: Übertragung an die Exchange über HyperCore
- Options-ERC20s: Einzahlung über den Exchange-Contract
Auszahlungen:
- Müssen Off-Chain-Risikoprüfungen bestehen (ausreichende Margin nach der Auszahlung)
- Werden on-chain über den Account-Contract ausgeführt
- Manager-Signatur erforderlich
Vertrauensgrenze: Einzahlungen und Auszahlungen erfolgen on-chain und sind verifizierbar.
Liquidation
Die Liquidation verwendet eine Zustandsmaschine mit einer Schonfrist vor der Auktion:
| Zustand | Beschreibung | Dauer |
|---|---|---|
| Healthy | Eigenkapital > erforderliche MM | - |
| PreLiquidation | Eigenkapital < MM, Schonfrist aktiv | 60 Sekunden |
| InLiquidation | Holländische Auktion läuft | Bis zur Ausführung |
| Liquidated | Positionen übertragen | - |
Partielle vs. vollständige Liquidation
| Typ | Bedingung | Verhalten |
|---|---|---|
| Partiell | ≤ 5 Positionen | Bestimmte Positionen liquidieren, bis das Konto gesund ist |
| Vollständig | > 5 Positionen | Gesamtes Konto liquidieren |
Auktionsmechanik
Solvente Auktion (Eigenkapital > 0): Startpreis = Eigenkapital × (1 - Strafgebühr), im Zeitverlauf sinkend. Liquidatoren bieten, um Positionen zu übernehmen.
Insolvente Auktion (Eigenkapital < 0): Der Versicherungsfonds gewährt einen Bonus, um Liquidatoren zu motivieren, Positionen im Minus zu übernehmen.
On-Chain: Auktionsausführung und Positionsübertragung erfolgen on-chain über den Exchange-Contract.
Siehe Liquidation für alle Details.
Hyperliquid-Integration
HIP-3 Perps
Hypercall-Konten können über ActionCaster Perp-Orders auf Hyperliquid ausführen:
Ablauf: Account-Contract → ActionCaster → Hyperliquid L1
Anwendungsfälle:
- Delta-Hedging von Optionspositionen
- Venue-übergreifende Margin (Perp-Positionen zählen zur Portfolio-Margin)
Cross-Margin
HyperCore-Perp-Positionen sind darauf ausgelegt, in die Portfolio-Margin-Berechnungen einbezogen zu werden, was kapitaleffiziente Hedging-Strategien ermöglicht. Portfolio-Margin ist für allgemeine Nutzer in der Mainnet Alpha deaktiviert.
RSM-Befehle
RSM (Risk & Settlement Manager): Backend-Komponente, die On-Chain-Befehle für das Risikomanagement ausgibt.
Zu den Befehlen gehören:
- Reduce-Only-Orders (erzwungene Positionsschließung)
- Schuldenrückzahlung (erzwungene Auszahlung zur Deckung eines negativen Saldos)
- Settlement-Ausführung
On-Chain: RSM-Befehle werden vom RSM-Signer signiert und über den Account-Contract ausgeführt. Nutzer können die Adresse des RSM-Signers und alle Befehlsausführungen on-chain verifizieren.
Dezentralisierungs-Roadmap: Der aktuelle RSM-Signer wird vom Betreiber kontrolliert. Zukünftige Roadmap-Arbeiten werden veröffentlichen, wie diese Rolle dezentralisiert oder anderweitig vertrauensminimiert wird.
Was Sie verifizieren können
On-Chain (verifizierbar)
- Kontoeigentum (Manager-Adresse)
- Account-Contract-Bereitstellung
- Einzahlungen und Auszahlungen
- Liquidationsauktionen und -ergebnisse
- Settlement-Preise (Oracle veröffentlicht on-chain)
- Hyperliquid-Orders (On-Chain-Ausführung)
- RSM-Befehle (On-Chain-Ausführung)
Off-Chain (Vertrauen erforderlich)
- Fairness des Order-Matchings
- Margin-Berechnungen
- Genauigkeit der Positionsverfolgung
- Genauigkeit der Marktdaten
- Zeitpunkt der Liquidationsauslösung
Sicherheitsmodell
Kernprinzip: Kritische Operationen (Kontoeigentum, Einzahlungen, Liquidation, Settlement-Preise) sind on-chain und verifizierbar. Betriebliche Effizienz (Matching, Margin-Prüfungen) erfolgt off-chain.
Kompromisse: Off-Chain-Matching bietet Geschwindigkeit und Effizienz, erfordert derzeit jedoch Vertrauen in den Backend-Betreiber. On-Chain-Operationen bieten Verifizierbarkeit, sind aber langsamer und teurer. Die RSM-Dezentralisierungs-Roadmap ist der Weg von diesem Mainnet-Alpha-Modell hin zu stärkerer Trustlessness.
Siehe auch:
- Settlement & Verfall - Settlement-Prozess und Lebenszyklus
- Liquidation - Zustandsmaschine und Mechanik der Liquidation
- Contracts - Smart-Contract-Dokumentation