DeepBook

Qu’est‑ce que DeepBook ?

DeepBook est le protocole de carnet d’ordres centralisé (CLOB) entièrement on‑chain natif de Sui, conçu pour offrir un lieu de liquidité « de gros » mutualisé dans lequel les autres applications Sui peuvent se composer, au lieu de forcer chaque DEX à créer sa propre liquidité isolée dans des pools séparés.

Son problème de base est structurel : sur de nombreuses L1, le trading on‑chain a tendance à se fragmenter entre AMM et pools spécifiques aux applications, ce qui crée des carnets peu profonds, une forte glissance pour les gros ordres et un routage fragile.

L’avantage compétitif de DeepBook, dans la mesure où il en existe un dans l’infrastructure DeFi, ne tient pas au marketing mais à la technique et à la distribution : il est étroitement aligné avec le modèle d’exécution centré sur les objets de Sui et est devenu une cible d’intégration par défaut dans l’écosystème pour les équipes qui souhaitent une découverte de prix de type carnet d’ordres sans devoir exploiter toute une pile d’échange depuis zéro, un positionnement mis en avant dans les supports de l’écosystème Sui et les guides d’outillage développeur, comme les analyses techniques et références d’intégration orientées Sui/Mysten (voir la présentation de DeepBook et la discussion sur son usage dans l’écosystème sur le blog Sui dans “Deep Dive into DeepBook” et “DeepBook powers DeFi protocols”, ainsi que la documentation d’infrastructure de prestataires comme “QuickNode’s DeepBook guide”).

En termes de positionnement sur le marché, DeepBook doit être analysé moins comme un DEX autonome orienté grand public que comme une infrastructure de marché mutualisée dont le « produit » est la liquidité composable et la logique de matching.

Les tableaux de bord publics qui suivent spécifiquement DeepBook en tant que protocole (plutôt qu’en tant que front‑end) présentent généralement son échelle en termes de TVL et de volume spot routé, le jeu de données public le plus fréquemment cité étant la page “DeepBook V3” sur DeFiLlama.

À partir du début‑milieu de l’année 2026, les agrégateurs de données de marché tiers montraient DEEP comme un token de capitalisation moyenne dont le rang par market cap variait sensiblement selon la plateforme et la méthodologie (par exemple, CoinGecko affichait un rang autour du milieu du classement dans des instantanés comme sa page DeepBook, tandis que CoinMarketCap a parfois indiqué un rang nettement plus élevé), ce qui rappelle que le « rang » est un indicateur imprécis pour un actif dont le flottant, la couverture par les plateformes et les hypothèses sur l’offre en circulation peuvent différer selon les fournisseurs d’indice (CoinGecko, CoinMarketCap).

Qui a fondé DeepBook et quand ?

DeepBook est apparu dans le cadre de la thèse « biens publics » de l’écosystème Sui plutôt que comme une marque de DEX émise par une application classique. Le protocole est généralement décrit comme open source et étroitement associé aux entités responsables du développement cœur et de l’écosystème de Sui, avec pour implication pratique que la trajectoire initiale de DeepBook a été façonnée par les incitations d’une L1 cherchant à mettre en place des primitives de liquidité on‑chain fiables pour les applications en aval.

Ce cadrage est explicite dans les communications de l’écosystème Sui qui présentent DeepBook comme une couche de liquidité native (par exemple, les articles de blog de Sui le décrivant comme une infrastructure fondatrice plutôt qu’une application unique), et il est cohérent avec les ressources destinées aux développeurs externes qui le décrivent comme un bloc de construction « par la Sui Foundation » pour les applications Sui (Sui blog DeepBook deep dive, QuickNode guide).

Au fil du temps, le récit est passé de « il existe un carnet d’ordres on‑chain sur Sui » à « DeepBook est le lieu de liquidité canonique par lequel les autres produits font transiter leurs ordres », un changement subtil mais important car il déplace l’ensemble concurrent pertinent des interfaces de DEX vers les couches d’infrastructure de liquidité.

