GRVT verfügt über Liquidität, die für eine Person, die auf „Kaufen“ klickt, real sein kann, aber für einen API-Trader unsichtbar und nicht nutzbar ist.
ㅤ
Ich musste diese Regel zweimal lesen.
ㅤ
@grvt_io ruft das Mechanismus „Retail Price Improvement“.
ㅤ
Ausgewählte Market Maker können RPI-Kurse platzieren, die nur von nicht-algorithmischen UI-Nutzern ausgeführt werden können. API-Bestellungen können nicht gegen diese gelangen.
ㅤ
Zum gleichen Preis werden normale Orders zuerst ausgeführt. RPI-Kurse können in der Oberfläche erscheinen, werden aber aus dem API-Orderbuch, dem Ticker „Best Bid/Ask“, aus Impact-Preis-Berechnungen und aus Funding-Rate-Berechnungen ausgeschlossen.
ㅤ
Gekreuzte RPI-Orders können sogar im Matching-Engine aktiv bleiben, während sie vor dem angezeigten Buch verborgen sind.
ㅤ
Der Vorteil ist leicht zu erkennen.
ㅤ
Ein Retail-Taker kann einen besseren Ausführungspreis erhalten, ohne irgendwelche Einstellungen zu ändern, während latenzsensiblen Bots den Kurs nicht unmittelbar nutzen können.
ㅤ
Aber das ist nicht einfach „mehr Liquidität“.
ㅤ
Es ist geschützte Liquidität mit Zugriffsregeln.
ㅤ
Eine Person, die über die Oberfläche handelt, kann einen ausführbaren Preis haben, den ein API-Trader nicht sehen oder erreichen kann. Gleichzeitig können der veröffentlichte beste Bid und Ask einen Kurs auslassen, der für eine Nutzerklasse real ist.
ㅤ
Ich verstehe das Design.
ㅤ
Wenn jedes Algorithmus-System den Kurs erreichen könnte, würde die für Retail beabsichtigte Preisverbesserung wahrscheinlich fast sofort verschwinden.
ㅤ
Dennoch wirft es eine Frage zu Marktdaten auf, die ich nicht ignorieren kann:
ㅤ
Wofür sollte ein Orderbuch stehen — für jede Order innerhalb der Matching-Engine oder nur für die Liquidität, die für alle gleich verfügbar ist?
ㅤ
Traditionelle Finanzen haben jahrelang mit segmentiertem Order-Flow gelebt. Das Onchain-Importieren von RPI bringt den Ausführungsvorteil, aber auch den Trade-off.
ㅤ
Ist das ein faires Schützen für Retail oder der Beginn von zwei verschiedenen Versionen desselben Orderbuchs?
ㅤ
#grvt
ㅤ
Ich musste diese Regel zweimal lesen.
ㅤ
@grvt_io ruft das Mechanismus „Retail Price Improvement“.
ㅤ
Ausgewählte Market Maker können RPI-Kurse platzieren, die nur von nicht-algorithmischen UI-Nutzern ausgeführt werden können. API-Bestellungen können nicht gegen diese gelangen.
ㅤ
Zum gleichen Preis werden normale Orders zuerst ausgeführt. RPI-Kurse können in der Oberfläche erscheinen, werden aber aus dem API-Orderbuch, dem Ticker „Best Bid/Ask“, aus Impact-Preis-Berechnungen und aus Funding-Rate-Berechnungen ausgeschlossen.
ㅤ
Gekreuzte RPI-Orders können sogar im Matching-Engine aktiv bleiben, während sie vor dem angezeigten Buch verborgen sind.
ㅤ
Der Vorteil ist leicht zu erkennen.
ㅤ
Ein Retail-Taker kann einen besseren Ausführungspreis erhalten, ohne irgendwelche Einstellungen zu ändern, während latenzsensiblen Bots den Kurs nicht unmittelbar nutzen können.
ㅤ
Aber das ist nicht einfach „mehr Liquidität“.
ㅤ
Es ist geschützte Liquidität mit Zugriffsregeln.
ㅤ
Eine Person, die über die Oberfläche handelt, kann einen ausführbaren Preis haben, den ein API-Trader nicht sehen oder erreichen kann. Gleichzeitig können der veröffentlichte beste Bid und Ask einen Kurs auslassen, der für eine Nutzerklasse real ist.
ㅤ
Ich verstehe das Design.
ㅤ
Wenn jedes Algorithmus-System den Kurs erreichen könnte, würde die für Retail beabsichtigte Preisverbesserung wahrscheinlich fast sofort verschwinden.
ㅤ
Dennoch wirft es eine Frage zu Marktdaten auf, die ich nicht ignorieren kann:
ㅤ
Wofür sollte ein Orderbuch stehen — für jede Order innerhalb der Matching-Engine oder nur für die Liquidität, die für alle gleich verfügbar ist?
ㅤ
Traditionelle Finanzen haben jahrelang mit segmentiertem Order-Flow gelebt. Das Onchain-Importieren von RPI bringt den Ausführungsvorteil, aber auch den Trade-off.
ㅤ
Ist das ein faires Schützen für Retail oder der Beginn von zwei verschiedenen Versionen desselben Orderbuchs?
ㅤ
#grvt