Launchpad hook on Ethereum

Uniswap v4 Hook Contract 0xb5db78452658440674cadcc342050728eca7ffff on Ethereum · Launchpad

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

What it does

This launchpad hook charges a basis-point fee on swaps and adds extra snipe restrictions during an early launch window, so early buyers in that window are likely to pay more than later traders, with the fee then split between holders, liquidity and reward recipients.

How it works step by step

  • Attached to a pool at initialization (afterInitialize stores the pool key and the launch timestamp), so the hook is designed around a single launched token pool.
  • Tracks a snipe window (SNIPE_WINDOW, snipeBps, SNIPE_MAX_BPS) and can restrict or tax early buyers during the launch period.
  • Collects a fee on swaps (feeBps, MAX_FEE_BPS, HOLDER_FEE_BPS) and accumulates pending fees, which are split into slices of recipients (slices, MAX_SLICES) and distributed through distribute() with a minimum threshold (minDistribute).
  • Routes fee and reward flows to a reward contract, with addRewards, a council address and a sink allowlist (isSink) controlling who receives value.
  • Supports an optional module system (modules, MAX_MODULES, disableModule) that runs extra logic in beforeSwap via onBeforeSwap, with a gas budget (MODULE_GAS).
  • Manages its own liquidity through an unlock callback (addLiquidity, collectFees, take, unlockCallback) and issues or burns ERC6909 claims for pool accounting.
Swap behaviour
Before a swap the hook can apply a fee and snipe-protection logic (beforeSwap, with a return delta), and after a swap it updates accounting and pending fees (afterSwap, with a return delta). Trades inside the snipe window in the early launch period are expected to pay more through the snipe and fee parameters; trades outside it pay the base fee (feeBps), and the exact direction and magnitude could not be confirmed from decoded bytecode alone.
Liquidity behaviour
Liquidity add and remove calls are hooked before and after (beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity, afterRemoveLiquidity, with return deltas on the after-hooks). Liquidity can also be placed by the hook itself through addLiquidity and fees collected via collectFees, with a return delta that can adjust the caller's balance.
Fee behaviour
Fees are charged as basis points (feeBps, capped by MAX_FEE_BPS), accumulated as pendingFees and totalFees, then distributed to recipients by slices and rewards. A holder fee (HOLDER_FEE_BPS) and a launch LP fee (LAUNCH_LP_FEE) also appear, so part of the swap fee is routed to holders and part to liquidity.
Owner & admin controls
A council address (setCouncil, council, COUNCIL) appears to hold privileged rights, and disableModule lets an authorised party turn off modules. The slice and sink lists (slices, isSink) are set by privileged functions. No pause or proxy upgrade function was identified, but the owner-level permissions could not be fully determined from bytecode.

Enabled Uniswap v4 callbacks

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

beforeInitialize and afterInitialize set up the pool and launch time; beforeSwap and afterSwap apply the snipe and fee logic and return deltas; beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity and afterRemoveLiquidity track LP activity and return deltas; beforeDonate and afterDonate are hooked for accounting around donations; the return-delta flags let the hook take or adjust currency during swaps and liquidity changes.

Security & trust assessment

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

Who controls it: A council or owner key can change the council, add or disable modules, and control sink and slice recipients, which can redirect fee and reward flows.

Risk to user funds: The hook can take currency through return deltas during swaps and liquidity changes, and it holds accumulated pendingFees before distribution, so user funds in the pool and fee balances are exposed to the hook's logic and privileged parameters.

Security findings

  • [high] Hook takes currency via return deltas: The hook enables beforeSwapReturnDelta, afterSwapReturnDelta and liquidity return-delta permissions, and it moves currency through take and the ERC6909 burn and mint selectors. This means it can take a portion of user swap and liquidity amounts.
  • [medium] Privileged council and module control: setCouncil, disableModule and the sink and slice lists give a privileged key the ability to redirect fee flows and change which modules run in beforeSwap. A compromised council key could redirect fees.
  • [medium] Snipe restriction can block or tax trades: The beforeSwap snipe logic can restrict early trades during SNIPE_WINDOW, so some users may pay substantially more or be unable to trade at launch.
  • [medium] External module execution in swap path: Modules run inside beforeSwap with a gas budget (MODULE_GAS), so a malicious or buggy module could affect swap execution.
  • [info] Source not verified: Analysis relies on decoded bytecode and selectors without verified source, so exact formulas and access checks are inferred.

Contract details

Verified source
No
Bytecode size
22,072 bytes
Upgradeable proxy
No
Detected patterns
erc6909-claims, fee-sharing, launchpad, moves-currency, return-delta, rewards, self-unlock

Pools using Launchpad hook