Likely oracle hook on Ethereum

Uniswap v4 Hook Contract 0x0b98ebd58d13e2d2054b22ca5693ba18d8f41040 on Ethereum · Fee sharing

Volume (24h)
$0
Value locked (TVL)
$0
All-time volume
$0
Pools using this hook
7
Swaps (24h)
0 (0 traders)
Total swaps
0

What it does

An unverified hook that initializes state after pool creation and, after each swap, appears to unlock the PoolManager to settle, donate or burn currency, though its exact purpose cannot be confirmed from bytecode alone.

How it works step by step

  • Runs afterInitialize to set initial hook state in a mapping at storage slot 1
  • Runs afterSwap to update hook state after every swap
  • Opens its own unlock session via unlock/unlockCallback to perform accounting
  • Calls settle and sync to reconcile currency balances with the PoolManager
  • Can donate to pool reserves and burn ERC-6909 claim tokens
  • Liquidity callbacks are dispatched but not enabled by the permission set
Swap behaviour
afterSwap runs after each swap and writes hook state; it also appears to self-unlock and move or donate currency, with trigger conditions not determinable from the decoded input.
Liquidity behaviour
Liquidity callbacks beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity and afterRemoveLiquidity are dispatched but enabled only as view selectors; the hook permissions do not enable them, so the PoolManager should not invoke them. Liquidity is not directly manipulated by the hook.
Fee behaviour
Does not set or override the pool fee in any decoded callback; fee handling is not determinable from decoded selectors alone. Pool fee is assumed to be the pool's configured fee.
Owner & admin controls
No admin controls found. Storage shows no owner slot and no pause flag; the only writable state is a uint256 at slot 0 and a mapping(uint256 => bool) at slot 1, written by afterInitialize, afterSwap and the unlock-driven entry point 0xeb173492. Whether any selector gates these writes cannot be confirmed without source.

Enabled Uniswap v4 callbacks

afterInitialize, afterSwap

afterInitialize: runs once after pool creation and writes hook state (storage slot 1 mapping). afterSwap: runs after each swap, writes hook state and may move currency via the unlock/settle/sync/transfer/donate/burn call set found in the bytecode.

Security & trust assessment

Risk level: medium, estimated (decoded bytecode, low confidence).

Who controls it: No owner or privileged key was identified in the decoded storage, so no single key is evident. Verification of this is limited because source is unavailable.

Risk to user funds: The hook can hold, transfer, donate and burn pool currency during afterSwap through its self-unlock flow, so swaps may route value through hook-controlled accounting. Whether it can block swaps or redirect user funds cannot be determined without source.

Security findings

  • [medium] Hook self-unlocks and moves currency: Bytecode contains selectors for unlock, settle, sync, donate, transfer, transferFrom and burn, meaning the hook can open its own unlock session and move or donate pool currency during afterSwap.
  • [low] Donate and burn paths present: The hook can donate to pool liquidity, which changes reserves for LPs; the donate path and its trigger condition could not be confirmed from bytecode alone.
  • [info] ERC-6909 claim accounting: The ERC-6909 burn selector is present, indicating claim-token accounting is used; the exact accounting invariant could not be verified.
  • [info] Unverified source: No source is available, so behaviour is inferred from selectors and storage only; the exact conditions for the currency movements are unknown.

Contract details

Verified source
No
Bytecode size
13,801 bytes
Upgradeable proxy
No
Detected patterns
donates, erc6909-claims, moves-currency, self-unlock

Pools using Likely oracle hook