Le cadrage plus récent autour de la « V3 » est également significatif : le protocole est désormais fréquemment désigné explicitement sous le nom de « DeepBook V3 » dans les contextes d’analytique et dans les hubs publics de documentation de code, ce qui signale un cycle d’itération architecturale plutôt qu’un déploiement statique (DeFiLlama DeepBook V3, DeepWiki / deepbookv3 technical documentation).

Comment fonctionne le réseau DeepBook ?

DeepBook n’est pas lui‑même un réseau de couche de base avec son propre consensus ; c’est une application/un protocole on‑chain déployé sur la L1 Sui.

En conséquence, ses propriétés de sécurité et de finalité sont héritées de l’ensemble de validateurs de Sui et du pipeline de consensus/exécution, plutôt que de mineurs/validateurs spécifiques au protocole.

Concrètement, cela signifie que la justesse de DeepBook dépend des règles de transition d’état de la chaîne Sui, du degré de décentralisation des validateurs et des hypothèses de vivacité, tandis que le risque propre à DeepBook se concentre dans la robustesse des smart contracts, la conception économique (frais/incitations) et la complexité d’intégration.

Cette chaîne de dépendance est importante pour l’analyse institutionnelle : les affirmations de DeepBook en matière de « temps de disponibilité » et de résistance à la censure ne sont solides que dans la mesure où la distribution des validateurs de Sui et la résilience opérationnelle de la chaîne le sont, tandis que son profil de performance est fortement lié au design d’exécution parallèle de Sui, qui est la principale raison pour laquelle les carnets d’ordres natifs Sui sont présentés comme viables par rapport à des environnements L1 plus lents et fortement congestionnés (Sui blog DeepBook deep dive, QuickNode guide).

Sur le plan technique, DeepBook V3 est documenté comme un système de carnet d’ordres et de pools implémenté en Move, avec des paramètres au niveau des pools et une logique de frais qui font explicitement référence à la tarification du token DEEP et aux calculs de frais dans l’écosystème de documentation au niveau du code, illustrant que DEEP n’est pas seulement un « token de gouvernance abstrait », mais qu’il est intégré dans la mécanique des frais et des pools de manière propre au protocole (DeepWiki deepbookv3 order-book system).

La sécurité du réseau est donc bifurquée : les validateurs de Sui sécurisent l’inclusion, l’ordre et la finalité des transactions, tandis que le profil de sécurité propre à DeepBook dépend des audits, des tests adversariaux et de la maturité de sa suite de contrats V3 ; les portails de sécurité tiers qui reflètent les données de TVL et des scores de risque basiques (sans être pour autant des références définitives) soulignent que l’écosystème le traite comme une infrastructure centrale plutôt qu’une simple dApp périphérique (CertiK project page, DeFiLlama DeepBook V3).

Quelle est la tokenomics de DEEP ?

DEEP est le token natif associé à DeepBook, implémenté comme un actif Sui Move (l’adresse de contrat que vous avez fournie correspond au type DEEP sur les explorateurs Sui), et l’offre maximale a été publiquement présentée comme 10 milliards de tokens dans les supports officiels de DeepBook (DeepBook DEEP token page).

Les métriques d’offre et de flottant disponibles publiquement ont été relativement cohérentes pour indiquer une offre en circulation nettement inférieure au maximum, mais les valeurs exactes en circulation varient selon le fournisseur de données et la date de l’instantané ; des tableaux de bord de tokenomics comme Tokenomist ont publié des chiffres d’offre en circulation/totale et des calendriers de déverrouillage destinés au suivi des émissions et de l’acquisition, ce qui est important car le rythme de déverrouillage peut dominer la dynamique de prix des actifs de capitalisation moyenne indépendamment de leurs fondamentaux (Tokenomist DEEP tokenomics, DeepBook DEEP token page).

