Heute sprechen wir über Builder Codes von @grvt_io: Schau nicht nur auf „offene APIs“ – das ist eine Weichenstellung in der GRVT-Architektur. In dem vergangenen Jahr drehte sich die DEX-Debatte um „vollständig On-Chain-Matching vs. Off-Chain-Matching + On-Chain-Abrechnung“. GRVT hat den zweiten Weg gewählt: Das CLOB läuft Off-Chain, die Latenz wird auf CEX-Niveau gedrückt. Der Preis dafür ist, dass die Matching-Schicht geschlossen ist; Market-Maker- und Strategie-Teams können nur die offiziellen APIs anpassen. Builder Codes heben den Einstieg von der API auf die On-Chain-Authorisierungsebene: Externe Builder erhalten über eine einmalige on-chain-Authorisierung (Bindung von main_account_id und builder_account_id) die Berechtigung, Nutzer-Proxy-Rechte zu nutzen. Auf derselben atomaren Abrechnungs-Chain signieren, matchen und clearen sie, und sie teilen die Erlöse entsprechend dem Order-Volumen. Was ändert sich dadurch?
1) GRVT verschiebt sich von der Position „Matching-Exchange“ hin zu „Matching-Infrastruktur“: Market Maker, Strategie- und Terminal-Teams können das Trading-Erlebnis im Frontend individuell gestalten;
2) Der private Schlüssel des Users wird nicht ausgelagert: Der Builder erhält nur einen eingeschränkten Signing Key. Die Grenze des Custody unterscheidet sich grundlegend von dem Weg wie bei Hyperliquid (eigenes L1 + eigener Konsens);
3) Der Matching-Flywheel erweitert sich von „proprietärem Traffic“ zu „gesamtem Ökosystem-Traffic“. Tealstreet und Hummingbot sind bereits integriert.
Der eigentliche Trade-off liegt in der Zentralisierung der Matching-Schicht sowie in der vollständigen On-Chain-Abrechnung mit User-Selbst-Custody. Das ist der grundlegende Abzweig zu Hyperliquid. #grvt