Architecture and codebase
The repository brings together Solidity contracts, a React/Vite dapp and two Node services. This GitBook is self-contained in gitbook/: its build reads neither private configuration nor protocol network data.
Directories
| Directory | Responsibility |
|---|---|
contracts/src |
Token, hook, libraries, interfaces and peripheral contracts |
contracts/test |
Foundry scenario and invariant tests |
contracts/audit |
Additional verification harnesses and campaigns |
contracts/scripts |
ABI export, checks and deployment procedures |
contracts/deployments |
Public version manifests and history |
dapp/src/chain |
Configuration, ABI, reads, quotes and transactions |
dapp/src/pages |
Swap, Proof, Keepers, roadmap and V2 modules |
services/shared |
Shared configuration, clients, ABI and execution tracking |
services/keeper |
Triggering permissionless operations |
services/floor-bot |
Reading events and preparing posts |
audit/reports |
Dated reports and evidence attached to revisions |
gitbook/docs |
French sources of this documentation |
Core contracts
| Component | Responsibility |
|---|---|
CubitToken |
ERC-20 with a single initial issuance of 21 M; only the hook may burn |
CubitHook |
Taxes, accounting compartments, liquidity, maintenance and V2 connection |
BandLib |
Price calculations, tick conversion and rounding, band geometry |
WallLib |
New linked library for fixed wall positions; revision still awaiting validation |
PoolManager v4 |
Pool state, liquidity positions, swaps and settlement |
The hook is the authorized liquidity provider for the CUBIT pool. Funds are tracked in positions and through the PoolManager’s ERC-6909 claims; the hook address’s native ETH balance is therefore not a sufficient measure of reserves.
WallLib works on the hook’s storage. A linked library does not become a new owner of positions: claims and positions remain allocated to the hook. Library bytecode and linking must be included in deployment verification.
Peripheral contracts
| Component | Responsibility |
|---|---|
CubitRouter |
Exact-input/output swaps, slippage limit, deadline, settlement and final burn on sales |
CubitLens |
Derived views, maintenance states and book reading |
CubitV2 |
Stable module registry, revision and first-bound referrals |
CubitVault |
CUBIT deposits, locking and WETH rewards |
CubitForge |
Curated beta of isolated child markets |
CubitLaunch |
Initial deposit, initialization and optional first taxed purchase in an atomic operation |
Router, Lens, Vault and Forge can be replaced in the registry by the team. The token, hook, pool identities, reward WETH and registry anchor do not follow this replacement mechanism.
The read workflow
Frontend or keeper
→ public manifest: network, core, registry
→ registry at a given block: modules + revision
→ module connection checks
→ Lens and hook views at the same block
→ display or action simulation
In the frontend, releases.ts resolves modules and vault.ts preserves reads from old Vaults. A missing RPC response must not authorize signing.
The swap workflow
The frontend obtains a quote and then a simulation. The router opens the PoolManager’s settlement context; the hook intervenes in the swap to apply taxes and isolate absorbed tokens. The router settles deltas and completes the operations required for the sale.
Boundaries matter: the router callback is accessible only to the PoolManager during the expected operation, and the payer comes from the router’s authenticated caller.
The multiple-wall revision
The WallLib library adds a wall book with permanent IDs and a tick index. Older ticks are preserved; new funds use the current target. Traversal of positions touched during a sale is being validated.
This revision affects invariants, Lens calculations, the frontend, ABIs, services and library deployment. Compilation alone cannot establish compatibility of all these layers with historical Sepolia. Version status.
Sources: named repository files, especially WallLib.Book, WallLib.Wall, CubitHook, releases.ts and service READMEs.