Skip to documentation
ZUNO / technical documentation

SIGNAL WINDOW
HOOK SYSTEM.

ZUNO's Signal Window Hook is a Uniswap v4 system for pool-scoped signals, bounded execution windows and telemetry.

Protocol scope: ZUNO's documentation covers Uniswap v4 hook architecture: PoolKey-scoped configuration, callback permissions, bounded fee parameters, TWAP observations and pool-state telemetry.
01 / System topology

One pool. One signal path.

ZUNO / pool-local coordination

Architecture / 01

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.

PoolKeyPoolManagerPermission bitmapCallback scope
Architecture / 02

Signal relay

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.

Tick deltaState digestRelay depthHeartbeat nonce
ZUNO / SIGNAL ROUTECallback sequence model
POOL KEY→BEFORE SWAP→POOL MATH→AFTER SWAP→ZUNO SIGNAL→TELEMETRY

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.

ZUNO smiling while reviewing the callback trace
ZUNO / CALLBACK TRACECallback trace: beforeSwap → afterSwap.
↗
ZUNO / FIELD NOTES · 02

Read the signal
in context.

Pool state, callback order and execution bounds, gathered into one readable system map.

PoolKeybeforeSwapTWAPsettlement
POOL CONTEXT · CALLBACKS · SETTLEMENT
FIELD LOG / POOL NOTES ORBITAL ARCHIVE / 02
02 / Hook modules

Four coordinated modules

ZUNO / system architecture

Module / A

ZUNO Signal Window

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.

Intent escrowExpiry stateAtomic settlementUser opt-in
Module / B

Adaptive fee envelope

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.

EWMADynamic feeDecay curveFee ceiling
Module / C

TWAP + range exit

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.

TWAP observationCumulative tickRange orderRoute guard
Module / D

Hook registry

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.

Hook allowlistPermission auditSource provenancePool transparency
03 / ZUNO application

From pool discovery to settlement

Interface design · Uniswap v4

App / 01

Inspect pools and positions

The interface design groups public wallet context with ZUNO-compatible pool fields: PoolKey, liquidity, fee mode, hook permissions and position state.

Pool explorerWallet contextHook state
App / 02

Swap and manage liquidity

The swap specification pairs a route quote, fee estimate and minimum output. Liquidity parameters group positions and range orders against the selected pool.

Swap quoteMinimum outputRange position
ZUNO / TRANSACTION DOCKExecution lifecycle model
PREPARE→SIMULATE→WALLET REVIEW→CONFIRM→FINALIZE

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.

04 / Execution model

Callbacks, bounds & settlement

Uniswap v4 · ZUNO architecture

Callback map

beforeSwap / afterSwap

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.

PreflightPost-swap observationReturns deltaPermission flags
Settlement semantics

Atomic by design

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.

Unlock / settleTransaction revertMin outputBounded execution
ZUNO / MODULE ROUTEModule responsibilities
WINDOW MANAGER→FEE MODULE→TWAP OBSERVER→HOOK REGISTRY

The route connects window state, fee bounds, pool observations and registry checks before settlement.

05 / ZUNO telemetry

Signal routing

ZUNO / pool-state telemetry

Subsystem / ZUNO

Intent → observation → state

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.

Intent stagingEpoch counterReplay guardEvent index
Subsystem / ZUNO

ZUNO signal operator

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.

Signal statusParameter viewTransaction traceCore heartbeat
A future execution flow should expose the selected PoolKey, hook permission mask, dynamic-fee bounds, TWAP window, slippage limit, minimum output and encoded wallet request. No transaction or signature flow is active on this site.

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.

06 / Security & verification

Review before routing

Publication checklist · pool configuration

Confirm the hook address

Hook verification compares the contract address, source code and callback permission mask with the official project references.

Review the PoolKey

Check the token pair, fee mode, tick spacing and hook configuration for the exact pool selected in the transaction.

Bound the swap

Set a minimum output and review the fee estimate and route before signing. A simulation is a preflight check, not a guarantee of execution.

Check published reviews

Use only published source and independent security review links. A status label or technical diagram is not an audit.

07 / FAQ

ZUNO FAQ

Wallets · pools · execution

What is ZUNO?

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.

What does the Signal Window describe?

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.

Which wallet and network should I use?

The gateway supports EVM wallet connections through Phantom or Rabby. Use the Ethereum network and verify the chain shown by your wallet before interacting.

Does connecting a wallet move funds or request signatures?

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.

Where do I find contract information?

The Contract section in the station groups ZUNO's Ethereum address information. Verification covers the hook address, source code and callback permission mask.

Are swaps risk-free?

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.