gmx synthetics
V2.1
Verträge für GMX Synthetics.
Dieser Abschnitt bietet einen allgemeinen Überblick über die Funktionsweise des Systems.
Eine technische Übersicht finden Sie im Abschnitt weiter unten.
Märkte unterstützen sowohl Spot- als auch Perp-Handel. Sie werden durch die Angabe eines Long-Collateral-Tokens, eines Short-Collateral-Tokens und eines Index-Tokens erstellt.
Beispiele:
Liquiditätsanbieter können entweder den Long- oder den Short-Sicherheitstoken oder beides hinterlegen, um Liquiditätstoken zu prägen.
Der Long-Collateral-Token wird zur Absicherung von Long-Positionen verwendet, während der Short-Collateral-Token zur Absicherung von Short-Positionen verwendet wird.
Liquiditätsanbieter übernehmen die Gewinne und Verluste der Händler für den Markt, für den sie Liquidität bereitstellen.
Da getrennte Märkte eine Risikoisolierung ermöglichen, sind Liquiditätsanbieter nur den Märkten ausgesetzt, auf denen sie ihre Einlagen tätigen, was möglicherweise erlaubnisfreie Notierungen ermöglicht.
Händler können entweder den Long- oder den Short-Token als Sicherheit für den Markt verwenden.
Die Verträge unterstützen die folgenden Hauptfunktionen:
Um frühzeitige Probleme zu vermeiden, erfordern die meisten Aktionen zwei Schritte zur Ausführung:
Die Preise werden von einem Off-Chain-Oracle-System bereitgestellt, das die Preise kontinuierlich basierend auf dem Zeitpunkt der Preisabfrage signiert.
Es wird sowohl ein Mindestpreis als auch ein Höchstpreis unterzeichnet, wodurch Informationen über die Geld-Brief-Spannen einbezogen werden können.
Die im Oracle-Vertrag gespeicherten Preise stellen den Preis einer Einheit des Tokens unter Verwendung eines Werts mit einer Genauigkeit von 30 Dezimalstellen dar.
Durch die Darstellung der Preise auf diese Weise können Umrechnungen zwischen Token-Beträgen und Fiat-Werten vereinfacht werden. Um beispielsweise den Fiat-Wert einer bestimmten Anzahl von Token zu berechnen, würde die Berechnung einfach wie folgt lauten: Token-Betrag * Oracle-Preis, um den Token-Betrag für a zu berechnen Fiat-Wert wäre es: Fiat-Wert / Oracle-Preis.
Finanzierungsgebühren und Preisauswirkungen sorgen für ein Gleichgewicht zwischen Long- und Short-Positionen und verringern gleichzeitig das Risiko einer Preismanipulation.
Es gibt einige Keeper und Knoten im System:
Es gibt einige Hauptarten von Verträgen:
Die Verträge sind in diese Typen unterteilt, um eine schrittweise Erweiterbarkeit zu ermöglichen.
Der Großteil der Daten wird über den DataStore-Vertrag gespeichert.
*storeUtils-Verträge speichern Strukturdaten mithilfe des DataStore. Dies ermöglicht das Hinzufügen neuer Schlüssel zu Strukturen.
EnumberableSets werden verwendet, um eine einfache Abfrage von Bestell- und Positionslisten durch Schnittstellen oder Betreuer zu ermöglichen. Dies wird gegenüber Indexern verwendet, da es bei Indexern zu Verzögerungen bei der Synchronisierung des neuesten Blocks kommen kann. Durch die direkte Speicherung der Listen im Vertrag wird außerdem sichergestellt, dass genaue Daten bei Bedarf abgerufen und überprüft werden können.
*eventUtils-Verträge geben Ereignisse mithilfe des Ereignisemitters aus. Die Ereignisse werden verallgemeinert, um das Hinzufügen neuer Schlüsselwerte zu Ereignissen zu ermöglichen, ohne dass eine Aktualisierung der ABIs erforderlich ist.
Abkürzung für GMX Liquidity Vault: ein Wrapper mehrerer Märkte mit den gleichen Long- und Short-Tokens. Die Liquidität wird basierend auf der Marktauslastung automatisch zwischen den zugrunde liegenden Märkten neu ausgeglichen.
In diesem Abschnitt finden Sie eine technische Beschreibung der Verträge.
Märkte werden mit MarketFactory.createMarket erstellt. Dadurch wird ein MarketToken erstellt und eine Market.Props-Struktur im MarketStore gespeichert.
Der MarketToken wird verwendet, um den Anteil der Liquiditätsanbieter am Marktpool zu verfolgen und die Token für jeden Markt zu speichern.
Zu jedem Zeitpunkt beträgt der Preis eines MarketToken (worth of market pool) / MarketToken.totalSupply() . Die Funktion MarketUtils.getMarketTokenPrice kann verwendet werden, um diesen Wert abzurufen.
Der Wert des Marktpools ist die Summe von
Durch Einzahlungen werden Long-/Short-Tokens zum Pool des Marktes hinzugefügt und MarketTokens an den Einzahler geprägt.
Einzahlungsanforderungen werden durch Aufrufen von ExchangeRouter.createDeposit erstellt, wobei Folgendes angegeben wird:
Einzahlungsanfragen werden mit DepositHandler.executeDeposit ausgeführt. Wenn die Einzahlung zum Zeitstempel n erstellt wurde, sollte sie mit den Oracle-Preisen nach dem Zeitstempel n ausgeführt werden.
Die Menge der zu prägenden MarketTokens vor Gebühren und Preisauswirkungen wird wie folgt berechnet (worth of tokens deposited) / (worth of market pool) * MarketToken.totalSupply() .
Bei Abhebungen werden MarketTokens im Austausch gegen die Long-/Short-Tokens des Pools eines Marktes verbrannt.
Abhebungsanfragen werden durch Aufrufen von ExchangeRouter.createWithdrawal erstellt, wobei Folgendes angegeben wird:
Auszahlungsanfragen werden mit WithdrawalHandler.executeWithdrawal ausgeführt. Wenn die Auszahlung zum Zeitstempel n erstellt wurde, sollte sie mit den Oracle-Preisen nach dem Zeitstempel n ausgeführt werden.
Die Menge der einzulösenden Long- oder Short-Tokens vor Gebühren und Preisauswirkungen wird wie folgt berechnet (worth of market tokens) / (long / short token price) .
Long- und Short-Token eines Marktes können gegeneinander getauscht werden.
Wenn der ETH/USD-Markt beispielsweise WETH als Long-Token und USDC als Short-Token hat, kann WETH an den Markt gesendet werden, um gegen USDC getauscht zu werden, und USDC kann an den Markt gesendet werden, um gegen WETH getauscht zu werden.
Swap-Order-Anfragen werden durch Aufrufen von ExchangeRouter.createOrder erstellt, wobei Folgendes angegeben wird:
Der Swap-Ausgabebetrag, vor Gebühren und Preisauswirkungen, (amount of tokens in) * (token in price) / (token out price) .
Market-Swap-Order-Anfragen werden mit OrderHandler.executeOrder ausgeführt. Wenn die Order zum Zeitstempel n erstellt wurde, sollte sie mit den Oracle-Preisen nach dem Zeitstempel n ausgeführt werden.
Passive Swap-Aufträge, die ausgeführt werden sollen, wenn der Ausgabebetrag dem vom Benutzer angegebenen Mindestausgabebetrag entspricht.
Limit-Swap-Order-Anfragen werden mit OrderHandler.executeOrder ausgeführt. Wenn die Order zum Zeitstempel n erstellt wurde, sollte sie mit Oracle-Preisen nach dem Zeitstempel n ausgeführt werden.
Eröffnen oder erhöhen Sie eine Long-/Short-Perp-Position.
Anforderungen für Markterhöhungsaufträge werden durch Aufrufen von ExchangeRouter.createOrder erstellt, wobei Folgendes angegeben wird:
Anfragen zur Marktsteigerungsorder werden mit OrderHandler.executeOrder ausgeführt. Wenn die Order zum Zeitstempel n erstellt wurde, sollte sie mit den Oracle-Preisen nach dem Zeitstempel n ausgeführt werden.
Passive Positionserhöhungsaufträge, die ausgeführt werden sollten, wenn der Index-Token-Preis dem vom Benutzer angegebenen akzeptablen Preis entspricht.
Beispiel für eine Long-Position: Wenn der aktuelle Index-Token-Preis 5.000 $ beträgt, kann eine Limit-Erhöhungsorder mit einem akzeptablen Preis von 4.990 $ erstellt werden. Die Order kann ausgeführt werden, wenn der Index-Token-Preis <= 4.990 $ beträgt.
Beispiel für eine Short-Position: Wenn der aktuelle Index-Token-Preis 5.000 $ beträgt, kann eine Limit-Erhöhungsorder mit einem akzeptablen Preis von 5.010 $ erstellt werden. Die Order kann ausgeführt werden, wenn der Index-Token-Preis >= 5.010 $ beträgt.
Anfragen zur Limiterhöhung werden mit OrderHandler.executeOrder ausgeführt. Wenn die Order zum Zeitstempel n erstellt wurde, sollte sie mit den Oracle-Preisen nach dem Zeitstempel n ausgeführt werden.
Schließen oder verringern Sie eine Long-/Short-Perp-Position.
Anforderungen für Marktverringerungsaufträge werden durch Aufrufen von ExchangeRouter.createOrder erstellt, wobei Folgendes angegeben wird:
Marktabnahme-Orderanfragen werden mit OrderHandler.executeOrder ausgeführt. Wenn die Order zum Zeitstempel n erstellt wurde, sollte sie mit den Oracle-Preisen nach dem Zeitstempel n ausgeführt werden.
Passive Positionsverringerungsaufträge, die ausgeführt werden sollten, wenn der Index-Token-Preis mit dem vom Benutzer angegebenen akzeptablen Preis übereinstimmt.
Beispiel für eine Long-Position: Wenn der aktuelle Index-Token-Preis 5.000 $ beträgt, kann eine Limit-Reduktionsorder mit einem akzeptablen Preis von 5.010 $ erstellt werden. Die Order kann ausgeführt werden, wenn der Index-Token-Preis >= 5.010 $ beträgt.
Beispiel für eine Short-Position: Wenn der aktuelle Index-Token-Preis 5.000 $ beträgt, kann eine Limit-Herabsetzungsorder mit einem akzeptablen Preis von 4.990 $ erstellt werden. Die Order kann ausgeführt werden, wenn der Index-Token-Preis <= 4.990 $ beträgt.
Limit-Reduktions-Orderanfragen werden mit OrderHandler.executeOrder ausgeführt. Wenn die Order zum Zeitstempel n erstellt wurde, sollte sie mit den Oracle-Preisen nach dem Zeitstempel n ausgeführt werden.
Passive Positionsverringerungsaufträge, die ausgeführt werden sollten, wenn der Index-Token-Preis den vom Benutzer angegebenen akzeptablen Preis überschreitet.
Beispiel für eine Long-Position: Wenn der aktuelle Index-Token-Preis 5.000 $ beträgt, kann eine Stop-Loss-Reduktionsorder mit einem akzeptablen Preis von 4.990 $ erstellt werden. Die Order kann ausgeführt werden, wenn der Index-Token-Preis <= 4.990 $ beträgt.
Beispiel für eine Short-Position: Wenn der aktuelle Index-Token-Preis 5.000 $ beträgt, kann eine Stop-Loss-Reduktionsorder mit einem akzeptablen Preis von 5.010 $ erstellt werden. Die Order kann ausgeführt werden, wenn der Index-Token-Preis >= 5.010 $ beträgt.
Stop-Loss-Reduction-Order-Anfragen werden mit OrderHandler.executeOrder ausgeführt. Wenn die Order zum Zeitstempel n erstellt wurde, sollte sie mit den Oracle-Preisen nach dem Zeitstempel n ausgeführt werden.
Der Preis der ETH beträgt 5000 und die ETH hat 18 Dezimalstellen.
Der Preis einer ETH-Einheit beträgt 5000 / (10 ^ 18), 5 * (10 ^ -15) .
Um die Dezimalstellen zu verarbeiten, multiplizieren Sie den Wert mit (10 ^ 30) .
Der Preis würde als 5000 / (10 ^ 18) * (10 ^ 30) => 5000 * (10 ^ 12) gespeichert.
Zur Gasoptimierung werden diese Preise in Form eines uint8-Dezimalmultiplikatorwerts und eines uint32-Preiswerts an das Oracle gesendet.
Wenn der Dezimalmultiplikatorwert auf 8 eingestellt ist, wäre der uint32-Wert 5000 * (10 ^ 12) / (10 ^ 8) => 5000 * (10 ^ 4) .
Mit dieser Konfiguration können ETH-Preise einen Maximalwert von (2 ^ 32) / (10 ^ 4) => 4,294,967,296 / (10 ^ 4) => 429,496.7296 mit einer Genauigkeit von 4 Dezimalstellen haben.
Der Preis von BTC beträgt 60.000 und BTC hat 8 Dezimalstellen.
Der Preis einer BTC-Einheit beträgt 60,000 / (10 ^ 8), 6 * (10 ^ -4) .
Der Preis würde als 60,000 / (10 ^ 8) * (10 ^ 30) => 6 * (10 ^ 26) => 60,000 * (10 ^ 22) gespeichert.
Maximalwert der BTC-Preise: (2 ^ 64) / (10 ^ 2) => 4,294,967,296 / (10 ^ 2) => 42,949,672.96 .
Dezimalstellen der Genauigkeit: 2.
Der Preis von USDC beträgt 1 und USDC hat 6 Dezimalstellen.
Der Preis einer USDC-Einheit beträgt 1 / (10 ^ 6), 1 * (10 ^ -6) .
Der Preis würde als 1 / (10 ^ 6) * (10 ^ 30) => 1 * (10 ^ 24) gespeichert.
Höchstwert der USDC-Preise: (2 ^ 64) / (10 ^ 6) => 4,294,967,296 / (10 ^ 6) => 4294.967296 .
Dezimalstellen der Genauigkeit: 6.
Der Preis von DG beträgt 0,00000001 und DG hat 18 Dezimalstellen.
Der Preis einer DG-Einheit beträgt 0.00000001 / (10 ^ 18), 1 * (10 ^ -26) .
Der Preis würde als 1 * (10 ^ -26) * (10 ^ 30) => 1 * (10 ^ 3) gespeichert.
Maximalwert der DG-Preise: (2 ^ 64) / (10 ^ 11) => 4,294,967,296 / (10 ^ 11) => 0.04294967296 .
Dezimalstellen der Genauigkeit: 11.
Die Formel zur Berechnung, auf welchen Wert der Dezimalmultiplikator eingestellt werden sollte:
Dezimalstellen: 30 – (Token-Dezimalstellen) – (Anzahl der für die Genauigkeit gewünschten Dezimalstellen)
Beispielrechnung für WNT:
dataStreamPrice / (10 ^ 8) / (10 ^ 18) * (10 ^ 30)(5000 * (10 ^ 8)) / (10 ^ 8) / (10 ^ 18) * (10 ^ 30) = 5000 * (10 ^ 12)dataStreamPrice * multiplier / (10 ^ 30)(5000 * (10 ^ 8)) * (10 ^ 34) / (10 ^ 30) = 5000 * (10 ^ 12)Beispielrechnung für WBTC:
dataStreamPrice / (10 ^ 8) / (10 ^ 8) * (10 ^ 30)(50,000 * (10 ^ 8)) / (10 ^ 8) / (10 ^ 8) * (10 ^ 30) = 50,000 * (10 ^ 22)dataStreamPrice * multiplier / (10 ^ 30)(50,000 * (10 ^ 8)) * (10 ^ 44) / (10 ^ 30) = 50,000 * (10 ^ 22) Die Formel für den Multiplikator lautet: 10 ^ (60 - dataStreamDecimals - tokenDecimals)
Finanzierungsgebühren stellen einen Anreiz für den Ausgleich von Long- und Short-Positionen dar. Die Seite mit dem größeren offenen Interesse zahlt eine Finanzierungsgebühr an die Seite mit dem kleineren offenen Interesse.
Die Finanzierungsgebühren für die größere Seite werden wie folgt berechnet: (funding factor per second) * (open interest imbalance) ^ (funding exponent factor) / (total open interest) .
Wenn beispielsweise der Finanzierungsfaktor pro Sekunde 1 / 50.000 und der Finanzierungsexponentenfaktor 1 beträgt und das Long-Open-Interest 150.000 USD und das Short-Open-Interest 50.000 USD beträgt, beträgt die Finanzierungsgebühr pro Sekunde für Long-Positionen (1 / 50,000) * 100,000 / 200,000 => 0.00001 => 0.001% .
Die Finanzierungsgebühr pro Sekunde für Shorts würde -0.00001 * 150,000 / 50,000 => 0.00003 => -0.003% betragen.
Es ist auch möglich, einen „fundingIncreaseFactorPerSecond“-Wert festzulegen. Dies würde zu der folgenden Finanzierungslogik führen:
longShortImbalance wird berechnet als [abs(longOpenInterest - shortOpenInterest) / totalOpenInterest] ^ fundingExponentFactorlongShortImbalance über dem thresholdForStableFunding liegt, erhöht sich die Finanzierungsrate um longShortImbalance * fundingIncreaseFactorPerSecondlongShortImbalance größer als thresholdForDecreaseFunding und kleiner als thresholdForStableFunding ist und die Abweichung in die gleiche Richtung wie die Finanzierung geht, ändert sich die Finanzierungsrate nichtlongShortImbalance unter dem Schwellenwert thresholdForDecreaseFunding liegt und die Abweichung in die gleiche Richtung wie die Finanzierung geht, verringert sich die Finanzierungsrate um fundingDecreaseFactorPerSecond Da „longShortImbalance“ > „thresholdForStableFunding“ ist, sollte „savedFundingFactorPerSecond“ um 0.0001% * 6% * 600 = 0.0036% steigen.
Da Long-Positionen bereits Short-Positionen auszahlen, ist die Abweichung dieselbe und longShortImbalance < Schwellenwert für stabile Finanzierung, gespeicherter Finanzierungsfaktor PerSecond sollte sich nicht ändern
Da „longShortImbalance“ < „thresholdForDecreaseFunding“ ist, sollte „savedFundingFactorPerSecond“ um 0.000002% * 600 = 0.0012% sinken.
Da der Versatz in die andere Richtung geht, sollte „savedFundingFactorPerSecond“ um 0.0001% * 1% * 600 = 0.0006% sinken.
Beachten Sie, dass es Möglichkeiten gibt, die Finanzierungsgebühren zu manipulieren. Die Finanzierungsfaktoren sollten angepasst werden, um diese Möglichkeit zu minimieren:
Wenn longOpenInterest > shortOpenInterest und longShortImbalance innerhalb des SchwellenwertsForStableFunding liegen, könnte ein Benutzer, der eine Short-Position hält, eine Long-Position eröffnen, um longShortImbalance zu erhöhen und versuchen, die Finanzierungsgebühr zu erhöhen. In einem aktiven Markt sollte es schwierig sein, vorherzusagen, wann jemand anderes eine gegnerische Short-Position eröffnen würde, um die erhöhte Finanzierungsgebühr zu verdienen, was dieses Spiel erschweren dürfte. Die Finanzierungsfaktoren können auch angepasst werden, um den Nutzen dieses Glücksspiels zu minimieren .
Wenn LongOpenInterest > ShortOpenInterest und LongShortImbalance > ThresholdForStableFunding, könnte ein Händler, der eine Long-Position hält, während dieser Zeit mehrere kleine Trades tätigen, um sicherzustellen, dass der Finanzierungsfaktor kontinuierlich aktualisiert wird, anstatt für die gesamte Dauer einen größeren Wert zu verwenden. Dies sollte dies minimieren Finanzierungsgebühr für Long-Positionen, sollte die Finanzierungsgebühr jedoch nicht unter die erwarteten Sätze senken.
Den Liquiditätsanbietern wird eine Leihgebühr gezahlt. Dadurch wird verhindert, dass Benutzer sowohl Long- als auch Short-Positionen eröffnen, um Poolkapazität zu nutzen, ohne Gebühren zu zahlen.
Für Kreditgebühren kann ein Kurvenmodell oder ein Kink-Modell verwendet werden.
Um das Kurvenmodell zu verwenden, wären die zu konfigurierenden Schlüssel BORROWING_FACTOR und BORROWING_EXPONENT_FACTOR . Der Kreditaufnahmefaktor pro Sekunde würde wie folgt berechnet:
// reservedUsd is the total USD value reserved for positions
reservedUsd = MarketUtils.getReservedUsd(...)
// poolUsd is the USD value of the pool excluding pending trader PnL
poolUsd = MarketUtils.getPoolUsdWithoutPnl(...)
// reservedUsdAfterExponent is the reservedUsd after applying the borrowingExponentFactor for the market
reservedUsdAfterExponent = applyExponentFactor(reservedUsd, borrowingExponentFactor)
borrowingFactorPerSecond = borrowingFactor * reservedUsdAfterExponent / poolUsd
Um das Kink-Modell zu verwenden, wären die zu konfigurierenden Schlüssel OPTIMAL_USAGE_FACTOR , BASE_BORROWING_FACTOR und ABOVE_OPTIMAL_USAGE_BORROWING_FACTOR . Der Kreditaufnahmefaktor pro Sekunde würde wie folgt berechnet:
// usageFactor is the ratio of value reserved for positions to available value that can be reserved
usageFactor = MarketUtils.getUsageFactor(...)
borrowingFactorPerSecond = baseBorrowingFactor * usageFactor
if (usageFactor > optimalUsageFactor) {
diff = usageFactor - optimalUsageFactor
additionalBorrowingFactorPerSecond = aboveOptimalUsageBorrowingFactor - baseBorrowingFactor
borrowingFactorPerSecond += additionalBorrowingFactorPerSecond * diff / (Precision.FLOAT_PRECISION - optimalUsageFactor)
}
Es besteht auch die Möglichkeit, das Flag „skipBorrowingFeeForSmallerSide“ zu setzen. Dies würde dazu führen, dass die Leihgebühr für die kleinere Seite auf Null gesetzt wird. Wenn es beispielsweise mehr Long- als Short-Positionen gibt und „skipBorrowingFeeForSmallerSide“ wahr ist, wäre die Leihgebühr für Short-Positionen Null.
Den Code zur Preisauswirkung finden Sie in den /pricing Verträgen.
Die Preisauswirkungen werden wie folgt berechnet:
(initial USD difference) ^ (price impact exponent) * (price impact factor) - (next USD difference) ^ (price impact exponent) * (price impact factor)
Bei Swaps wird das Ungleichgewicht als Differenz im Wert der Long-Tokens und Short-Tokens berechnet.
Zum Beispiel:
price impact exponent ist auf 2 und price impact factor auf 0.01 / 50,000 festgelegt0 ^ 2 * (0.01 / 50,000) - 50,000 ^ 2 * (0.01 / 50,000) => -$50050,000 ^ 2 * (0.01 / 50,000) - 25,000 ^ 2 * (0.01 / 50,000) => $375Bei Positionsaktionen (Position erhöhen/verringern) wird das Ungleichgewicht als Differenz zwischen den offenen Long- und Short-Positionen berechnet.
price impact exponents und price impact factors werden pro Markt konfiguriert und können für Spot- und Positionsaktionen unterschiedlich sein.
Beachten Sie, dass es sich bei dieser Berechnung um die Preisauswirkungen für den Handel eines Benutzers handelt, nicht um die Preisauswirkungen auf den Pool. Beispielsweise kann der Handel eines Benutzers eine Preisauswirkung von 0,25 % haben, der nächste Handel über einen sehr kleinen Betrag kann eine Preisauswirkung von 0,5 % haben.
Der Zweck der Preisauswirkung besteht darin:
Da die Verträge einen Orakelpreis verwenden, der ein Durchschnitts- oder Medianpreis mehrerer Referenzbörsen wäre. Ohne Auswirkungen auf den Preis kann es gewinnbringend sein, die Preise an Referenzbörsen bei der Ausführung von Aufträgen für die Kontrakte zu manipulieren.
Dieses Risiko besteht auch dann, wenn die positiven und negativen Preisauswirkungswerte ähnlich sind. Aus diesem Grund sollte der positive Preisauswirkungswert in Zeiten von Volatilität oder unregelmäßigen Preisbewegungen auf einen niedrigen Wert eingestellt werden.
Wenn negative Preisauswirkungen als Sicherheit von der Position abgezogen werden, kann dies dazu führen, dass die Position eine andere Hebelwirkung hat als vom Benutzer beabsichtigt, sodass anstelle der Sicherheit der Einstiegs-/Ausstiegspreis der Position abgezogen wird aufgrund der Preisauswirkungen angepasst.
Zum Beispiel:
Wenn sich der Index-Token sowohl vom Long- als auch vom Short-Token des Marktes unterscheidet, ist es möglich, dass der Poolwert erheblich durch den Position Impact Pool beeinflusst wird, wenn der Position Impact Pool sehr groß ist und der Index Token einen hohen Preis hat Zunahme. Sollte dies zu einem Problem werden, kann eine Option zur schrittweisen Reduzierung der Größe des Position Impact Pools hinzugefügt werden.
Der Einfluss auf den Preis wird auch mithilfe eines virtuellen Inventarwerts für Positionen und Swaps verfolgt. Dadurch wird das Ungleichgewicht von Token auf ähnlichen Märkten verfolgt, z. B. ETH/USDC, ETH/USDT.
Im Falle einer großen Preisbewegung ist es möglich, dass eine große Anzahl von Positionen auf einer Seite reduziert oder liquidiert wird, was zu einem erheblichen Ungleichgewicht zwischen offenen Long- und Short-Positionen führt. Dies könnte zu sehr hohen Preisauswirkungswerten führen. Um dies zu mildern, kann ein maximaler Position Impact Factor-Wert konfiguriert werden. Wenn die aktuelle Preisauswirkung die maximale negative Preisauswirkung übersteigt, werden alle überschüssigen Sicherheiten, die über die maximale negative Preisauswirkung hinaus abgezogen werden, im Vertrag gehalten. Wenn keine Preismanipulation festgestellt wurde, kann diese Sicherheit an den Benutzer freigegeben werden. Wenn die negative Preisauswirkung begrenzt ist, kann es profitabel sein, Positionen zu eröffnen und sofort zu schließen, da die positive Preisauswirkung nun möglicherweise größer ist als die begrenzte negative Preisauswirkung. Um dies zu vermeiden, sollte die maximale positive Preisauswirkung so konfiguriert werden, dass sie unter der maximalen negativen Preisauswirkung liegt.
Es gibt konfigurierbare Swap-Gebühren und Positionsgebühren pro Markt.
Auch die Ausführungsgebühren werden bei der Erstellung von Einzahlungs-, Auszahlungs- und Orderanfragen geschätzt und verbucht, sodass die Inhaber Transaktionen zu nahezu Nettokosten von Null ausführen können.
Wenn ein Markt über Stablecoins als Short-Collateral-Token verfügt, sollte er in der Lage sein, Short-Gewinne vollständig auszuzahlen, wenn das maximale Short-Open-Interest die Anzahl der Stablecoins im Pool nicht überschreitet.
Verfügt ein Markt über einen Long-Collateral-Token, der sich vom Index-Token unterscheidet, kann es sein, dass die Long-Gewinne nicht vollständig ausgezahlt werden, wenn der Preisanstieg des Index-Tokens den Preisanstieg des Long-Collateral-Tokens übersteigt.
Märkte verfügen über einen Reservefaktor, der es ermöglicht, offene Positionen auf einen Prozentsatz der Poolgröße zu begrenzen. Dies verringert die Auswirkungen von Gewinnen aus Short-Positionen und verringert das Risiko, dass Long-Positionen nicht vollständig ausgezahlt werden können.
Der Preis eines Markt-Tokens hängt vom Wert der Vermögenswerte im Pool und dem ausstehenden Netto-PnL der offenen Positionen der Händler ab.
Es ist möglich, dass der ausstehende PnL begrenzt wird. Die zur Berechnung des Markt-Token-Preises verwendeten Faktoren können je nach Aktivität unterschiedlich sein:
Keys.MAX_PNL_FACTOR_FOR_DEPOSITS: Dies ist die PnL-Faktorobergrenze bei der Berechnung des Markt-Token-Preises für Einlagen
Keys.MAX_PNL_FACTOR_FOR_WITHDRAWALS: Dies ist die PnL-Faktorobergrenze bei der Berechnung des Markt-Token-Preises für Abhebungen
Keys.MAX_PNL_FACTOR_FOR_TRADERS: Dies ist die PnL-Faktorobergrenze bei der Berechnung des Markt-Token-Preises für die Schließung einer Position
Diese verschiedenen Faktoren können konfiguriert werden, um Liquiditätsanbietern beim Risikomanagement zu helfen und bei Bedarf Anreize für Einlagen zu schaffen. Beispielsweise trägt die Obergrenze des PnL des Händlers dazu bei, den Betrag zu begrenzen, um den der Markt-Token-Preis aufgrund des PnL des Händlers gesenkt werden kann. Eine Obergrenze des PnL für Ein- und Auszahlungen kann dazu führen zu einem niedrigeren Markt-Token-Preis für Einzahlungen im Vergleich zu Auszahlungen, was einen Anreiz für Einzahlungen bieten kann, wenn der ausstehende PnL hoch ist.
minCollateralFactor: Dies bestimmt das minimal zulässige Verhältnis von (Positionssicherheit) / (Positionsgröße)
maxPoolAmount: Die maximale Anzahl an Token, die in einen Markt eingezahlt werden können
maxOpenInterest: Das maximale offene Interesse, das für einen Markt geöffnet werden kann
Reservefaktor: Dies bestimmt das maximal zulässige Verhältnis von (Wert der für Positionen reservierten Token) / (Tokens im Pool)
maxPnlFactor: Das maximale Verhältnis von (PnL / Wert der Token im Pool)
positionFeeFactor: Dies bestimmt den prozentualen Betrag der Gebühren, die für Aktionen zur Positionserhöhung/-verringerung abgezogen werden. Der Gebührenbetrag basiert auf der Änderung der Positionsgröße
positionImpactFactor: Dies ist der „Preisauswirkungsfaktor“ für Positionen, die im Abschnitt „Preisauswirkung“ beschrieben werden
maxPositionImpactFactor: Dies ist der „maximale Preiseinfluss“ für Positionen, die im Abschnitt „Preiseinfluss“ beschrieben werden
positionImpactExponentFactor: Dies ist der „Preisauswirkungsexponent“-Wert für Positionsaktionen, der im Abschnitt „Preisauswirkung“ beschrieben wird
swapFeeFactor: Dies bestimmt den prozentualen Betrag der Gebühren, die für Swaps abgezogen werden, der Gebührenbetrag basiert auf dem Swap-Betrag
swapImpactFactor: Dies ist der „Preisauswirkungsfaktor“, der im Abschnitt „Preisauswirkungen“ beschrieben wird
swapImpactExponentFactor: Dies ist der „Preisauswirkungsexponenten“-Wert für Einlagen und Swaps, der oben im Abschnitt „Preisauswirkungen“ beschrieben wird
„fundingFactor“: Dies ist der „Finanzierungsfaktor pro Sekunde“, der im Abschnitt „Finanzierungsgebühren“ beschrieben wird
BorrowingFactorForLongs: Dies ist der „Borrowing-Faktor“ für Long-Positionen, der im Abschnitt „Borrowing-Gebühren“ beschrieben wird
BorrowingFactorForShorts: Dies ist der „Borrowing-Faktor“ für Short-Positionen, der im Abschnitt „Borrowing-Gebühren“ beschrieben wird
BorrowingExponentFactorForLongs: Dies ist der „Borrowing-Exponentenfaktor“ für Long-Positionen, der im Abschnitt „Borrowing-Gebühren“ beschrieben wird
BorrowingExponentFactorForShorts: Dies ist der „Borrowing-Exponentenfaktor“ für Long-Positionen, der im Abschnitt „Borrowing-Gebühren“ beschrieben wird
Rollen werden im RoleStore verwaltet, der RoleAdmin hat Zugriff, um jede Rolle zu gewähren und zu widerrufen.
Der RoleAdmin wird zunächst der Deployer sein, dieser sollte jedoch entfernt werden, nachdem die Rollen eingerichtet wurden.
Nach der Ersteinrichtung:
Nur der Timelock-Vertrag sollte die RoleAdmin-Rolle haben
Neue Rollen können von Timelock-Administratoren zeitverzögert vergeben werden
Systemwerte sollten nur über den Config-Vertrag festgelegt werden
Kein EOA sollte eine Controller-Rolle haben
Konfigurationsverwalter und Timelock-Administratoren könnten möglicherweise den regulären Betrieb stören, indem sie Funktionen deaktivieren, Werte falsch einstellen, bösartige Token auf die Whitelist setzen, den positiven Preisauswirkungswert missbrauchen usw
Es wird erwartet, dass das Timelock-Multisig die Berechtigungen böswilliger oder kompromittierter Konten widerrufen sollte
Auftragsverwalter und eingefrorene Auftragsverwalter könnten möglicherweise durch Transaktionsbestellung, verzögerte Transaktionsausführung, ADL-Ausführung usw. Mehrwert schaffen. Dies wird durch ein Keeper-Netzwerk teilweise abgemildert
Von Oracle-Unterzeichnern wird erwartet, dass sie den Preis der Token genau angeben
Sicherheiten-Token müssen mit einem konfigurierten TOKEN_TRANSFER_GAS_LIMIT auf die Whitelist gesetzt werden
Rebasing-Token, Token, deren Guthaben sich bei der Übertragung ändert, mit Token-Burns, Token mit Rückrufen, z. B. ERC-777-Token usw., sind nicht mit dem System kompatibel und sollten nicht auf die Whitelist gesetzt werden
Orderverwalter können bei Limit-Orders mit einem Swap Preise aus unterschiedlichen Zeitstempeln verwenden, was zu unterschiedlichen Outputmengen führen würde
Von den Auftragsverwaltern wird erwartet, dass sie überprüfen, ob eine Transaktion rückgängig gemacht wird, bevor sie die Transaktion senden, um die Gasverschwendung zu minimieren
Ordnungshüter können dazu führen, dass Anfragen storniert statt ausgeführt werden, indem sie die Anfrage mit unzureichendem Gas ausführen
Wenn eine Ausführungstransaktion eine große Gasmenge erfordert, die nahe an der maximalen Blockgasgrenze liegt, kann es möglich sein, Blöcke zu stopfen, um zu verhindern, dass die Transaktion in Blöcke aufgenommen wird
In bestimmten Blockchains ist es möglich, dass der Halter die Kontrolle über den tx.gasprice hat, der zur Ausführung einer Transaktion verwendet wird, was sich auf die an den Halter gezahlte Ausführungsgebühr auswirken würde
Die Ausführung von Aufträgen kann durch einen böswilligen Benutzer verhindert werden, der absichtlich einen Markt aus dem Gleichgewicht bringt, was zu hohen Preisauswirkungen führt. Dies dürfte kostspielig sein und es ist schwierig, davon zu profitieren
Die Auswirkungen auf den Preis können durch den Einsatz von Positionen und Swaps sowie den Handel über Märkte, Ketten, Forks und andere Protokolle hinweg reduziert werden. Dies wird teilweise durch die virtuelle Bestandsverfolgung gemildert
Ein Benutzer kann die Auswirkungen auf den Preis reduzieren, indem er Positionen mit hoher Hebelwirkung verwendet. Dies wird teilweise durch den Wert MIN_COLLATERAL_FACTOR_FOR_OPEN_INTEREST_MULTIPLIER gemildert
Die Berechnung der Preiswirkungwerte berücksichtigen Gebühren nicht und die Auswirkungen, die sich aus der Preiswirkung selbst ergeben
Es ist selten, aber möglich, dass der Wert eines Pools negativ wird. Dies kann passieren, da der ImpoolAmount und die anhängige PNL vom Wert der Token im Pool abgezogen werden
Aufgrund der Differenz der positiven und negativen Positionspreisauswirkungen kann es zu einem Aufbau virtueller Token -Mengen im Positionswirkungsbecken aufgebaut sein
Virtual Inventory verfolgt die Anzahl der Token in Pools. Es muss sichergestellt werden in der Gruppe sollte die gleichen Dezimalstellen haben, vorausgesetzt, USDC hat 6 Dezimalstellen und DAI hat 18 Dezimalstellen, Märkte wie Eth-Usdc, ETH-DAI sollte nicht gruppiert werden
Virtuelle IDs müssen vor der Erstellung des Marktes / Token -Whitelisting festgelegt werden. Wenn sie nach dem Handel mit Token / Markt abgeschlossen ist, wäre die Verfolgung nicht korrekt und muss möglicherweise angepasst werden
Für L2s mit Sequenzern gibt es keine Vertragsvalidierung, um zu überprüfen, ob der L2 -Sequenzer aktiv ist. Oracle Keepers sollten aufhören, Preise zu unterschreiben, wenn der Sequenzer keine Blöcke erstellt wird. Wenn der Sequenzer den regulären Betrieb wieder aufnimmt Neueste Blöcke mit den neuesten abgerufenen Preisen
Wenn ein L2 -Sequenzer heruntergekommen ist, kann dies Ablagerungen in Positionen verhindern, um Liquidationen zu verhindern
Für Transaktionen, die vollständig mit Preis-Ketten-Preis-Feeds ausgeführt werden können Stattdessen verwendet, sobald alle Token unterstützt werden
Block-Re-ORGs können es einem Benutzer ermöglichen, eine Bestellung nach seiner Ausführung rückwirkend zu stornieren, wenn der Preis für den Benutzer nicht positiv bewegt wurde. Es sollte darauf geachtet werden
Das Aktualisieren und Stornieren von Bestellungen könnte vorne mit der Ausführung von Auftragsanlagen geführt werden. Dies sollte kein Problem sein Die Preiswirkung sollte angepasst werden, um sicherzustellen, dass die Strategie nicht nettiert ist, und die Anpassung der UI -Gebühr oder des Überweisungsrabatts kann in ähnlicher Weise verwendet werden, um Bestellstornierungen zu verursachen
Bei Ausfallzeiten der Blockchain oder Oracle können Bestellungen zu erheblich unterschiedlichen Preisen ausgeführt werden oder nicht ausgeführt werden, wenn der akzeptable Preis der Bestellung nicht erfüllt werden kann
Es ist eine Abhängigkeit von der Genauigkeit des Block -Zeitstempels, da Orakelpreise gegen diesen Wert validiert werden. Für Blockchains, bei denen die Blockchain -Knoten eine gewisse Kontrolle über den Zeitstempel haben, sollte darauf geachtet werden Zeitstempel unrentabel
Die GLV -Verschiebungsfunktion kann genutzt werden, indem die Nutzung in einem Markt vorübergehend erhöht wird, der typischerweise eine geringe Nutzung aufweist. Sobald der Torhüter die Verschiebung ausführt, kann der Angreifer die Nutzung wieder auf seine normalen Ebenen senken. Positionsgebühren und Preisauswirkungen sollten so konfiguriert werden, dass dieser Angriff so teuer genug ist, um den GLV -Verlust abzudecken.
In GLV können GM -Märkte über ihren maximalen PnltopoolfactorFortraders liegen. Wenn die Maxpnlfactorfordeposits dieses GM -Marktes höher als die MaxPnlfactorFortraders ist, wird der GM -Markt während der Einlagen niedriger bewertet, als es sich an Händlern realisiert hat, dass ihre begrenzten Gewinne festgestellt haben. Bösartiger Benutzer kann einen GM -Markt in einem solchen Zustand beobachten und sich in den GLV einreichen, der ihn enthält, um von ADLs zu gewinnen, die bald folgen werden. Um diese maxpnlfactorFordePosits zu vermeiden, sollte maxpnlfactorFortraders geringer oder gleich sein.
Es ist technisch möglich, dass der Marktwert negativ wird. In diesem Fall wäre der GLV unbrauchbar, bis der Marktwert positiv wird.
GM -Token könnten aufgrund des hohen PNL -Faktors oder des hohen Reserved USD illiquide werden. Benutzer können illiquide GM -Token in die GVL einlegen und die Liquidität aus einem anderen Markt abziehen, wodurch der GLV mit illiquide Token zurücklässt. Die Parameter von GlvmaxMarkettokenBalanceusd und GlvmaxettokenBalanceamount sollten die Risiko eines Marktes verantwortlich verantwortlich machen, um nicht zu viele GM -Token von einem riskanten Markt zu haben.
scripts/verifyFallback.ts können verwendet werden, um Verträge zu überprüfennpx hardhat verify verifiziert werden, danach sollten alle Markttoken -Verträge überprüft werden, da der Quellcode derselbe wäre Wenn neue Verträge hinzugefügt werden, die zu einem Unterschied in der Preisgestaltung führen können, z.
Alle externen Protokolle, die den Leservertrag oder potenziell veraltete Berechnungen für die Preisgestaltung verwenden
Es wird empfohlen, einen besten Aufwand zu veröffentlichen, um wichtige Änderungen zu dokumentieren, über die die Integrationen bekannt sein sollten, z. B. wenn ein Feld zu einer Struktur hinzugefügt wird, die in eine Rückruffunktion übergeben wird. Diese Änderung ist möglicherweise nicht offensichtlich für Integrationen
Wenn die Verträge zur Unterstützung von Aktiensynthetikmärkten verwendet werden, sollte darauf geachtet werden, dass Aktienspalten und ähnliche Änderungen behandelt werden können
Verträge mit der Rolle "Controller" haben Zugriff auf wichtige Funktionen wie das Festlegen von Datenspeicherwerten. Aus diesem Grund sollten darauf geachtet werden, dass solche Verträge keine generischen Funktionen oder Funktionen haben, die verwendet werden können, um wichtige Werte zu ändern
Tests sollten für die verschiedenen Markttypen hinzugefügt werden, z. B. nur Märkte, einzelne Tokenmärkte
Die Reihenfolge der Werte im EreignisData für Rückrufe sollte nicht geändert werden, sofern dies ausschließlich erforderlich ist, da Rückrufverträge auf die Werte nach einem festen Index verweisen können
Beachten Sie, dass wenn eine Struktur, die in Rückrufe übergeben wird
Wenn das Überweisungssystem verwendet wird, sollte dem OrderHandler Zugriff erhalten, um den Empfehlungscode für Händler zu aktualisieren
Einlagen, Abhebungen und Bestellungen können storniert werden, wenn die in der Anfrage angegebenen Anforderungen nicht erfüllt werden können, z. B. minem Betrag. Überprüfen Sie, wo Mittel und Gasrückerstattungen an die Stornierung gesendet werden, um sicherzustellen, dass sie den Erwartungen entsprechen.
Die Verringerung von Positionsaufträgen kann zwei Token anstelle eines einzelnen Tokens ausgeben, wenn der Abnahmepositions -Swap ausfällt, ist es auch möglich, dass die Ausgangsmenge und die Sicherheiten möglicherweise nicht ausreichen, um die Gebühren abzudecken, was dazu führt, dass die Reihenfolge nicht ausgeführt wird
Wenn es eine große Ausbreitung gibt, ist es möglich, dass das Öffnen / Schließen einer Position den minem und maximalen Preis des Markttourens erheblich verändern kann.
Änderungen in Konfigurationswerten wie Finanzierung_Faktor, Stable_funding_factor, bloße_faktor, Skip_Borrowing_fee_for_smaller_side, bloße_fee_receiver_factor, könnte zu zusätzlichen Gebühren für Benutzer führen, dies könnte auch zu einer Änderung der Markttouren führen.
Wenn Trader PNL aufgrund von max_pnl_factor_for_traders begrenzt ist, kann sich der Prozentsatz des an Händler ausgezahlten Gewinns abhängig von der Reihenfolge, wann die Positionen verringert / geschlossen werden
Ereignisdaten können an Rückrufverträge übergeben werden, die Bestellung der Parameter im EreignisData wird versucht, unverändert zu sein der erwartete Wert
Einige Parameter wie Order.Sizedelta und Order.initialCollateraldeltaAmount können während der Ausführung aktualisiert werden. Die aktualisierten Werte werden möglicherweise nicht an den Rückrufvertrag übergeben
Bei der Erstellung eines Rückrufvertrags muss der Rückrufvertrag möglicherweise die Whitelist den Einleger, OrderHandler oder EntzugsHandler benötigen. Es ist zu beachten vorübergehend zur gleichen Zeit existieren, z. B. OrderHandler (1), OrderHandler (2). Aus diesem Grund sollte der Rückrufvertrag in der Lage sein, Whitelist und gleichzeitig Rückrufe von mehreren Einlagen, Auftragshandlern und gleichzeitig anzunehmen können Rückzugshandler
Für Rückrufverträge, anstatt einen separaten Whitelisten für Einlagen, Orderhandler und Entschiedene zu unterhalten, besteht eine mögliche Lösung darin, die Rolle des MSG.Sender im Rolestore zu validieren, z RoleStore.hasRole(msg.sender, Role.CONTROLLER) Überprüfen Sie, ob der msg.sender ein gültiger Handler ist
Bei Verwendung von Verträgen wie dem Austauscherouter beachten Oracle oder Reader, dass sich ihre Adressen ändern, wenn eine neue Logik hinzugefügt wird
Wenn Verträge wie der Austauscherouter, Oracle oder Reader aktualisiert werden, sollten Anstrengungen unternommen werden, um die Funktionsparameter gleich zu halten. Dies ist jedoch möglicherweise nicht immer möglich, z. B. wenn eine neue Auftragseigenschaft unterstützt werden soll. muss geändert werden
Der Rolestore und der Datenspeicher für Bereitstellungen sollten sich nicht ändern, wenn sie eine Migration von Geldern aus den vorherigen Verträgen in die neuen Verträge verändert haben
Während der Code strukturiert wurde, um das Risiko einer schreibgeschützten Wiedereinstellung zu minimieren, sollte darauf geachtet werden
Token Airdrops können den Konten von GM -Token -Inhabern auftreten, in denen Verträge, die mit GM -Token integriert sind von Token, die keine Markttoken sind, kann mit dem Wert Keys.MARKET_LIST überprüft werden
ETH -Überweisungen werden mit nativ_token_transfer_gas_limit für die Gasgrenze gesendet. Wenn die Übertragung aufgrund unzureichender Gas oder anderer Fehler fehlschlägt, wird die ETH stattdessen als Weth gesendet
Konten können ETH für ADLs / Liquidationen erhalten. Wenn das Konto keine ETH erhalten kann, wird Weth stattdessen gesendet
Positive Preiswirkung wird durch die Anzahl der Token in den Impact -Pools und basierend auf konfigurierten Werten begrenzt
Negative Preiswirkung kann durch konfigurierte Werte begrenzt werden
Wenn negative Preiswirkung begrenzt wird, würde der zusätzliche Betrag im anspruchsvollen Sicherheitenpool aufbewahrt werden. Dies muss manuell mit dem Austauscherouter beansprucht.
Positive Finanzierungsgebühren müssen manuell unter Verwendung des Austauscherouters beansprucht.
Affiliate -Belohnungen müssen manuell unter Verwendung des Austauscherouters beansprucht.
Märkte oder Funktionen können deaktiviert sein
Die Ausführung wird fortgesetzt, auch wenn sich ein Rückruf zurückversetzt
Stellen Sie sicher, dass Rückrufe ausreichend Gas haben
Unterkonten können jede Bestellung für ein Konto erstellen, aktualisieren und stornieren
Unterkonten können Wnt und Sicherheiten aus dem Konto ausgeben
UI -Gebühren können geändert werden
Überweisungsrabatte können geändert werden
Mittel für die schwarze Liste werden innerhalb des Protokolls aufbewahrt
Der Index -Token ist nicht immer garantiert das lange Token
Die Gebührenquoten ändern sich je nachdem, ob es positive oder negative Auswirkungen gibt
Betrachten Sie den PNL -Faktor bei der Schätzung des GM -Preises
Kaution Stornierungen bearbeiten
Stellen Sie sicher
Stellen Sie sicher
Betrachten Sie Märkte mit dem gleichen langen und kurzen Token. Swaps werden für diese Märkte nicht unterstützt
Betrachten Sie eine positive und negative Preisauswirkungen
Für eine konfigurierte Verzögerung gibt es einen Antragsabstornzeitraum für eine konfigurierte Verzögerung, bei der Einzahlungsanforderungen nicht storniert werden können
Ausgangsbeträge unterliegen den Preiswirkung und Gebühren
Einlagen sind nicht über den max_pnl_factor_for_deposits zulässig
Die erste Einzahlung in einem beliebigen Markt muss zum Empfänger_First_deposit gehen
Für Abhebungen müssen zwei Mindestausgänge verwendet werden
Abhebungsstornierungen bearbeiten
Stellen Sie sicher
Stellen Sie sicher
Betrachten Sie Märkte mit dem gleichen langen und kurzen Token. Swaps werden für diese Märkte nicht unterstützt
Betrachten Sie eine positive und negative Preisauswirkungen
Für eine konfigurierte Verzögerung gibt es einen Antragsabstornzeitraum für eine konfigurierte Verzögerung, bei der Auszahlungsanforderungen nicht storniert werden können
Ausgangsbeträge unterliegen den Preiswirkung und Gebühren
Abhebungen sind nicht über den max_pnl_factor_for_withdrawals zulässig
Auftragsstornierungen behandeln
Liquidationen und ADLs können den gespeicherten Rückrufvertrag auslösen
Bestellungen können gefroren werden
Stellen Sie sicher
Stellen Sie sicher
Berücksichtigen Sie Märkte mit dem gleichen langen und kurzen Token. Swaps werden für diese Märkte nicht unterstützt
Betrachten Sie eine positive und negative Preisauswirkungen
Gespeicherte Rückrufverträge können geändert werden
Für eine konfigurierte Verzögerung gibt es eine Anforderungsstornierungsperiode, bei der Auftragsanforderungen nicht storniert werden können
Ausgangsbeträge unterliegen den Preiswirkung und Gebühren
Der Positions -Impact -Pool wird im Laufe der Zeit an Liquiditätsanbieter verteilt
Wenn der Versuch, die Auswirkungen der Preisauswirkungen zu berechnen, sollte das virtuelle Inventar konsultiert werden
Trader PNL ist über die max_pnl_factor_for_traders bedeckt
Negative Preiswirkung kann auf die Position abnimmt, nimmt ab
Die Verringerung der Bestellung von Sizedelta und Kollateraldelta werden automatisch aufgerichtet, wenn sie größer sind, als die Position umgehen kann
Betrachten Sie die WillenspositionCollateralBefefefaid Validierung
Erwägen Sie eine Verkleinerungswechsel
Berücksichtigen Sie die minimale Sicherheitenbetrag
Überweisungen werden während der Liquidation noch ausgezahlt
Es ist möglich, dass Positionen keine Sicherheiten haben
Positionen mit Nullgröße können nicht existieren
Verträge zusammenstellen:
npx hardhat compile
So führen Sie alle Tests aus:
npx hardhat test
export NODE_OPTIONS=--max_old_space_size=4096 kann zum Ausführen von Tests benötigt werden.
Code -Metriken drucken:
npx ts-node metrics.ts
Testenabdeckung drucken:
npx hardhat coverage
