FwaRewardBoostHook on Ethereum

Uniswap v4 Hook Contract 0x37bfb8ac7c960e558657871d41ca70e07e7dbfff on Ethereum · Rewards · Verified contract

Volume (24h)
$543.96K
Value locked (TVL)
$316.70K
All-time volume
$24.71M
Pools using this hook
1
Swaps (24h)
893 (284 traders)
Total swaps
52,654

What it does

A Uniswap v4 hook for the CLAUS pool that wraps a reviewed reward implementation and gates CLAUS token transfers by granting transient transfer allowances after swaps and liquidity changes on the official pool.

How it works step by step

  • Delegates all hook callbacks to a pinned prior implementation whose runtime hash is checked at construction.
  • After swaps and liquidity add or remove on the official pool key, grants a transient CLAUS transfer allowance equal to the absolute token1 delta.
  • Wraps the unlock callback with a fixed payout context so the pool manager can pay out to the hook, FOMO and reserve addresses during processing.
  • Checks a token restriction policy version so transfer gating only activates after the token upgrade.
  • Relies on the CLAUS token's default-deny transfer restrictions with owner and distributor exemptions.
Swap behaviour
After swaps on the official pool key, when the restriction policy is active and internal processing is not in progress, the hook grants a transient CLAUS transfer allowance equal to the absolute token1 delta of the swap; all swap logic beyond that runs in the delegated implementation.
Liquidity behaviour
After liquidity add or remove events on the official pool key, the hook delegates to the prior implementation and, when the restriction policy is active, grants a transient token transfer allowance sized to the token1 delta unless internal fixed processing is in progress.
Fee behaviour
Uses the pool's static fee; the hook does not set or take fees, but after swaps and liquidity changes it grants a transient transfer allowance on the CLAUS token equal to the absolute token1 delta, which is a token-transfer gate rather than a fee.
Owner & admin controls
The proxy admin of the underlying token (external ProxyAdmin, owner-controlled) can install new token implementations; the token owner can set distributor exemptions via setDistributor and update metadata; the hook itself has no owner, pause or parameter setter, and its previousImplementation and baseRuntimeHash are immutable.

Enabled Uniswap v4 callbacks

beforeInitialize, afterInitialize, beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity, afterRemoveLiquidity, beforeSwap, afterSwap, beforeDonate, afterDonate, beforeSwapReturnDelta, afterSwapReturnDelta, afterAddLiquidityReturnDelta, afterRemoveLiquidityReturnDelta

beforeInitialize, afterInitialize, beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity, afterRemoveLiquidity, beforeSwap, afterSwap, beforeDonate, afterDonate are all forwarded to the delegated implementation; beforeSwapReturnDelta, afterSwapReturnDelta, afterAddLiquidityReturnDelta and afterRemoveLiquidityReturnDelta are enabled by address flags and handled by the implementation, which is not verified here; afterSwap and liquidity-after hooks in this wrapper grant transfer allowance on the CLAUS token.

Security & trust assessment

Risk level: high (verified source, medium confidence).

Who controls it: The token owner can exempt arbitrary addresses from transfer restrictions via setDistributor, and the external token ProxyAdmin can replace the token implementation entirely, which would change transfer rules and balances behaviour for all holders. The hook's delegatecall target is fixed at deployment, so the hook implementation itself cannot be swapped by a privileged key.

Risk to user funds: The hook itself does not custody funds, but the delegated implementation runs in the hook's context with pool-manager permissions and the token's transfer gating can block holders from moving CLAUS, and the token ProxyAdmin or the owner can change those rules or exempt addresses.

Security findings

  • [high] Unreviewed delegatecall target: Every call is delegatecalled to implementation 0x19143522eab522bdd1ef0084223434c3de8fee5d, which is not part of the verified source set here. Reward and return-delta logic in that implementation cannot be reviewed from the provided material.
  • [medium] Owner-controlled transfer exemptions: The token owner can add or remove distributor exemptions with setDistributor, letting exempt addresses transfer freely while other holders are restricted; the owner can also update token metadata.
  • [medium] Upgradeable token and hook proxy: The CLAUS token sits behind an upgradeable proxy controlled by an external ProxyAdmin, so the transfer restriction logic and balances can be changed by that admin.
  • [medium] Default-deny transfer restriction: Transfers between non-exempt users are reverted unless the sender is the pool manager with sufficient transient allowance or the transfer matches a legacy withdrawal or fixed payout path, so holders can be unable to move tokens freely after activation.
  • [info] Pinned prior implementation: The hook is deployed with an immutable reference to a previous implementation whose runtime hash is checked at construction, which constrains what the delegated logic can be.

Contract details

Verified source
Yes (FwaRewardBoostHook)
Compiler
solc 0.8.26+commit.8a97fa7a
Bytecode size
3,070 bytes
Upgradeable proxy
Yes
Detected patterns
return-delta, rewards, upgradeable

Pools using FwaRewardBoostHook