04 / CONSTRUIR8 MIN DE LECTURA

Contratos e integración

Una integración debe identificar la cadena, el núcleo del pool, la ABI y la revisión de los módulos. Una dirección de router copiada de un informe antiguo puede sustituirse; una ABI local nueva puede ser incompatible con el pool todavía desplegado.

Las vistas de múltiples muros siguientes describen la API en preparación. No se anuncian como disponibles en la Sepolia histórica. Exporta la ABI de la versión validada y verifica los runtimes antes de conectar un cliente.

Identidad del pool

La PoolKey contiene currency0, currency1, fee, tickSpacing y hooks. Para CUBIT, ETH nativo es currency0 y el token CUBIT es currency1.

Campo Lectura esperada
currency0 Dirección cero, que representa ETH nativo
currency1 Token del despliegue identificado
fee 100 en la nueva versión prevista; 3000 en la Sepolia histórica
tickSpacing 10 en las fuentes leídas
hooks Hook del despliegue identificado

El poolId depende de toda esta clave. Cambiar únicamente fee en un frontend no transforma un pool antiguo en un despliegue nuevo.

Resolver los módulos en un mismo bloque

Lee primero el registro anclado en hook.v2(). Después resuelve las direcciones de los módulos disponibles y moduleRevision en el mismo bloque. Comprueba su conexión al núcleo.

Este fragmento es de solo lectura, para utilizarlo con un cliente viem ya configurado y una dirección de registro verificada:

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

Este fragmento no verifica por sí solo todas las conexiones ni autoriza ninguna firma. El frontend del repositorio las comprueba en resolveRelease, readRelease y assertCurrentDeployment.

Antes de cada firma, compara los módulos y la revisión con el contexto que el usuario ya ha revisado. No redirijas silenciosamente una autorización.

Leer múltiples muros

Vista prevista del hook Resultado / uso
wallCount() Número de identificadores históricos, distinto del número de posiciones activas
activeWallCount() Número de muros activos en el estado leído
activeWallId(index) ID permanente en un índice de la lista activa actual
latestWallId() ID del último muro financiado; comprueba primero que existe un muro
walls(id) (int24 lower, uint128 liquidity, uint256 idleEth, uint256 fundedEth)
wallIdleEth() Total de remanentes ETH asignados a los muros

Los índices de la lista activa pueden cambiar tras una absorción. Conserva el ID del muro como identidad, no su índice de recorrido. Lee el recuento y los elementos en el mismo bloque.

fundedEth representa el acumulado de fondos nuevos realmente colocados en ese tick. No debe mostrarse como profundidad restante. idleEth representa un remanente vinculado al muro, distinto de su liquidez desplegada.

El límite superior de un rango es lower + tickSpacing. Los activos presentes se calculan con la geometría y el precio actual, o mediante las vistas del Lens adaptadas a esa versión. Las nuevas tasas todavía libres para colocación permanecen separadas en pendingFloorEth.

Los campos históricos floorPrice y netFloorPrice ya no resumen todos los niveles. La referencia del último muro financiado puede bajar cuando baja el objetivo actual; los ticks de los muros ya creados permanecen fijos.

Unidades y orientación

Las cantidades de CUBIT y ETH utilizan 18 decimales. Los precios derivados del Lens se expresan en ETH por CUBIT a escala 1e18. El tick v4 sigue la orientación CUBIT por ETH; disminuye cuando aumenta el precio en ETH por CUBIT.

Utiliza enteros bigint para importes y cálculos antes de darles formato. Una conversión prematura a Number puede perder precisión. La base “7k” se interpreta como 7 000 USD de FDV sobre 21 millones de CUBIT: su conversión a ETH debe registrarse antes del despliegue y el precio inicial queda fijo después. No mezcles USD, wei y unidades de token.

Los métodos 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. Para exact-input, proporciona amountIn como value; para una compra exact-output, proporciona amountInMax, con devolución del excedente. Una venta utiliza zeroForOne = false, value cero y una autorización CUBIT para el router.

Los importes devueltos siguen los límites netos/brutos del router: salida neta para exact-input, entrada bruta para exact-output. El contrato controla las ejecuciones incompletas. La cotización debe simularse con la clave de pool correcta y su versión.

Eventos y errores

Los eventos históricos incluyen BuyTaxed, SellTaxed, FloorRaised, SweepExecuted, TokensBurned y BountyPaid. ModuleUpdated permite seguir sustituciones de módulos; ReferralBound describe un vínculo de referido.

La nueva biblioteca añade WallFunded y WallAbsorbed con el ID correspondiente. Los logs de una biblioteca ejecutada en el contexto del hook deben indexarse en la dirección emisora del hook y con las firmas ABI correspondientes.

FloorRaised conserva un nombre histórico; el nombre no basta para concluir que todos los niveles suben. Un retransmisor debe interpretar la financiación del muro identificado y la política de la versión.

En el router, trata especialmente Expired, WrongPool, TooLittleReceived, TooMuchRequested, InsufficientOutput e IncompleteInput. Para mantenimiento, los errores de elegibilidad y los errores RPC son distintos. Revisa los códigos y la ABI después de validar los múltiples muros.

Fuentes: interfaces/ICubitHook.sol, interfaces/ICubitLens.sol, WallLib.sol, CubitRouter.sol y dapp/src/chain. API de muros redactada durante su implementación, el 10 de septiembre de 2026.

CUBIT / 10 de septiembre de 2026 Fuentes y método