Architecture et codebase
Le dépôt réunit les contrats Solidity, un dapp React/Vite et deux services Node. Ce GitBook est autonome dans gitbook/ : son build ne lit ni configuration privée ni données réseau du protocole.
Les répertoires
| Répertoire | Responsabilité |
|---|---|
contracts/src |
Token, hook, bibliothèques, interfaces et contrats périphériques |
contracts/test |
Tests de scénarios et invariants Foundry |
contracts/audit |
Harnais et campagnes de vérification complémentaires |
contracts/scripts |
Export ABI, contrôles et procédures de déploiement |
contracts/deployments |
Manifestes publics de versions et historique |
dapp/src/chain |
Configuration, ABI, lectures, cotations et transactions |
dapp/src/pages |
Swap, Proof, Keepers, roadmap et modules V2 |
services/shared |
Configuration partagée, clients, ABI et suivi d’exécution |
services/keeper |
Déclenchement des opérations permissionless |
services/floor-bot |
Lecture des événements et préparation de publications |
audit/reports |
Rapports datés et preuves attachées aux révisions |
gitbook/docs |
Sources françaises de cette documentation |
Les contrats du cœur
| Composant | Responsabilité |
|---|---|
CubitToken |
ERC-20 à émission initiale unique de 21 M ; burn autorisé uniquement au hook |
CubitHook |
Taxes, compartiments comptables, liquidité, maintenance et raccordement V2 |
BandLib |
Calcul des prix, conversion et arrondis aux ticks, géométrie des bandes |
WallLib |
Nouvelle bibliothèque liée pour les positions de murs fixes ; révision encore à valider |
PoolManager v4 |
État du pool, positions de liquidité, swaps et règlement |
Le hook est le fournisseur de liquidité autorisé pour le pool CUBIT. Les fonds sont suivis dans les positions et via des claims ERC-6909 du PoolManager ; le solde ETH natif de l’adresse du hook n’est donc pas une mesure suffisante des réserves.
WallLib travaille sur le stockage du hook. Une bibliothèque liée n’est pas un nouveau propriétaire des positions : les claims et les positions restent attribués au hook. Le bytecode de bibliothèque et le linking doivent être compris dans la vérification d’un déploiement.
Les contrats périphériques
| Composant | Responsabilité |
|---|---|
CubitRouter |
Swaps exact-input/output, limite de slippage, deadline, settlement et burn final des ventes |
CubitLens |
Vues dérivées, états de maintenance et lecture du carnet |
CubitV2 |
Registre stable des modules, révision et parrainage first-bound |
CubitVault |
Dépôts CUBIT, verrouillage et rewards WETH |
CubitForge |
Bêta curée de marchés enfants isolés |
CubitLaunch |
Dépôt initial, initialisation et éventuel premier achat taxé dans une opération atomique |
Router, Lens, Vault et Forge peuvent être remplacés dans le registre par l’équipe. Le token, le hook, les identités du pool, le WETH de récompense et l’ancre du registre ne suivent pas ce mécanisme de remplacement.
Le parcours d’une lecture
Frontend ou keeper
→ manifeste public : réseau, cœur, registre
→ registre à un bloc donné : modules + révision
→ contrôle des liaisons des modules
→ Lens et vues du hook à ce même bloc
→ affichage ou simulation d’une action
Dans le frontend, releases.ts résout les modules et vault.ts conserve la lecture des anciens Vaults. Une absence de réponse RPC ne doit pas autoriser une signature.
Le parcours d’un swap
Le frontend obtient une cotation puis une simulation. Le routeur ouvre le contexte de règlement du PoolManager ; le hook intervient dans le swap pour appliquer les taxes et isoler les tokens absorbés. Le routeur règle les deltas et termine les opérations nécessaires à la vente.
Les frontières sont importantes : le callback du routeur n’est accessible qu’au PoolManager pendant l’opération attendue, et le payer vient du caller authentifié du routeur.
La révision multi-murs
La bibliothèque WallLib ajoute un carnet de murs par IDs permanents et un index des ticks. Les anciens ticks sont conservés ; les nouveaux fonds utilisent la cible courante. Le parcours des positions touchées lors d’une vente est en cours de validation.
Cette révision touche les invariants, les calculs du Lens, le frontend, les ABI, les services et le déploiement des bibliothèques. Sa compilation ne suffit pas à déclarer toutes ces couches compatibles avec le Sepolia historique. Statut des versions.
Sources : fichiers nommés du dépôt, en particulier WallLib.Book, WallLib.Wall, CubitHook, releases.ts et les README des services.