Likely custom pricing hook on Ethereum

Uniswap v4 Hook Contract 0x8a76867df8cc4a02cc5ebfdc47e3cc4cebea28cc on Ethereum · Custom pricing

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

What it does

This hook charges a levy on swaps through return deltas and tracks trend-based owed balances that traders and LPs can claim, but the exact direction of which trades pay more cannot be determined from the decoded bytecode.

How it works step by step

  • Initializes a pool with a fixed open tick and open sqrt price, recording the open time and marking the hook as initialized in beforeInitialize.
  • Gates liquidity additions in beforeAddLiquidity and records a per-epoch state flag, so liquidity entry is controlled by the hook.
  • Runs a trend and purse accounting model keyed by epoch id, with trend states UNDECIDED and STEADY, tracking owed amounts per address.
  • Uses beforeSwap and afterSwap with return deltas, so the hook can adjust the amounts a swap settles and take a levy from trades.
  • Exposes claim and owed functions so eligible addresses can withdraw accumulated amounts recorded for a given epoch.
  • Reads a trading flag and a window parameter to decide when the trend mechanism is active.
Swap behaviour
Swaps are gated and modified in beforeSwap and afterSwap via return deltas; a levy is charged on trades (LEVY_BPS) and the hook can alter settled amounts depending on the trend state.
Liquidity behaviour
beforeAddLiquidity is implemented and can restrict entry; afterAddLiquidity and afterRemoveLiquidity selectors are present but hook-permission flags indicate liquidity callbacks other than beforeAddLiquidity are not enabled.
Fee behaviour
Levies a fee in basis points (LEVY_BPS) on swaps through return deltas; the pool's LP_FEE is also exposed. Which trades pay more or less depends on the trend state, which cannot be determined from bytecode alone.
Owner & admin controls
No owner or pause function was identified in the decoded selectors; an arm() function is present and state is changed by it, but its access control could not be determined from bytecode.

Enabled Uniswap v4 callbacks

beforeInitialize, beforeAddLiquidity, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta

beforeInitialize sets up pool state; beforeAddLiquidity gates liquidity entry; beforeSwap and afterSwap adjust swap amounts via return deltas (beforeSwapReturnDelta and afterSwapReturnDelta) to take a levy and route value into the hook.

Security & trust assessment

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

Who controls it: No privileged owner key was identified from decoded selectors; the arm() function may gate state transitions and its caller restrictions are unknown.

Risk to user funds: The hook takes a levy through return deltas and holds accounted balances that are paid out through claim, so user funds in the pool and hook accounting are exposed to the hook's swap-time deductions.

Security findings

  • [high] Return deltas let the hook take value from swaps: beforeSwapReturnDelta and afterSwapReturnDelta are enabled, so the hook can alter settled amounts and retain tokens taken from trades.
  • [medium] Unverified arm() entry point: arm() is a nonpayable function that writes state; without source the access control and the effect on the trend and trading flags cannot be confirmed.
  • [medium] Claim logic moves accumulated funds: claim(address,uint256[]) transfers amounts recorded in owed and purse mappings; correctness of the accounting cannot be verified without source.
  • [info] No upgradeability or owner found: No proxy or owner selectors were decoded, which reduces admin key risk but leaves the arm() and state-setting logic unverified.

Contract details

Verified source
No
Bytecode size
6,739 bytes
Upgradeable proxy
No
Detected patterns
return-delta

Pools using Likely custom pricing hook