L’utilité et la capture de valeur de DEEP sont de nature particulièrement « mécaniste » comparées à beaucoup de tokens de gouvernance : la documentation de DeepBook et les notes de recherche publiées par des plateformes d’échange décrivent une gouvernance au niveau des pools dans laquelle les détenteurs de tokens peuvent influencer des variables comme les frais de trading et les exigences minimales de staking, et le whitepaper du protocole présente le staking comme un mécanisme de filtrage et d’alignement des incitations directement lié à la façon dont les pools sont configurés et à la manière dont les frais/incitations s’équilibrent (DeepBook DEEP token page, DeepBook token whitepaper PDF hosted on Sui docs, Kraken Deepbook asset brief PDF).

Cela dit, la critique institutionnelle est simple : à moins que la capture de frais ou la demande de staking obligatoire ne deviennent structurellement importantes et durables, DEEP peut se comporter comme un token de gouvernance et d’incitation dont la valorisation est davantage guidée par la liquidité spéculative, les calendriers d’émission et l’accès aux plateformes que par des droits sur des flux de trésorerie durables ; la conception de DeepBook cherche à atténuer cela en reliant la gouvernance à l’économie des pools, mais la « preuve » est empirique et doit être évaluée à travers un volume routé soutenu et organique, ainsi que par la pérennité des intégrations, plutôt que par des campagnes d’incitation ponctuelles (DeepBook token whitepaper, DeFiLlama DeepBook V3).

Qui utilise DeepBook ?

L’usage doit être décomposé entre (i) le trading spéculatif du token DEEP lui‑même sur les plateformes centralisées et (ii) la véritable utilité on‑chain où DeepBook est utilisé comme lieu de routage pour les swaps/ordres à cours limité par les applications Sui.

