DeepBook

Czym jest DeepBook?

DeepBook jest natywnym dla Sui, w pełni on‑chainowym protokołem księgi zleceń z limitem (CLOB – central limit order book), zaprojektowanym tak, aby zapewnić wspólne, „hurtowe” źródło płynności, z którego mogą korzystać inne aplikacje w ekosystemie Sui, zamiast zmuszać każdy DEX do samodzielnego uruchamiania odizolowanej płynności we własnych pulach.

Jego podstawowy problem ma charakter strukturalny: handel on‑chain na wielu L1 ma tendencję do fragmentacji pomiędzy AMM‑ami oraz pulami specyficznymi dla danej aplikacji, co tworzy płytkie księgi zleceń, wysokie poślizgi cenowe przy większych zleceniach i kruche mechanizmy routingu.

Przewaga DeepBook – o ile w infrastrukturze DeFi w ogóle można mówić o „fosie konkurencyjnej” – nie wynika z marki, lecz z techniki i dystrybucji: jest on ściśle dopasowany do obiektocentrycznego modelu wykonywania transakcji Sui i stał się domyślnym celem integracji w ekosystemie dla zespołów, które chcą uzyskać księgę zleceń do odkrywania cen bez konieczności budowania całego stosu giełdy od zera. Takie jego pozycjonowanie jest podkreślane w materiałach ekosystemu Sui i przewodnikach dla deweloperów, takich jak techniczne opracowania i referencje integracyjne ukierunkowane na Sui/Mysten (zob. przegląd DeepBook i omówienie wykorzystania w ekosystemie w “Deep Dive into DeepBook” oraz “DeepBook powers DeFi protocols”, a także dokumentację infrastruktury od dostawców takich jak “QuickNode’s DeepBook guide”).

Z punktu widzenia pozycji rynkowej DeepBook powinien być analizowany mniej jako samodzielny, konsumencki DEX, a bardziej jako wspólna infrastruktura rynkowa, której „produktem” jest kompozywowalna płynność i logika dopasowywania zleceń.

Publiczne pulpity, które śledzą DeepBook konkretnie jako protokół (a nie front‑end), zazwyczaj przedstawiają jego skalę w kategoriach TVL oraz wolumenu spot routowanego przez niego; najczęściej cytowanym publicznym zbiorem danych jest strona “DeepBook V3” na DeFiLlama.

Na początku–w połowie 2026 r. zewnętrzni agregatorzy danych rynkowych prezentowali DEEP jako token o średniej kapitalizacji, którego pozycja rynkowa istotnie różniła się w zależności od giełdy i metodologii (na przykład CoinGecko pokazywał pozycję w połowie drugiej setki w migawkach takich jak jego strona DeepBook, podczas gdy CoinMarketCap okresowo wskazywał znacząco wyższe miejsce w rankingu), co podkreśla, że „ranking” jest mało precyzyjną miarą dla aktywa, którego free float, zakres uwzględnianych giełd i założenia dotyczące podaży w obiegu różnią się pomiędzy dostawcami indeksów (CoinGecko, CoinMarketCap).

Kto założył DeepBook i kiedy?

DeepBook pojawił się jako część „tezy dóbr publicznych” ekosystemu Sui, a nie jako typowa marka DEX‑a wydana przez konkretną aplikację. Protokół jest powszechnie opisywany jako open‑source i ściśle powiązany z głównymi instytucjami odpowiedzialnymi za rozwój rdzenia i ekosystemu Sui, co w praktyce oznacza, że wczesna trajektoria DeepBook była kształtowana przez bodźce L1 dążącego do zaszczepienia niezawodnych, on‑chainowych prymitywów płynności dla aplikacji budowanych wyżej w stosie.

Takie ujęcie jest wprost widoczne w komunikacji ekosystemu Sui, która pozycjonuje DeepBook jako natywną warstwę płynności (np. materiały na blogu Sui opisujące go jako infrastrukturę fundamentalną, a nie pojedynczą aplikację) i jest spójne z zewnętrznymi zasobami dla deweloperów, które opisują go jako klocki budulcowe „by Sui Foundation” dla aplikacji w ekosystemie Sui (Sui blog DeepBook deep dive, QuickNode guide).

