#grvt Ich lese in den offiziellen GRVT-Dokumenten und das, was mich am meisten zum genauen Hinsehen bringt, ist dessen Risk-Engine-Architektur. Bei den meisten Derivate-Kontrakten besteht die Risiko-Engine im Grunde aus einer Abwicklungslogik plus einem Preis-Orakel, GRVT zerlegt es jedoch in drei Ebenen: Pre-trade Risk Check, Position Monitoring und Settlement Validation. Diese drei Ebenen laufen nicht seriell, sondern jeweils unabhängig. Erkennt eine Ebene ein Problem, wird eine entsprechende Maßnahme im Risikomanagement ausgelöst.
Der Pre-trade Risk Check erfolgt, bevor Order gematcht werden. Wenn du eine Eröffnungsanfrage stellst, prüft die Risk Engine zuerst, ob dein Unified Balance ausreicht, um die initiale Margin abzudecken, ob der Nominalwert den Obergrenzen der Account-Ebene entspricht, und ob die Konzentration der Positionen für dieses Handelspaar zum Zeitpunkt der Transaktion zu hoch ist. Wenn eine der Bedingungen nicht erfüllt ist, wird die Order direkt abgelehnt und gelangt nicht in die Matching-Queue. Ich habe das im Testnetz mit einer Eröffnung ausprobiert, die den Nominalwert-Limit des Accounts überschritt: Das System stoppte sie bereits in der Einreichungsphase, ohne auf die Abwicklung zu warten.
Position Monitoring läuft in Echtzeit und verfolgt für jedes Konto die Maintenance-Margin-Quote und den Hebel. Der Abwicklungs-Trigger von GRVT ist nicht nur eine einzelne Preislinie, sondern ein gewichteter Wert aus dem Markpreis und dem Orakelpreis, um Fehl-Abwicklungen zu verhindern, die durch Schwankungen eines einzelnen Orakels entstehen. In der Doku steht, dass Pyth und Chainlink als zwei Quellen für die Preisgebung genutzt werden, wobei der gewichtete Median genommen wird. Wenn Abweichungen den Schwellwert überschreiten, wird eine Preisdivergenzprüfung ausgelöst: Die Abwicklung der betreffenden Handelspaare wird pausiert, bis die Preise wieder übereinstimmen.
Settlement Validation findet beim endgültigen Settlement statt und prüft, ob die On-Chain-Statusinformationen mit den Aufzeichnungen der Off-Chain-Matching-Engine konsistent sind. Werden Differenzen festgestellt, triggert das System einen Reconciliation-Prozess und friert die betroffenen Konten ein, bis die Abweichungen behoben sind. Dieses Mechanismus ist bei Derivate-Kontrakten nicht üblich; eher findet man so etwas in klassischen Finanz-Clearingstellen.
Der Vorteil der dreistufigen Prüfung ist, dass Risiken über mehrere Einstiegspunkte abgefangen werden, statt erst an der Abwicklungsgrenze gehandhabt zu werden. Der Nachteil ist, dass jede Ebene zusätzliche Latenz und Rechenaufwand mitbringt. Laut GRVT-Dokumentation soll der Pre-trade Check innerhalb von 10 Millisekunden abgeschlossen sein; Position Monitoring ist eine Echtzeit-Streaming-Berechnung; und Settlement Validation erfolgt als asynchrone, batchweise Verarbeitung.
Ich persönlich denke, dass diese dreistufige Risk-Engine-Architektur nach einem erfolgreichen Mainnet-Launch als recht solide für Derivate-Kontrakte gilt, vorausgesetzt, die genannten SLA können eingehalten werden. @grvt_io
Der Pre-trade Risk Check erfolgt, bevor Order gematcht werden. Wenn du eine Eröffnungsanfrage stellst, prüft die Risk Engine zuerst, ob dein Unified Balance ausreicht, um die initiale Margin abzudecken, ob der Nominalwert den Obergrenzen der Account-Ebene entspricht, und ob die Konzentration der Positionen für dieses Handelspaar zum Zeitpunkt der Transaktion zu hoch ist. Wenn eine der Bedingungen nicht erfüllt ist, wird die Order direkt abgelehnt und gelangt nicht in die Matching-Queue. Ich habe das im Testnetz mit einer Eröffnung ausprobiert, die den Nominalwert-Limit des Accounts überschritt: Das System stoppte sie bereits in der Einreichungsphase, ohne auf die Abwicklung zu warten.
Position Monitoring läuft in Echtzeit und verfolgt für jedes Konto die Maintenance-Margin-Quote und den Hebel. Der Abwicklungs-Trigger von GRVT ist nicht nur eine einzelne Preislinie, sondern ein gewichteter Wert aus dem Markpreis und dem Orakelpreis, um Fehl-Abwicklungen zu verhindern, die durch Schwankungen eines einzelnen Orakels entstehen. In der Doku steht, dass Pyth und Chainlink als zwei Quellen für die Preisgebung genutzt werden, wobei der gewichtete Median genommen wird. Wenn Abweichungen den Schwellwert überschreiten, wird eine Preisdivergenzprüfung ausgelöst: Die Abwicklung der betreffenden Handelspaare wird pausiert, bis die Preise wieder übereinstimmen.
Settlement Validation findet beim endgültigen Settlement statt und prüft, ob die On-Chain-Statusinformationen mit den Aufzeichnungen der Off-Chain-Matching-Engine konsistent sind. Werden Differenzen festgestellt, triggert das System einen Reconciliation-Prozess und friert die betroffenen Konten ein, bis die Abweichungen behoben sind. Dieses Mechanismus ist bei Derivate-Kontrakten nicht üblich; eher findet man so etwas in klassischen Finanz-Clearingstellen.
Der Vorteil der dreistufigen Prüfung ist, dass Risiken über mehrere Einstiegspunkte abgefangen werden, statt erst an der Abwicklungsgrenze gehandhabt zu werden. Der Nachteil ist, dass jede Ebene zusätzliche Latenz und Rechenaufwand mitbringt. Laut GRVT-Dokumentation soll der Pre-trade Check innerhalb von 10 Millisekunden abgeschlossen sein; Position Monitoring ist eine Echtzeit-Streaming-Berechnung; und Settlement Validation erfolgt als asynchrone, batchweise Verarbeitung.
Ich persönlich denke, dass diese dreistufige Risk-Engine-Architektur nach einem erfolgreichen Mainnet-Launch als recht solide für Derivate-Kontrakte gilt, vorausgesetzt, die genannten SLA können eingehalten werden. @grvt_io