Contratti e integrazione
Un’integrazione deve identificare catena, nucleo del pool, ABI e revisione dei moduli. Un indirizzo di router copiato da un vecchio rapporto può essere sostituito; una nuova ABI locale può essere incompatibile con il pool ancora distribuito.
Le viste a più muri seguenti descrivono l’API in preparazione. Non vengono annunciate come disponibili su Sepolia storico. Esporta l’ABI della release validata e verifica i runtime prima di collegare un client.
Identità del pool
La PoolKey contiene currency0, currency1, fee, tickSpacing e hooks. Per CUBIT, ETH nativo è currency0 e il token CUBIT è currency1.
| Campo | Lettura prevista |
|---|---|
currency0 |
Indirizzo zero, che rappresenta ETH nativo |
currency1 |
Token del deployment identificato |
fee |
100 nella nuova versione prevista; 3000 su Sepolia storico |
tickSpacing |
10 nelle fonti lette |
hooks |
Hook del deployment identificato |
Il poolId dipende dall’intera chiave. Sostituire solo fee in un frontend non trasforma un vecchio pool in un nuovo deployment.
Risolvere i moduli allo stesso blocco
Leggi prima il registro ancorato in hook.v2(). Poi risolvi gli indirizzi dei moduli disponibili e moduleRevision allo stesso blocco. Verifica il loro collegamento al nucleo.
Ecco un frammento di sola lettura, da usare con un client viem già configurato e un indirizzo di registro verificato:
import { parseAbi, type Address, type PublicClient } from "viem";
const registryAbi = parseAbi([
"function router() view returns (address)",
"function moduleRevision() view returns (uint256)",
]);
export async function readRelease(
client: PublicClient,
registry: Address,
) {
const blockNumber = await client.getBlockNumber();
const [router, revision] = await Promise.all([
client.readContract({ address: registry, abi: registryAbi,
functionName: "router", blockNumber }),
client.readContract({ address: registry, abi: registryAbi,
functionName: "moduleRevision", blockNumber }),
]);
return { blockNumber, router, revision };
}
Questo frammento non verifica da solo tutti i collegamenti e non autorizza alcuna firma. Il frontend del repository li controlla in resolveRelease, readRelease e assertCurrentDeployment.
Prima di ogni firma, confronta moduli e revisione con il contesto già esaminato dall’utente. Non reindirizzare silenziosamente un’approvazione.
Leggere più muri
| Vista dell’hook prevista | Risultato / utilizzo |
|---|---|
wallCount() |
Numero di identificatori storici, distinto dal numero di posizioni attive |
activeWallCount() |
Numero di muri attivi nello stato letto |
activeWallId(index) |
ID permanente a un indice dell’elenco attivo corrente |
latestWallId() |
ID dell’ultimo muro finanziato; verificare prima che esista un muro |
walls(id) |
(int24 lower, uint128 liquidity, uint256 idleEth, uint256 fundedEth) |
wallIdleEth() |
Totale dei residui ETH assegnati ai muri |
Gli indici dell’elenco attivo possono cambiare dopo un assorbimento. Conserva l’ID del muro come identità, non il suo indice di iterazione. Leggi il conteggio e gli elementi allo stesso blocco.
fundedEth rappresenta il totale cumulativo dei nuovi fondi effettivamente collocati a quel tick. Non va mostrato come profondità residua. idleEth rappresenta un residuo legato al muro, distinto dalla liquidità collocata.
Il limite superiore di un intervallo è lower + tickSpacing. Gli asset presenti si calcolano con la geometria e il prezzo corrente oppure tramite le viste del Lens adattate alla versione. Le nuove commissioni ancora libere per il collocamento restano separate in pendingFloorEth.
I campi storici floorPrice e netFloorPrice non riassumono più tutti i livelli. Il riferimento dell’ultimo muro finanziato può scendere quando scende l’obiettivo corrente; i tick dei muri già creati restano fissi.
Unità e orientamento
Le quantità di CUBIT ed ETH usano 18 decimali. I prezzi derivati dal Lens sono espressi in ETH per CUBIT su scala 1e18. Il tick v4 segue l’orientamento CUBIT per ETH; diminuisce quando il prezzo ETH per CUBIT aumenta.
Usa interi bigint per importi e calcoli prima della formattazione. Una conversione troppo precoce in Number può perdere precisione. La base “7k” viene interpretata come 7 000 USD di FDV su 21 milioni di CUBIT: la sua conversione in ETH va registrata prima del deployment, poi il prezzo iniziale resta fisso. Non mescolare USD, wei e unità di token.
I metodi del router
swapExactIn(
PoolKey key, bool zeroForOne,
uint256 amountIn, uint256 amountOutMin,
address recipient, uint256 deadline
)
swapExactOut(
PoolKey key, bool zeroForOne,
uint256 amountOut, uint256 amountInMax,
address recipient, uint256 deadline
)
zeroForOne = true compra CUBIT con ETH. Per exact-input, fornisci amountIn come value; per un acquisto exact-output, fornisci amountInMax, con rimborso dell’eccedenza. Una vendita usa zeroForOne = false, value zero e un’approvazione CUBIT al router.
Gli importi restituiti seguono i limiti netti/lordi del router: uscita netta per exact-input, ingresso lordo per exact-output. Il contratto controlla i riempimenti incompleti. La quotazione va simulata con la chiave corretta del pool e la relativa versione.
Eventi ed errori
Gli eventi storici comprendono BuyTaxed, SellTaxed, FloorRaised, SweepExecuted, TokensBurned e BountyPaid. ModuleUpdated permette di seguire le sostituzioni dei moduli; ReferralBound descrive un legame di referral.
La nuova libreria aggiunge WallFunded e WallAbsorbed con l’ID interessato. I log di una libreria eseguita nel contesto dell’hook vanno indicizzati sull’indirizzo emittente dell’hook e con le firme ABI corrispondenti.
FloorRaised conserva un nome storico; il nome non basta a concludere che tutti i livelli salgano. Un relay deve interpretare il finanziamento del muro identificato e la politica della release.
Nel router, gestisci in particolare Expired, WrongPool, TooLittleReceived, TooMuchRequested, InsufficientOutput e IncompleteInput. Per la manutenzione, gli errori di ammissibilità e quelli RPC sono distinti. Rileggi codici e ABI dopo la validazione a più muri.
Fonti: interfaces/ICubitHook.sol, interfaces/ICubitLens.sol, WallLib.sol, CubitRouter.sol e dapp/src/chain. API dei muri redatta durante l’implementazione, il 10 settembre 2026.