Z czasem narracja ewoluowała od „na Sui istnieje on‑chainowa księga zleceń” do „DeepBook jest kanonicznym miejscem płynności, przez które routowane są inne produkty” – to subtelna, ale ważna zmiana, ponieważ przesuwa konkurencyjny punkt odniesienia z interfejsów DEX na warstwy infrastruktury płynności.

Nowsze ramy „V3” również mają znaczenie: protokół jest obecnie często wprost określany jako „DeepBook V3” w kontekstach analitycznych i w publicznych hubach dokumentacji kodu, co sygnalizuje cykl iteracji architektonicznej, a nie statyczne wdrożenie (DeFiLlama DeepBook V3, DeepWiki / deepbookv3 technical documentation).

Jak działa sieć DeepBook?

Sam DeepBook nie jest siecią bazową z własnym konsensusem; to aplikacja/protokół on‑chain wdrożony na L1 Sui.

W efekcie jego właściwości w zakresie bezpieczeństwa i finalności są dziedziczone od zbioru walidatorów Sui oraz od tamtejszego łańcucha konsensusu/wykonywania, a nie od dedykowanych dla protokołu górników/walidatorów.

W praktyce oznacza to, że poprawność działania DeepBook zależy od reguł przejścia stanów łańcucha Sui, stopnia decentralizacji walidatorów i założeń dotyczących żywotności sieci, podczas gdy ryzyka specyficzne dla DeepBook koncentrują się w poprawności smart kontraktów, konstrukcji ekonomicznej (opłaty/incentywy) oraz złożoności integracji.

Ten łańcuch zależności jest istotny z perspektywy analizy instytucjonalnej: „przestoje” i odporność na cenzurę DeepBook są tak silne, jak rozproszenie walidatorów Sui i odporność operacyjna samego łańcucha, natomiast jego profil wydajności jest silnie powiązany z równoległym modelem wykonywania Sui, co jest głównym powodem, dla którego natywne dla Sui księgi zleceń prezentuje się jako realną alternatywę wobec wolniejszych, silnie kontendowanych środowisk L1 (Sui blog DeepBook deep dive, QuickNode guide).

Od strony technicznej DeepBook V3 jest udokumentowany jako system księgi zleceń i pul, zaimplementowany w Move, z parametrami na poziomie pul i logiką opłat, które wprost odwołują się w ekosystemie dokumentacji kodu do wyceny DEEP i obliczania opłat. Pokazuje to, że DEEP nie jest jedynie „abstrakcyjnym tokenem governance”, lecz jest w specyficzny dla protokołu sposób wpięty w mechanikę opłat i pul (DeepWiki deepbookv3 order-book system).

Bezpieczeństwo sieci jest więc dwudzielne: walidatorzy Sui zabezpieczają włączanie transakcji do łańcucha, ich kolejność i finalność, natomiast profil bezpieczeństwa samego DeepBook zależy od audytów, testów nastawionych na wykrywanie zachowań adversarialnych oraz dojrzałości zestawu kontraktów V3. Zewnętrzne portale bezpieczeństwa, które odzwierciedlają dane o TVL i podstawowe oceny ryzyka (choć nie są źródłem ostatecznym), podkreślają, że ekosystem traktuje DeepBook jako kluczową infrastrukturę, a nie peryferyjną dApp (CertiK project page, DeFiLlama DeepBook V3).

Jakie są tokenomiki DEEP?

DEEP jest natywnym tokenem powiązanym z DeepBook, zaimplementowanym jako zasób Sui Move (adres kontraktu, który podałeś, odpowiada typowi DEEP w eksploratorach Sui), a publicznie deklarowana maksymalna podaż została przedstawiona jako 10 miliardów tokenów w materiałach DeepBook (DeepBook DEEP token page).

Dane o podaży i free float w obiegu są na rynku stosunkowo spójne w tym sensie, że pokazują istotnie niższą podaż w obiegu niż maksymalna, ale dokładne wartości w obiegu różnią się w zależności od dostawcy danych i daty migawki. Pulpity tokenomiczne, takie jak Tokenomist, publikują wartości podaży w obiegu/całkowitej oraz harmonogramy odblokowań przeznaczone do monitorowania emisji i vestingu, co ma znaczenie, ponieważ tempo odblokowań może w tokenach o średniej kapitalizacji dominować nad fundamentami jako czynnik kształtujący cenę (Tokenomist DEEP tokenomics, DeepBook DEEP token page).

