Skip to pool terminal
ZUNO / pool observation

Beneath
the surface.

Pool state. Liquidity ranges. Callback boundaries.
A closer look at the Signal Window.

OBSERVATION LENS

Nested bands frame active liquidity and selected price ranges.

ZUNO protocol / pool status

Signal
aligned.

ZUNO's architecture connects PoolKey context, adaptive fee bounds, TWAP observations, callback permissions and event-indexed transaction telemetry.

PoolKey · tick spacing · fee bounds · callback permissions.

PROTOCOL REFERENCEETHEREUM / EVM
Signal Window HookINTENT LIFECYCLE
Pool telemetrySCHEMA
Hook registryARCHITECTURE MAP
ZUNO / FIELD NOTESSignal stack mapped. Pool context in view.
↗
WALLET CONNECTIONNOT CONNECTED

Public address and EVM network only.
No signatures, transactions or asset transfers.

Choose your wallet to open its extension and approve the connection.
Connection permissions

Phantom or Rabby may ask for your password in its extension window to unlock your wallet. Your password stays with the extension and is never shared with ZUNO. Connecting only shares your public address and network. No message or transaction signature is requested, and this connection cannot send transactions or move your funds.

ZUNO / EXECUTION TRACKEthereum · Uniswap v4
SIGNAL WINDOW→ADAPTIVE FEE→TWAP→HOOK REGISTRY

The modules coordinate pool context, fee bounds, time-weighted observations and callback permissions across the ZUNO execution path.

Wallet sessionDISCONNECTED
Connected networkNOT CHECKED
Launch accessPUBLIC UPDATES
01 / ZUNO app

One interface for the pool

Swaps · liquidity · positions

Pool / 01

Swap with context

The route model brings together an active fee, recent price movement, TWAP window and hook permissions, with slippage and minimum output as explicit bounds.

Pool quoteFee boundsMinimum output
Liquidity / 02

Manage ranges

The ZUNO design groups liquidity positions and range exits within the same pool view, with trigger state and route context represented as pool fields.

Liquidity positionRange orderExit state
Transaction / 03

Follow every stage

The transaction dock describes an architecture flow from preparation and local simulation through wallet review, confirmation and finalized state. The reference separates preparation, authorization and finality into distinct stages.

Simulation modelWallet reviewFinalized state
Network / 04

See the network context

The wallet indicator displays the connected EVM account and chain. The network reference defines account context, chain identity and pool-state fields.

Chain statusPool freshnessWallet context
ZUNO / TRANSACTION DOCKExecution reference
PREPARE→SIMULATE→SIGN→CONFIRM→FINALIZE

The execution reference maps calldata preparation, simulation, authorization, confirmation and finality.

02 / Pool field notes

ZUNO's pool model

PoolKey · liquidity · hook permissions

The pool reference brings together PoolKey fields, liquidity parameters, hook permissions and execution boundaries.
Pool identityPoolKeyToken pair · fee mode · tick spacing
Pool readoutLiquidityRange bounds and active liquidity context
Hook surfaceCallbacksPermission mask and hook address schema
Route reviewPreflightFee bounds · TWAP · minimum output
Signal inputPool fieldRole in ZUNO
Pool identityPoolKeyDefines token pair, fee mode and tick spacing.
Market contextTick · TWAPFrames price movement across a selected time window.
Execution boundaryHook permissionsMaps the beforeSwap and afterSwap callback surface.
Liquidity stateActive liquidityPlaces the route against the pool's available depth.
ZUNO / EVENT SCHEMAPool-local signal model
SWAP·LIQUIDITY UPDATE·WINDOW STATE·HOOK EVENT

Event schema: transaction hash, block number, pool identifier, event topic and execution result. These fields define the structure of pool-local telemetry.

ZUNO / POOL INDEXField map for the PoolKey, fee parameters, liquidity and callback permissions.
↗
03 / Hook execution

How a ZUNO signal moves

Uniswap v4 · execution flow

01 / Pool context

Read the PoolKey

ZUNO begins with the selected pool’s currencies, fee mode, tick spacing and hook address. The pool key identifies which hook is called and which callback permissions are fixed for that pool.

PoolKeyPoolManagerPermission mask
02 / Before swap

Open the signal window

The entry flow attaches a user-selected expiry to a pending intent. Confirm and cancel paths use explicit asset accounting and atomic settlement.

User opt-inExpiry stateAtomic settlement
03 / Pool observation

Measure movement

The design assigns recent tick movement to a bounded fee model and uses a TWAP observer for pool-local price context.

EWMADynamic feeTWAP
04 / After swap

Settle and record

The afterSwap specification covers resulting pool state and signal events. Uniswap v4 settlement rules define the accounting and execution semantics.

afterSwapState eventRevert safety
04 / Protocol modules

ZUNO system modules

Protocol architecture · Ethereum

Module A · INTENT

Signal Window

An intent lifecycle specification with explicit expiry, confirm and cancel paths, and asset-accounting boundaries.

Module B · FEES

Adaptive Fee

An EWMA-based fee specification: tick movement, decay toward a base fee and a pool-defined maximum.

Module C · OBSERVATIONS

TWAP + Range Exit

A pool-local observation model for time-weighted tick history, paired with a range-exit lifecycle for selected price bands.

Module D · PERMISSIONS

Hook Registry

A registry schema for hook addresses, permission masks, source versions and review status.

The module reference connects intent bounds, adaptive fees, TWAP observations and callback permissions.

05 / Execution boundaries

Permissions stay visible

Pool configuration · settlement · routing

ZUNO / SAFETY MODELUniswap v4 constraints
FIXED POOL KEY→CALLBACK PERMISSIONS→BOUNDED FEE→MIN OUTPUT→SETTLEMENT

ZUNO’s deployment checklist includes permission-mask verification, immutable pool parameter disclosure, fee bounds, TWAP history limits, minimum-output routing, source publication and independent security review.