Verträge und Integration

Eine Integration muss die Blockchain, den Poolkern, die ABI und die Modulrevision identifizieren. Eine aus einem früheren Bericht kopierte Routeradresse kann ausgetauscht werden; eine neue lokale ABI kann mit dem noch bereitgestellten Pool inkompatibel sein.

Die folgenden Ansichten für mehrere Walls beschreiben die API in Vorbereitung. Sie werden nicht als auf dem historischen Sepolia verfügbar angekündigt. Exportieren Sie die ABI der validierten Veröffentlichung und prüfen Sie die Runtimes, bevor Sie einen Client anbinden.

Poolidentität

Die PoolKey enthält currency0, currency1, fee, tickSpacing und hooks. Bei CUBIT ist natives ETH currency0 und der CUBIT-Token currency1.

Die poolId hängt von diesem gesamten Schlüssel ab. Nur fee in einem Frontend zu ändern, verwandelt einen früheren Pool nicht in ein neues Deployment.

Module am selben Block auflösen

Lesen Sie zuerst die in hook.v2() verankerte Registry. Lösen Sie dann die Adressen der verfügbaren Module und moduleRevision am selben Block auf. Prüfen Sie ihre Anbindung an den Kern.

Das folgende Fragment dient ausschließlich zum Lesen und setzt einen bereits konfigurierten viem-Client sowie eine geprüfte Registry-Adresse voraus:

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

Dieses Fragment prüft allein nicht alle Verknüpfungen und berechtigt zu keiner Signatur. Das Frontend des Repositorys prüft sie in resolveRelease, readRelease und assertCurrentDeployment.

Vergleichen Sie vor jeder Signatur die Module und die Revision mit dem bereits vom Nutzer geprüften Kontext. Leiten Sie eine Freigabe nicht stillschweigend um.

Mehrere Walls abfragen

Die Indizes der aktiven Liste können sich nach einer Aufnahme ändern. Verwenden Sie die Wall-ID als Identität, nicht ihren Durchlaufindex. Lesen Sie die Anzahl und die Elemente am selben Block.

fundedEth stellt die Summe der tatsächlich an diesem Tick platzierten neuen Mittel dar. Sie darf nicht als verbleibende Tiefe angezeigt werden. idleEth bezeichnet einen an die Wall gebundenen Restbestand, getrennt von ihrer platzierten Liquidität.

Die obere Grenze eines Bereichs ist lower + tickSpacing. Die vorhandenen Vermögenswerte werden anhand der Geometrie und des aktuellen Preises oder über die an diese Version angepassten Lens-Ansichten berechnet. Neue, noch frei platzierbare Gebühren bleiben in pendingFloorEth getrennt.

Die historischen Felder floorPrice und netFloorPrice fassen nicht mehr alle Niveaus zusammen. Die Referenz der zuletzt finanzierten Wall kann fallen, wenn das aktuelle Ziel fällt; die Ticks bereits erstellter Walls bleiben fest.

Einheiten und Ausrichtung

CUBIT- und ETH-Mengen verwenden 18 Dezimalstellen. Die abgeleiteten Preise des Lens werden in ETH pro CUBIT mit dem Maßstab 1e18 angegeben. Der v4-Tick folgt der Ausrichtung CUBIT pro ETH; er sinkt, wenn der Preis in ETH pro CUBIT steigt.

Verwenden Sie vor der Formatierung bigint-Ganzzahlen für Beträge und Berechnungen. Eine zu frühe Umwandlung in Number kann Genauigkeit verlieren. Die Basis „7k“ wird als 7 000 USD FDV auf 21 Millionen CUBIT verstanden: Ihre ETH-Umrechnung muss vor dem Deployment festgehalten werden; anschließend bleibt der anfängliche Preis fest. Vermischen Sie USD, Wei und Tokeneinheiten nicht.

Die Methoden des Routers

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 kauft CUBIT mit ETH. Geben Sie bei Exact-Input amountIn als value an; bei einem Exact-Output-Kauf amountInMax, wobei der Überschuss erstattet wird. Ein Verkauf verwendet zeroForOne = false, value null und eine CUBIT-Freigabe an den Router.

Die zurückgegebenen Beträge folgen den Netto-/Bruttogrenzen des Routers: Nettoausgabe bei Exact-Input, Bruttoeingabe bei Exact-Output. Der Vertrag prüft unvollständige Ausführungen. Die Quotierung muss mit dem richtigen Poolschlüssel und seiner Version simuliert werden.

Ereignisse und Fehler

Zu den historischen Ereignissen gehören BuyTaxed, SellTaxed, FloorRaised, SweepExecuted, TokensBurned und BountyPaid. ModuleUpdated ermöglicht das Verfolgen von Modulaustauschen; ReferralBound beschreibt eine Empfehlungsverbindung.

Die neue Bibliothek ergänzt WallFunded und WallAbsorbed mit der betreffenden ID. Logs einer im Kontext des Hooks ausgeführten Bibliothek müssen anhand der ausgebenden Hook-Adresse und mit den entsprechenden ABI-Signaturen indexiert werden.

FloorRaised behält einen historischen Namen; dieser Name reicht nicht aus, um zu folgern, dass alle Niveaus steigen. Ein Relais muss die Finanzierung der identifizierten Wall und die Regeln der Veröffentlichung interpretieren.

Behandeln Sie im Router insbesondere Expired, WrongPool, TooLittleReceived, TooMuchRequested, InsufficientOutput und IncompleteInput. Bei der Wartung sind Zulässigkeitsfehler und RPC-Fehler getrennt. Lesen Sie nach der Validierung mehrerer Walls die Codes und die ABI erneut.

Quellen: interfaces/ICubitHook.sol, interfaces/ICubitLens.sol, WallLib.sol, CubitRouter.sol und dapp/src/chain. Wall-API während ihrer Implementierung am 10. September 2026 dokumentiert.