Fee sharing hook on Ethereum

Uniswap v4 Hook Contract 0xfda43c856ffa6b759dab36a17bd00de9bda9a080 on Ethereum · Fee sharing

Volume (24h)
$0
Value locked (TVL)
$653
All-time volume
$17.82K
Pools using this hook
5
Swaps (24h)
0 (0 traders)
Total swaps
340

What it does

A Uniswap v4 hook that applies a time-based and sniper-protection fee to swaps in configured pools, with per-pool terms and a whitelist controlling who is exempt.

How it works step by step

  • Stores per-pool fee terms keyed by pool id via setTerms and reads them on initialization and swaps.
  • Computes the current fee with currentFee and feeAt based on elapsed time since the schedule started.
  • Applies an anti-sniper window of up to MAX_SNIPER_BLOCKS blocks after pool setup.
  • Maintains a per-pool whitelist via setWhitelist that exempts listed addresses from sniper-window fees.
  • Enforces a maximum total fee (MAX_TOTAL_FEE) and schedule length (MAX_SCHEDULE_SECONDS) to bound parameters.
Swap behaviour
beforeSwap applies the hook's dynamic fee logic per pool, with elevated fees during the sniper window for non-whitelisted swappers.
Liquidity behaviour
No liquidity callbacks are enabled in the hook permissions (only beforeInitialize and beforeSwap); the add and remove liquidity selectors present in the dispatch are not wired to pool-manager callbacks by permission flags.
Fee behaviour
The hook computes a time-dependent fee via currentFee(bytes32) and feeAt(bytes32,uint256,uint256) based on per-pool terms (capped by MAX_TOTAL_FEE and a FeeTooHigh error), with an anti-sniper window (MAX_SNIPER_BLOCKS, sniperWindowOpen) that appears to apply elevated fees to early swaps; exact fee curve cannot be confirmed without source.
Owner & admin controls
setTerms(bytes32,(uint24,uint24,uint32,uint24,uint32,uint64,uint64,bool,bool)) and setWhitelist(bytes32,address[]) are nonpayable and write storage; the decoded bytecode does not show an explicit owner check in the dispatch alone, so the access control on these setters cannot be confirmed. Parameters that can be changed include per-pool terms (fee bounds, schedule length, sniper window, whitelist membership).

Enabled Uniswap v4 callbacks

beforeInitialize, beforeSwap

beforeInitialize: likely registers terms or initializes per-pool state for the pool. beforeSwap: applies the time- and sniper-dependent fee logic and may check whitelist status for the sender.

Security & trust assessment

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

Who controls it: A privileged key able to call setTerms and setWhitelist could raise or redefine the fee schedule, extend the schedule, and control which addresses are whitelisted for the sniper window, affecting swap pricing for users.

Risk to user funds: The hook does not take tokens via return deltas and does not hold pool funds according to its permissions, so user funds are not directly custodied; exposure is indirect through fee magnitude and swap pricing set by its terms.

Security findings

  • [medium] Unconfirmed access control on parameter setters: setTerms and setWhitelist are state-changing and no owner or role check is visible in the decoded dispatch; authorization must be verified from the code paths.
  • [medium] Dynamic fee applied on swaps: The hook can charge a dynamic fee on swaps through beforeSwap, so users may pay higher effective fees than a static pool fee during the sniper window or after configured schedules.
  • [low] Whitelist controls fee exemption: Whitelist membership per pool determines who is exempt from sniper-window fees, creating a privileged list that can be changed by the setter.
  • [info] No direct fund custody observed: The hook is not upgradeable based on the decoded functions, and it has no return-delta or fund-taking permission, so it does not hold pool funds directly.

Contract details

Verified source
No
Bytecode size
5,660 bytes
Upgradeable proxy
No

Pools using Fee sharing hook