Architektur und Codebasis
Das Repository umfasst Solidity-Verträge, eine React/Vite-dApp und zwei Node-Dienste. Dieses GitBook ist in gitbook/ eigenständig: Sein Build liest weder private Konfigurationen noch Netzwerkdaten des Protokolls.
Die Verzeichnisse
| Verzeichnis | Zuständigkeit |
|---|---|
contracts/src |
Token, Hook, Bibliotheken, Schnittstellen und Peripherieverträge |
contracts/test |
Foundry-Tests für Szenarien und Invarianten |
contracts/audit |
Ergänzende Testumgebungen und Prüfungskampagnen |
contracts/scripts |
ABI-Export, Prüfungen und Deployment-Verfahren |
contracts/deployments |
Öffentliche Versionsmanifeste und Historie |
dapp/src/chain |
Konfiguration, ABI, Abfragen, Quotierungen und Transaktionen |
dapp/src/pages |
Swap, Proof, Keepers, Roadmap und V2-Module |
services/shared |
Gemeinsame Konfiguration, Clients, ABI und Ausführungsverfolgung |
services/keeper |
Auslösen erlaubnisfreier Operationen |
services/floor-bot |
Abfragen von Ereignissen und Vorbereiten von Veröffentlichungen |
audit/reports |
Datierte Berichte und den Revisionen zugeordnete Nachweise |
gitbook/docs |
Französische Quellen dieser Dokumentation |
Die Kernverträge
| Komponente | Zuständigkeit |
|---|---|
CubitToken |
ERC-20 mit einmaliger anfänglicher Ausgabe von 21 Mio.; Burn nur durch den Hook erlaubt |
CubitHook |
Steuern, Buchhaltungsbereiche, Liquidität, Wartung und V2-Anbindung |
BandLib |
Preisberechnung, Umrechnung und Rundung auf Ticks, Bandgeometrie |
WallLib |
Neue verknüpfte Bibliothek für feste Wall-Positionen; Überarbeitung noch zu validieren |
PoolManager v4 |
Poolzustand, Liquiditätspositionen, Swaps und Abrechnung |
Der Hook ist der für den CUBIT-Pool autorisierte Liquiditätsanbieter. Die Mittel werden in Positionen und über ERC-6909-Claims des PoolManagers verfolgt; das native ETH-Guthaben der Hook-Adresse ist daher kein ausreichendes Maß für die Reserven.
WallLib arbeitet auf dem Speicher des Hooks. Eine verknüpfte Bibliothek ist kein neuer Eigentümer der Positionen: Claims und Positionen bleiben dem Hook zugeordnet. Der Bibliotheksbytecode und die Verknüpfung müssen in die Prüfung eines Deployments einbezogen werden.
Die Peripherieverträge
| Komponente | Zuständigkeit |
|---|---|
CubitRouter |
Exact-Input-/Output-Swaps, Slippage-Grenze, Frist, Abrechnung und abschließender Burn bei Verkäufen |
CubitLens |
Abgeleitete Ansichten, Wartungszustände und Abfrage des Buchs |
CubitV2 |
Stabile Modul-Registry, Revision und First-Bound-Empfehlungen |
CubitVault |
CUBIT-Einlagen, Sperre und WETH-Prämien |
CubitForge |
Kuratierte Beta für isolierte Kindmärkte |
CubitLaunch |
Anfängliche Einlage, Initialisierung und möglicher erster besteuerter Kauf in einem atomaren Vorgang |
Router, Lens, Vault und Forge können vom Team in der Registry ausgetauscht werden. Token, Hook, Poolidentitäten, Prämien-WETH und der Registry-Anker unterliegen diesem Austauschmechanismus nicht.
Der Ablauf einer Abfrage
Frontend oder Keeper
→ öffentliches Manifest: Netzwerk, Kern, Registry
→ Registry an einem bestimmten Block: Module + Revision
→ Prüfung der Modulverknüpfungen
→ Lens und Hook-Ansichten am selben Block
→ Anzeige oder Simulation einer Aktion
Im Frontend löst releases.ts die Module auf, und vault.ts erhält die Abfrage früherer Vaults. Eine fehlende RPC-Antwort darf keine Signatur erlauben.
Der Ablauf eines Swaps
Das Frontend holt eine Quotierung und anschließend eine Simulation ein. Der Router öffnet den Abrechnungskontext des PoolManagers; der Hook greift in den Swap ein, um die Steuern anzuwenden und aufgenommene Token zu isolieren. Der Router gleicht die Deltas aus und schließt die für den Verkauf erforderlichen Vorgänge ab.
Die Grenzen sind wesentlich: Der Router-Callback ist nur für den PoolManager während des erwarteten Vorgangs zugänglich, und der Payer stammt vom authentifizierten Aufrufer des Routers.
Die Überarbeitung für mehrere Walls
Die Bibliothek WallLib ergänzt ein Wall-Buch mit dauerhaften IDs und einem Tick-Index. Bestehende Ticks bleiben erhalten; neue Mittel verwenden das aktuelle Ziel. Das Durchlaufen der bei einem Verkauf betroffenen Positionen wird derzeit validiert.
Diese Überarbeitung betrifft Invarianten, Lens-Berechnungen, Frontend, ABI, Dienste und das Deployment der Bibliotheken. Ihre Kompilierung reicht nicht aus, um alle diese Schichten für mit dem historischen Sepolia kompatibel zu erklären. Versionsstatus.
Quellen: die genannten Dateien im Repository, insbesondere WallLib.Book, WallLib.Wall, CubitHook, releases.ts und die README-Dateien der Dienste.