Rewards hook on Ethereum

Uniswap v4 Hook Contract 0x6c6f61f4fa4ec3a1e52919600157fc833d10a8cc on Ethereum · Rewards

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

What it does

This hook uses return deltas on swaps to take or redirect part of each trade and runs staking incentive logic, but the exact fee and reward amounts cannot be determined from the decoded bytecode.

How it works step by step

  • Hook is initialized once; a boolean flag in slot 0 tracks the opened state and is set on first initialization.
  • Uses a self-unlock pattern: the hook calls the pool manager's unlock and handles the callback via unlockCallback, settling balances with pay() and tracking owed amounts in storage slots 1 and 2.
  • beforeSwap and afterSwap adjust balances through return deltas, so the hook can take or give back part of a swap's input or output.
  • Contains an external call to a staking incentive calculation (selector 0x0787ab3b, _calculateStakingIncentivesBatch with Merkle-style proofs), suggesting incentive distribution tied to pool activity.
  • Liquidity additions and removals are gated by beforeAddLiquidity and beforeRemoveLiquidity checks and the afterRemoveLiquidity/afterAddLiquidity hooks exist but are declared as view and appear to be placeholders.
Swap behaviour
beforeSwap and afterSwap run on every swap and can modify the trade through return deltas; the exact fee or reward split cannot be confirmed from bytecode alone.
Liquidity behaviour
beforeAddLiquidity is active and can revert or gate additions; beforeRemoveLiquidity is declared as view and does not appear to change state.
Fee behaviour
Fees and reward amounts are not directly readable from decoded bytecode; the hook may take a share of swap amounts through afterSwapReturnDelta and beforeSwapReturnDelta, but the rate cannot be determined.
Owner & admin controls
An OWNER() getter exists, indicating an owner address; the bytecode does not show clear parameter setters, so the extent of owner powers is unclear.

Enabled Uniswap v4 callbacks

beforeInitialize, beforeAddLiquidity, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta

beforeInitialize sets the opened flag; beforeAddLiquidity gates liquidity additions; beforeSwap and afterSwap run swap logic and can apply deltas; beforeSwapReturnDelta and afterSwapReturnDelta let the hook take or return currency during swaps.

Security & trust assessment

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

Who controls it: The owner appears to hold privileged control over the hook, but without verified source it is unclear what parameters or upgrades are available to them.

Risk to user funds: The hook can hold and move pool currency through return deltas and settlement with pay(), so user swap amounts can be altered by its logic.

Security findings

  • [high] Return deltas let the hook take user funds: beforeSwapReturnDelta and afterSwapReturnDelta are enabled, so the hook can alter the amounts users receive or pay on each swap.
  • [medium] Owner address present: An OWNER() getter and owner-related storage suggest privileged control, but the decoded functions do not reveal how it is used or whether it can change hook logic.
  • [medium] Self-unlock with balance settlement: The hook unlocks the pool manager itself and manages owed balances and payments through pay(), which adds complexity and a surface for accounting errors.
  • [info] Staking incentive logic with Merkle-style proofs: An external call to _calculateStakingIncentivesBatch takes proof arrays, so incentive correctness depends on proof validation that cannot be verified from bytecode.

Contract details

Verified source
No
Bytecode size
6,088 bytes
Upgradeable proxy
No
Detected patterns
return-delta, rewards, self-unlock

Pools using Rewards hook