Rewards hook on Optimism

Uniswap v4 Hook Contract 0xf8c3f4243c4d8c02831a718a7978fd869f094300 on Optimism · Rewards

Volume (24h)
$0.06
Value locked (TVL)
$7.84
All-time volume
$30
Pools using this hook
21
Swaps (24h)
22 (18 traders)
Total swaps
3,764

What it does

A Uniswap v4 hook that only enables liquidity-removal callbacks and exposes a full set of hook entry points, with its logic in the remove-liquidity path, which traders and LPs should check before relying on it.

This read was written for the hook 0xf8c3…4300 on Ethereum and reused here: the two run the same code.

How it works step by step

  • Declares only beforeRemoveLiquidity and afterRemoveLiquidity as enabled permissions, so the pool manager calls it only when liquidity is removed from a pool that uses it.
  • Exposes the complete Uniswap v4 hook interface (initialize, add/remove liquidity, swap, donate callbacks), though only the remove-liquidity callbacks are enabled by the address permissions.
  • Exposes getHookPermissions() and poolManager() getters, indicating it is built on the standard BaseHook pattern and is bound to a single pool manager.
  • Includes an unlockCallback(bytes) entry point, which is the standard way the pool manager calls back into a contract during an unlock flow, suggesting the hook can take actions within a pool manager unlock session.
  • The bytecode references a HookNotImplemented() error, which is the standard revert for unused callbacks in BaseHook-style contracts.
Swap behaviour
No swap callbacks.
Liquidity behaviour
Runs custom logic before and after liquidity is removed. Add-liquidity selectors are present in the dispatch table but the address does not enable beforeAddLiquidity or afterAddLiquidity, so they are not invoked.
Fee behaviour
Uses the pool's static fee.
Owner & admin controls
No admin controls found.

Enabled Uniswap v4 callbacks

beforeRemoveLiquidity, afterRemoveLiquidity

beforeRemoveLiquidity runs before a position is withdrawn and afterRemoveLiquidity runs after the withdrawal amounts are known; their specific purpose cannot be determined from the decoded bytecode alone.

Security & trust assessment

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

Who controls it: No privileged roles or admin functions were identified in the decoded selectors, so no specific central key was found; this cannot be fully confirmed without source.

Risk to user funds: The hook sits in the liquidity removal path and could block or modify withdrawals if its logic reverts or changes amounts; it does not appear to custody funds directly, but this depends on logic not visible in the bytecode.

Security findings

  • [medium] No verified source: Without verified source the actual logic inside the remove-liquidity callbacks cannot be read, so the effect on withdrawals is unknown.
  • [medium] Remove-liquidity callbacks can affect withdrawals: Because beforeRemoveLiquidity and afterRemoveLiquidity are enabled, the hook can revert or alter withdrawals if its logic does so, and could block LPs from exiting.
  • [info] No storage layout detected: The inferred storage layout is empty, so the bytecode shows no obvious persistent state or owner variable, though this is not conclusive.
  • [low] Unlock callback present: The presence of unlockCallback suggests the hook may perform pool manager actions, which warrants review of what it can move.

Contract details

Verified source
No
Bytecode size
2,488 bytes
Upgradeable proxy
No
Detected patterns
self-unlock

Pools using Rewards hook