Arquitectura y base de código
El repositorio reúne contratos Solidity, un dapp React/Vite y dos servicios Node. Este GitBook es autónomo en gitbook/: su build no lee configuración privada ni datos de red del protocolo.
Los directorios
| Directorio | Responsabilidad |
|---|---|
contracts/src |
Token, hook, bibliotecas, interfaces y contratos periféricos |
contracts/test |
Pruebas de escenarios e invariantes Foundry |
contracts/audit |
Arneses y campañas de verificación complementarios |
contracts/scripts |
Exportación ABI, controles y procedimientos de despliegue |
contracts/deployments |
Manifiestos públicos de versiones e historial |
dapp/src/chain |
Configuración, ABI, lecturas, cotizaciones y transacciones |
dapp/src/pages |
Swap, Proof, Keepers, roadmap y módulos V2 |
services/shared |
Configuración compartida, clientes, ABI y seguimiento de ejecución |
services/keeper |
Ejecución de operaciones permissionless |
services/floor-bot |
Lectura de eventos y preparación de publicaciones |
audit/reports |
Informes fechados y pruebas vinculadas a revisiones |
gitbook/docs |
Fuentes francesas de esta documentación |
Los contratos del núcleo
| Componente | Responsabilidad |
|---|---|
CubitToken |
ERC-20 con emisión inicial única de 21 M; quema autorizada solo al hook |
CubitHook |
Tasas, compartimentos contables, liquidez, mantenimiento y conexión V2 |
BandLib |
Cálculo de precios, conversión y redondeo a ticks, geometría de bandas |
WallLib |
Nueva biblioteca vinculada para posiciones de muros fijos; revisión aún pendiente de validación |
PoolManager v4 |
Estado del pool, posiciones de liquidez, swaps y liquidación |
El hook es el proveedor de liquidez autorizado para el pool CUBIT. Los fondos se siguen en las posiciones y mediante claims ERC-6909 del PoolManager; por tanto, el saldo de ETH nativo de la dirección del hook no basta para medir las reservas.
WallLib trabaja sobre el almacenamiento del hook. Una biblioteca vinculada no es una nueva propietaria de las posiciones: los claims y las posiciones siguen asignados al hook. El bytecode de la biblioteca y su vinculación deben incluirse en la verificación del despliegue.
Los contratos periféricos
| Componente | Responsabilidad |
|---|---|
CubitRouter |
Swaps exact-input/output, límite de slippage, fecha límite, liquidación y quema final de ventas |
CubitLens |
Vistas derivadas, estados de mantenimiento y lectura del libro |
CubitV2 |
Registro estable de módulos, revisión y referidos first-bound |
CubitVault |
Depósitos CUBIT, bloqueo y recompensas WETH |
CubitForge |
Beta curada de mercados hijos aislados |
CubitLaunch |
Depósito inicial, inicialización y posible primera compra con tasa en una operación atómica |
El equipo puede sustituir Router, Lens, Vault y Forge en el registro. El token, el hook, las identidades del pool, el WETH de recompensa y el anclaje del registro no siguen este mecanismo de sustitución.
El recorrido de una lectura
Frontend o keeper
→ manifiesto público: red, núcleo, registro
→ registro en un bloque dado: módulos + revisión
→ comprobación de conexiones de los módulos
→ Lens y vistas del hook en ese mismo bloque
→ visualización o simulación de una acción
En el frontend, releases.ts resuelve los módulos y vault.ts conserva la lectura de los Vaults antiguos. La falta de respuesta RPC no debe autorizar una firma.
El recorrido de un swap
El frontend obtiene una cotización y después una simulación. El router abre el contexto de liquidación del PoolManager; el hook interviene en el swap para aplicar las tasas y aislar los tokens absorbidos. El router liquida los deltas y termina las operaciones necesarias para la venta.
Las fronteras importan: el callback del router solo es accesible al PoolManager durante la operación esperada, y el payer procede del llamante autenticado del router.
La revisión de múltiples muros
La biblioteca WallLib añade un libro de muros con IDs permanentes y un índice de ticks. Se conservan los ticks antiguos; los fondos nuevos utilizan el objetivo actual. El recorrido de las posiciones alcanzadas durante una venta está en validación.
Esta revisión afecta a invariantes, cálculos del Lens, frontend, ABI, servicios y despliegue de bibliotecas. Compilarla no basta para declarar todas esas capas compatibles con la Sepolia histórica. Estado de las versiones.
Fuentes: archivos citados del repositorio, especialmente WallLib.Book, WallLib.Wall, CubitHook, releases.ts y los README de los servicios.