Contrats et intégration

Une intégration doit identifier la chaîne, le cœur du pool, l’ABI et la révision des modules. Une adresse de routeur copiée dans un ancien rapport peut être remplacée ; une nouvelle ABI locale peut être incompatible avec le pool encore déployé.

Les vues multi-murs ci-dessous décrivent l’API en préparation. Elles ne sont pas annoncées comme disponibles sur le Sepolia historique. Exportez l’ABI de la release validée et vérifiez les runtimes avant de raccorder un client.

Identité du pool

La PoolKey contient currency0, currency1, fee, tickSpacing et hooks. Pour CUBIT, ETH natif est currency0 et le token CUBIT est currency1.

Le poolId dépend de toute cette clé. Remplacer seulement fee dans un frontend ne transforme pas un ancien pool en nouveau déploiement.

Résoudre les modules à un même bloc

Lisez d’abord le registre ancré dans hook.v2(). Puis résolvez les adresses des modules disponibles et moduleRevision au même bloc. Vérifiez leur raccordement au cœur.

Voici un fragment de lecture seule, à utiliser avec un client viem déjà configuré et une adresse de registre vérifiée :

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 };
}

Ce fragment ne vérifie pas à lui seul toutes les liaisons et n’autorise aucune signature. Le frontend du dépôt les contrôle dans resolveRelease, readRelease et assertCurrentDeployment.

Avant chaque signature, comparez les modules et la révision avec le contexte déjà revu par l’utilisateur. Ne redirigez pas silencieusement une approval.

Lire plusieurs murs

Les index de la liste active peuvent changer après une absorption. Conservez l’ID du mur comme identité, pas son index de parcours. Lisez le count et les éléments au même bloc.

fundedEth représente le cumul des nouveaux fonds effectivement placés à ce tick. Il ne doit pas être affiché comme la profondeur restante. idleEth représente un reliquat attaché au mur, distinct de sa liquidité déployée.

La borne supérieure d’une plage est lower + tickSpacing. Les actifs présents se calculent avec la géométrie et le prix courant, ou via les vues du Lens adaptées à cette version. Les nouveaux frais encore libres de placement restent séparés dans pendingFloorEth.

Les champs historiques floorPrice et netFloorPrice ne résument plus tous les niveaux. La référence du dernier mur financé peut baisser quand la cible courante baisse ; les ticks des murs déjà créés restent fixes.

Unités et orientation

Les quantités de CUBIT et d’ETH utilisent 18 décimales. Les prix dérivés du Lens sont exprimés en ETH par CUBIT à l’échelle 1e18. Le tick v4 suit l’orientation CUBIT par ETH ; il diminue quand le prix ETH par CUBIT augmente.

Utilisez des entiers bigint pour les montants et les calculs avant formatage. Une conversion en Number trop tôt peut perdre de la précision. La base « 7k » est interprétée comme 7 000 USD de FDV sur 21 millions de CUBIT : sa conversion en ETH doit être enregistrée avant le déploiement, puis le prix initial demeure fixe. Ne mélangez pas USD, wei et token units.

Les méthodes du routeur

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 achète des CUBIT avec des ETH. Pour exact-input, fournissez amountIn en value ; pour un achat exact-output, fournissez amountInMax, avec remboursement du surplus. Une vente passe zeroForOne = false, value zéro, et une approval CUBIT au routeur.

Les montants retournés suivent les limites nettes/brutes du routeur : sortie nette pour exact-input, entrée brute pour exact-output. Le contrat contrôle les remplissages incomplets. La cotation doit être simulée avec la bonne clé de pool et sa version.

Événements et erreurs

Les événements historiques comprennent BuyTaxed, SellTaxed, FloorRaised, SweepExecuted, TokensBurned et BountyPaid. ModuleUpdated permet de suivre les remplacements de modules ; ReferralBound décrit un lien de parrainage.

La nouvelle bibliothèque ajoute WallFunded et WallAbsorbed avec l’ID concerné. Les logs d’une bibliothèque exécutée dans le contexte du hook doivent être indexés sur l’adresse émettrice du hook et avec les signatures ABI correspondantes.

FloorRaised conserve un nom historique ; son nom ne suffit pas à conclure que tous les niveaux montent. Un relais doit interpréter le financement du mur identifié et la politique de la release.

Dans le routeur, traitez notamment Expired, WrongPool, TooLittleReceived, TooMuchRequested, InsufficientOutput et IncompleteInput. Pour la maintenance, les erreurs d’éligibilité et les erreurs RPC sont distinctes. Relisez les codes et l’ABI après validation multi-murs.

Sources : interfaces/ICubitHook.sol, interfaces/ICubitLens.sol, WallLib.sol, CubitRouter.sol et dapp/src/chain. API des murs rédigée pendant son implémentation, le 10 septembre 2026.