PoolKey context
The design starts with a pool’s immutable context: currency pair, fee mode, tick spacing and hook address. In Uniswap v4, the PoolManager invokes callbacks enabled by the hook’s permission bits.
ZUNO's Signal Window Hook is a Uniswap v4 system for pool-scoped signals, bounded execution windows and telemetry.
ZUNO / pool-local coordination
The design starts with a pool’s immutable context: currency pair, fee mode, tick spacing and hook address. In Uniswap v4, the PoolManager invokes callbacks enabled by the hook’s permission bits.
ZUNO models the post-swap event as a compact signal envelope: tick movement, timestamp, active liquidity and a relay-state digest. “Heartbeat” describes the project’s telemetry metaphor, not consensus or finality.
The callback names are Uniswap v4 lifecycle points. ZUNO's system design maps a signal relay and heartbeat to pool-local telemetry fields such as tick delta, active liquidity and event timestamp.
Pool state, callback order and execution bounds, gathered into one readable system map.
POOL CONTEXT · CALLBACKS · SETTLEMENTZUNO / system architecture
The core module in ZUNO's Signal Window Hook: an opt-in entry flow with a user-selected window. Its lifecycle separates a pending intent from a settled position: confirm or cancel before expiry, then route the resulting assets through the pool. Escrow, accounting, expiry and revert behavior are enforced through the transaction flow.
The fee module uses recent pool tick movement as a volatility signal. An EWMA accumulator raises the dynamic LP fee after sharp movement and decays it toward a base level as activity calms, within immutable pool parameters and a hard maximum.
The oracle module uses a pool-local observation ring to expose a time-weighted tick window. The range-exit module holds a filled exit state until its owner withdraws, with compatible routers checking the state before routing.
The registry identifies compatible ZUNO hooks by address, callback mask, source version and review status. Pool parameters and callback permissions are displayed before routing, alongside governance and upgrade rules.
Interface design · Uniswap v4
The interface design groups public wallet context with ZUNO-compatible pool fields: PoolKey, liquidity, fee mode, hook permissions and position state.
The swap specification pairs a route quote, fee estimate and minimum output. Liquidity parameters group positions and range orders against the selected pool.
This sequence specifies an execution lifecycle: calldata preparation, local simulation, wallet review, user authorization and settlement confirmation. The reference separates calldata preparation, wallet authorization and PoolManager settlement into distinct stages.
Uniswap v4 · ZUNO architecture
The design maps beforeSwap to fee evaluation and preflight checks, then afterSwap to the resulting tick and pool telemetry. A deployed hook can only execute callbacks enabled by its permission bits.
Uniswap v4 operations settle within PoolManager’s unlock flow; an unsettled balance or reverting callback reverts the transaction. ZUNO preserves atomic accounting and enforces user-defined minimum output on routed swaps.
The route connects window state, fee bounds, pool observations and registry checks before settlement.
ZUNO / pool-state telemetry
The ZUNO model places an intent before pool observation and describes state transitions through event-indexed telemetry. The traceability specification includes epoch handling and replay protection.
ZUNO coordinates the user-facing pool workflow. The application exposes signal status, module parameters, transaction outcomes and contract events so participants can follow each stage from intent to settlement.
ZUNO combines purchase windows, lifecycle accounting, Uniswap v4 hook permissions, bounded dynamic fees, TWAP observation, range execution and hook allowlisting in a single pool-aware architecture.
Publication checklist · pool configuration
Hook verification compares the contract address, source code and callback permission mask with the official project references.
Check the token pair, fee mode, tick spacing and hook configuration for the exact pool selected in the transaction.
Set a minimum output and review the fee estimate and route before signing. A simulation is a preflight check, not a guarantee of execution.
Use only published source and independent security review links. A status label or technical diagram is not an audit.
Wallets · pools · execution
ZUNO is an Ethereum project exploring pool-aware execution with Uniswap v4 hooks, including PoolKey configuration, beforeSwap/afterSwap callbacks, adaptive fees, TWAP observations and event-indexed telemetry.
It describes an opt-in intent lifecycle with explicit bounds and expiry. The specification maps callback permissions, pool context and state transitions across the intent lifecycle.
The gateway supports EVM wallet connections through Phantom or Rabby. Use the Ethereum network and verify the chain shown by your wallet before interacting.
No. Connecting only displays your public wallet address and EVM network. ZUNO never asks you to sign a message or transaction, and the site cannot submit transactions or move your assets.
The Contract section in the station groups ZUNO's Ethereum address information. Verification covers the hook address, source code and callback permission mask.
No. Pool trading and liquidity provision carry risks including price movement, slippage, changing liquidity and smart-contract vulnerabilities. Review the transaction details and only interact with contracts you have verified.