Użyteczność DEEP i mechanizm akumulacji wartości są wyjątkowo „mechaniczne” na tle wielu tokenów governance: dokumentacja DeepBook i zewnętrzne opracowania badawcze giełd opisują governance na poziomie pul, w ramach którego posiadacze tokenów mogą wpływać na takie zmienne jak opłaty transakcyjne czy minimalne wymagania stakingowe, a whitepaper protokołu przedstawia staking jako mechanizm bramkowania i wyrównywania bodźców bezpośrednio powiązany z tym, jak konfigurowane są pule oraz jak równoważą się opłaty i zachęty (DeepBook DEEP token page, DeepBook token whitepaper PDF hosted on Sui docs, Kraken Deepbook asset brief PDF).

Jednocześnie instytucjonalna krytyka jest dość prosta: dopóki skala przechwytywanych opłat lub popyt na wymagany staking nie stanie się strukturalnie duża i trwała, DEEP może zachowywać się jak token governance‑owy i motywacyjny, którego wycena jest w większym stopniu napędzana przez spekulacyjną płynność, harmonogramy emisji i dostępność na giełdach niż przez trwałe, „strumieniowe” przepływy przypominające cash flow. Konstrukcja DeepBook próbuje to ograniczyć, wiążąc governance z ekonomią pul, ale „dowód” ma charakter empiryczny i powinien być oceniany poprzez trwały, organicznie routowany wolumen i trwałość integracji, a nie jednorazowe kampanie z zachętami (DeepBook token whitepaper, DeFiLlama DeepBook V3).

Kto korzysta z DeepBook?

Wykorzystanie należy rozdzielić na (i) spekulacyjny handel samym tokenem DEEP na scentralizowanych giełdach oraz (ii) rzeczywistą użyteczność on‑chain, w której DeepBook jest używany jako miejsce routingu dla swapów/zleceń z limitem przez aplikacje w ekosystemie Sui.