Les pages de données de marché qui mettent en avant les « paires les plus actives » capturent principalement le premier aspect et peuvent surestimer la pertinence dans l’écosystème si elles sont interprétées comme une mesure de l’utilisation du protocole ; à l’inverse, les pages d’analytique de protocole qui suivent la TVL et le volume DEX routé via DeepBook V3 sont des indicateurs plus proches d’une utilité on‑chain réelle, même s’ils restent imparfaits car le « volume DEX » peut inclure des comportements de type wash trading motivés par des incitations, et la TVL peut être une métrique bruitée (effets de prix des actifs, composition et différences comptables) ([CoinGecko DEEP markets and rank …]) snapshot](https://www.coingecko.com/en/coins/deepbook/usd), DeFiLlama DeepBook V3).

Dans la pratique, l’exposition sectorielle dominante de DeepBook concerne la DeFi native à Sui, en particulier les plateformes de trading au comptant, les agrégateurs et les piles orientées trading qui recherchent la composabilité d’un carnet d’ordres plutôt que de simples courbes d’AMM.

En matière d’adoption identifiable, le propre « builder hub » de DeepBook et ses pages écosystème répertorient des intégrations avec des applications DeFi Sui reconnues (par exemple, Cetus, Aftermath, Bluefin, FlowX, Scallop, Turbos et d’autres), ce qui est significatif sur le plan directionnel car cela reflète des intégrations techniques délibérées plutôt que de simples mentions occasionnelles, mais cela doit tout de même être considéré comme un auto‑rapport de l’écosystème plutôt qu’une liste de « partenariats » contractuels avec volumes et conditions divulgués (DeepBook builder hub).

Du point de vue institutionnel, le signal d’adoption le plus solide serait une part de routage persistante et une dépendance mesurable — c’est‑à‑dire la question de savoir si les principales plateformes de trading sur Sui s’appuient par défaut sur la liquidité de DeepBook pour la découverte des prix et l’exécution — ce qui peut être partiellement surveillé via des tableaux de bord agrégés on‑chain plutôt que via des annonces (DeFiLlama DeepBook V3).

Quels sont les risques et les défis pour DeepBook ?

L’exposition réglementaire se conçoit au mieux en deux couches : l’exposition au niveau du protocole (publication de logiciels, émission/distribution de tokens et gouvernance) et l’exposition au niveau de l’activité (exploitation ou facilitation de fonctionnalités assimilables à un échange).

La conception de DeepBook en tant que carnet d’ordres on‑chain et place de liquidité se situe inconfortablement près du schéma factuel que les régulateurs ont déjà décrit lors de procédures liées à des activités de « bourse non enregistrée » aux États‑Unis ; bien que DeepBook ne soit pas EtherDelta et opère sur une autre blockchain et dans un autre contexte, la position historique de la SEC illustre que les plateformes de trading de type carnet d’ordres peuvent être examinées de près selon la manière dont elles sont exploitées, commercialisées, et selon qui contrôle les principales interfaces ou sources de revenus SEC EtherDelta enforcement release.

À ce jour, d’après les sources examinées dans ce travail de recherche, il n’existe pas d’action en justice largement rapportée, spécifique au protocole, aux États‑Unis, ni d’événement de classification lié à un ETF directement associé à DeepBook/DEEP ; le risque institutionnel le plus réaliste tient à l’incertitude réglementaire quant à la possibilité que la gouvernance et la fixation des frais liées au token puissent être considérées comme impliquant des problématiques de bourse, d’intermédiaire financier (broker‑dealer) ou de valeurs mobilières, en fonction de la distribution, du contrôle et des attentes économiques, en particulier si les front‑ends ou les entités affiliées constituent des points de contrôle identifiables.

Les vecteurs de centralisation sont principalement hérités de Sui (concentration des validateurs, diversité des clients, dépendances opérationnelles) et des propres mécanismes de gouvernance et de mise à jour de DeepBook. Même si le code est open source, la capacité pratique à livrer des mises à jour, coordonner les intégrations et définir les paramètres par défaut peut être concentrée entre un petit nombre d’acteurs de l’écosystème, surtout pour une infrastructure en phase de cycle précoce à intermédiaire. Par ailleurs, les menaces économiques sont réelles : DeepBook ne concurrence pas seulement d’autres CLOB on‑chain mais aussi des hubs de liquidité basés sur des AMM et des systèmes de routage par intents/solvers de plus en plus sophistiqués qui peuvent abstraire le choix du venue sous‑jacent. Si la principale liquidité sur Sui se concentre autour d’un AMM dominant ou d’un autre primitif de liquidité, DeepBook peut se retrouver comme une « infrastructure en quête de flux », où la captation de valeur par le token (via les exigences de staking et la gouvernance des frais) sous‑performe par rapport au récit.

Quelles sont les perspectives d’avenir pour DeepBook ?

Les perspectives à court terme se comprennent le plus crédiblement comme une poursuite de la maturation de DeepBook V3, un approfondissement de l’intégration au sein des principales applications de trading de Sui, et une extension progressive des primitives (spot, marge, produits structurés) au niveau de l’écosystème plutôt qu’au travers d’une unique « application DeepBook » monolithique.

Les hubs de documentation technique publique pour DeepBook V3 et les supports continus à destination de l’écosystème suggèrent une posture d’itération active plutôt qu’un simple mode maintenance, et les fournisseurs d’analyses continuent de le suivre comme une catégorie de protocole distincte avec des séries temporelles de volumes/TVL routés, ce qui implique qu’il reste stratégiquement pertinent au sein de la DeFi sur Sui (DeepWiki deepbookv3 documentation, DeFiLlama DeepBook V3).

Les obstacles structurels sont ceux qui déterminent généralement si une « infrastructure de liquidité considérée comme bien public » devient durable : maintenir des flux organiques sans subvention persistante, éviter la fragmentation de la liquidité entre venues concurrentes, préserver la sécurité au fil des mises à jour, et naviguer dans un périmètre de conformité de plus en plus strict autour des primitives DeFi assimilables à des bourses, en particulier pour les équipes et interfaces qui peuvent être identifiables même lorsque les contrats de base sont permissionless.