Likely fee sharing hook on BNB Chain

Uniswap v4 Hook Contract 0x68e854e644c29f6dc21bf24247f7a293756f4044 on BNB Chain · Fee sharing

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 takes a share of swap output after each trade and sends it to a configured beneficiary, so swappers in pools using it receive slightly less, while LPs are not directly affected because liquidity callbacks are disabled.

How it works step by step

  • Enables only the afterSwap and afterSwapReturnDelta hook permissions, so it acts after each swap and can take a share of the swap output as a return delta.
  • Stores per-pool configuration in poolConfigs keyed by pool id, and tracks per-pool, per-address balances and debt in mapping storage.
  • afterSwap reads stored values, updates per-address accounting and calls take on the pool manager to move a currency out to the beneficiary.
  • Exposes a keeper role that can call functions writing pool parameters and a beneficiary address that receives the taken funds.
  • Includes a bootstrap view and projectedDebt view, suggesting a staged funding or debt-tracking mechanism for a pool.
Swap behaviour
After each swap the afterSwap callback runs, updates internal accounting and can take a currency from the pool via the pool manager, reducing the amount the swapper effectively receives through the return delta. Exactly which trades pay more or less cannot be determined from decoded bytecode alone.
Liquidity behaviour
beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity and afterRemoveLiquidity selectors are present in the dispatch table but the corresponding hook permissions are not enabled, so the hook is not called on liquidity changes.
Fee behaviour
Fee amount is not directly set by a visible fee function; the hook takes a return delta on swaps, so its economics come from that taken amount rather than the pool's static fee. Exact computation cannot be confirmed without source.
Owner & admin controls
owner() exists and is ownable; setBeneficiary and setKeeper are nonpayable and appear restricted to owner and keeper roles. Whether the owner can upgrade the contract or pause swaps is not visible in the decoded bytecode.

Enabled Uniswap v4 callbacks

afterSwap, afterSwapReturnDelta

afterSwap: updates accounting and processes the swap after execution. afterSwapReturnDelta: lets the hook return a delta that changes the amounts settled for the swapper, used to take a share of the swap.

Security & trust assessment

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

Who controls it: The owner can reassign the beneficiary, and the keeper can change stored pool parameters, so either key could redirect or alter the value taken from swaps.

Risk to user funds: The hook can take currency from swaps via return deltas and send it to the beneficiary, so swappers in affected pools lose a portion of their output to this mechanism.

Security findings

  • [medium] Return delta takes funds from swaps: afterSwapReturnDelta with take() calls means the hook removes a currency from each affected swap; the amount is determined by stored parameters that a keeper or owner can influence.
  • [medium] Privileged keeper and owner roles: setKeeper and setBeneficiary change where taken funds go and who can run parameter updates, so a compromised key could redirect proceeds.
  • [info] Unverified source: No verified source is available, so the exact formulas for taken amounts and any pause or upgrade logic could not be confirmed.

Contract details

Verified source
No
Bytecode size
5,176 bytes
Upgradeable proxy
No
Detected patterns
moves-currency, ownable, return-delta

Pools using Likely fee sharing hook