Strony z danymi rynkowymi, które kładą nacisk na „najaktywniejsze pary wymiany”, odzwierciedlają przede wszystkim pierwszy rodzaj aktywności i mogą zawyżać postrzegane znaczenie ekosystemowe, jeśli zostaną zinterpretowane jako miernik wykorzystania protokołu; z kolei pulpity analityczne protokołu, które śledzą TVL oraz wolumen DEX routowany przez DeepBook V3, są bliższymi przybliżeniami rzeczywistej użyteczności on‑chain, choć nadal nieidealnymi, ponieważ „wolumen DEX” może obejmować zachowania zbliżone do wash tradingu napędzanego zachętami, a TVL jest metryką zaszumioną (efekty cen aktywów, skład, różnice w metodologii księgowania) (CoinGecko DEEP markets and rank "). snapshot, DeFiLlama DeepBook V3).

W praktyce dominująca ekspozycja sektorowa DeepBook to natywne dla Sui DeFi, w szczególności rynki spot, agregatory oraz stosy zorientowane na trading, które potrzebują kompozycyjności księgi zleceń zamiast czysto krzywych AMM.

Jeśli chodzi o zidentyfikowaną adopcję, własny „builder hub” DeepBooka i strony ekosystemowe wymieniają integracje z rozpoznawalnymi aplikacjami Sui DeFi (np. Cetus, Aftermath, Bluefin, FlowX, Scallop, Turbos i inne), co ma znaczenie kierunkowe, ponieważ odzwierciedla celowe integracje techniczne, a nie przypadkowe wzmianki, ale nadal powinno być traktowane jako samo-raportowanie ekosystemu, a nie kontraktowa lista „partnerstw” z ujawnionymi wolumenami i warunkami (DeepBook builder hub).

Z instytucjonalnego punktu widzenia najsilniejszym sygnałem adopcji byłby trwały udział w routingu i mierzalna zależność — tj. czy główne platformy tradingowe na Sui domyślnie korzystają z płynności DeepBook do odkrywania cen i egzekucji — coś, co można częściowo monitorować za pomocą zagregowanych pulpitów on-chain zamiast ogłoszeń (DeFiLlama DeepBook V3).

Jakie są ryzyka i wyzwania dla DeepBook?

Ryzyko regulacyjne najlepiej rozumieć w dwóch warstwach: ekspozycji na poziomie protokołu (publikacja oprogramowania, emisja/dystrybucja tokenów i zarządzanie) oraz ekspozycji na poziomie aktywności (prowadzenie lub ułatwianie działalności zbliżonej do giełdy).

Projekt DeepBook jako on-chain’owej księgi zleceń i miejsca zapewniania płynności znajduje się niebezpiecznie blisko wzorca faktów, który regulatorzy wcześniej opisywali przy egzekwowaniu przepisów dotyczących „niezarejestrowanej giełdy” w USA; choć DeepBook to nie EtherDelta i działa na innej sieci i w innym kontekście, historyczna postawa SEC ilustruje, że platformy handlowe w stylu księgi zleceń mogą być przedmiotem kontroli w zależności od tego, jak są obsługiwane, reklamowane oraz kto kontroluje kluczowe interfejsy lub strumienie przychodów (SEC EtherDelta enforcement release).

Według źródeł przeanalizowanych w ramach tego researchu nie ma szeroko raportowanego, specyficznego dla protokołu pozwu w USA lub zdarzenia klasyfikacyjnego związanego z ETF bezpośrednio powiązanego z DeepBook/DEEP; bardziej realistycznym ryzykiem instytucjonalnym jest niepewność regulacyjna wokół tego, czy powiązane z tokenem zarządzanie i ustalanie opłat mogłyby zostać uznane za powiązane z działalnością giełdową, broker-dealerską lub dotyczącą papierów wartościowych, w zależności od dystrybucji, kontroli i oczekiwań ekonomicznych, szczególnie jeśli front-endy lub podmioty stowarzyszone są rozpoznawalnymi punktami zdławienia.

Wektory centralizacji są przede wszystkim dziedziczone z Sui (koncentracja walidatorów, różnorodność klientów, zależności operacyjne) oraz z własnych procesów zarządzania i aktualizacji DeepBook. Nawet jeśli kod jest open-source, praktyczna zdolność do wdrażania aktualizacji, koordynowania integracji i kształtowania domyślnych parametrów może być skupiona w niewielkim zbiorze podmiotów ekosystemu, szczególnie we wczesno- i środkowofazowej infrastrukturze. Oddzielnie, realne są zagrożenia ekonomiczne: DeepBook konkuruje nie tylko z innymi on-chain CLOB-ami, ale także z hubami płynności opartymi na AMM i coraz bardziej zaawansowanymi systemami routingu opartymi na intencjach/solverach, które mogą abstrahować wybór bazowego venue. Jeśli główna płynność na Sui skupi się wokół dominującego AMM lub innego prymitywu płynności, DeepBook może skończyć jako „infrastruktura szukająca przepływu”, gdzie akumulacja wartości tokena (przez wymagania stakingowe i zarządzanie opłatami) dostarcza mniej, niż sugeruje narracja.

Jakie są perspektywy rozwoju DeepBook?

Krótkoterminowe perspektywy najwiarygodniej można opisać jako dalsze dojrzewanie DeepBook V3, pogłębianie integracji z głównymi aplikacjami tradingowymi Sui oraz stopniowe rozszerzanie prymitywów (spot, margin, produkty strukturyzowane) na poziomie ekosystemu, zamiast jednego monolitycznego „DeepBook app”.

Publiczne huby dokumentacji technicznej dla DeepBook V3 i bieżące materiały skierowane do ekosystemu sugerują aktywną iterację, a nie jedynie tryb utrzymaniowy, a dostawcy analityki nadal śledzą go jako odrębną kategorię protokołu z szeregiem czasowym wolumenu/TVL, co implikuje, że pozostaje on strategicznie istotny w ramach Sui DeFi (DeepWiki deepbookv3 documentation, DeFiLlama DeepBook V3).

Strukturalne przeszkody to te, które zazwyczaj decydują, czy „publiczna infrastruktura płynności” staje się trwała: utrzymanie organicznego flow bez stałych subsydiów, zapobieganie fragmentacji płynności między konkurującymi venue, utrzymanie bezpieczeństwa podczas aktualizacji oraz poruszanie się w coraz ciaśniejszej otoczce regulacyjnej wokół prymitywów DeFi przypominających giełdy, szczególnie dla zespołów i interfejsów, które mogą być identyfikowalne nawet wtedy, gdy rdzeniowe kontrakty są permissionless.