Launchpad hook on Ethereum

Uniswap v4 Hook Contract 0xc3774a7456c4cfe8e44d780877c9771d6562e0cc on Ethereum · Launchpad

Volume (24h)
$39.88K
Value locked (TVL)
$13.50K
All-time volume
$39.88K
Pools using this hook
3
Swaps (24h)
187 (75 traders)
Total swaps
187

What it does

This launchpad hook charges a dynamic fee on swaps, with a higher starting rate during an early snipe window that decays, so early buyers pay more while later trades pay less, and it splits the collected fees between a platform wallet and a fee recipient.

How it works step by step

  • Acts as a launchpad hook: beforeInitialize registers a new token pool and records its launch parameters, and the hook tracks launched tokens in an address array (allTokens, tokensCount)
  • Charges a dynamic fee per swap through currentFeeBps, with a sniper-protection window (SNIPE_START_BPS, SNIPE_DURATION) that appears to start high and decay
  • Accrues fees per token in an internal mapping (pendingFees) and splits them between a platform wallet (platformShareBps, platformWallet) and a fee recipient set by setFeeRecipient
  • Mints an ERC-6909 claim balance for accrued fees and lets holders redeem them with claim(address)
  • Uses return deltas in beforeSwap and afterSwap, so it can take a cut of swap amounts directly and settle currency with the PoolManager via unlock/unlockCallback and self-unlock
  • Exposes a launch fee (launchFee) and a migrateEth entry point, indicating a migration of ETH-side liquidity into a Uniswap v2/v3-style pool or position manager
Swap behaviour
beforeSwap and afterSwap both run. beforeSwap computes the current dynamic fee for the pool and can return a delta that takes a portion of the swap amount. afterSwap settles fees and may return a further delta. Trades in the sniper window are likely charged a higher fee than trades after it ends, but this is inferred from the selector names and storage, not confirmed from logic.
Liquidity behaviour
beforeAddLiquidity, beforeRemoveLiquidity, afterAddLiquidity, afterRemoveLiquidity and beforeDonate/afterDonate are exposed as selectors but are not enabled in the hook permissions, so the PoolManager will not call them. Liquidity is handled by the PoolManager and the position manager, and the hook does not appear to intercept it.
Fee behaviour
Fees are dynamic: currentFeeBps(pool) returns a per-pool rate capped by MAX_FEE_BPS, with a higher starting level during the snipe window (SNIPE_START_BPS, SNIPE_DURATION). Collected fees are tracked in pendingFees and split between the platform (platformShareBps to platformWallet) and the fee recipient (setFeeRecipient). Exact fee values cannot be determined without source.
Owner & admin controls
setFeeRecipient(address,address) is callable and changes the fee recipient for a pool or token; access control cannot be confirmed from bytecode. platformWallet and platformShareBps are stored values that a privileged role may be able to change. No pause or upgrade mechanism was identified from the selectors.

Enabled Uniswap v4 callbacks

beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta

beforeInitialize: registers the new pool and token launch state when the pool is created. beforeSwap: sets the dynamic fee and may take a return delta. afterSwap: settles accrued fees and may take a return delta. beforeSwapReturnDelta and afterSwapReturnDelta: allow the hook to take currency from swaps, which is why it can collect fees.

Security & trust assessment

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

Who controls it: A privileged key that can call setFeeRecipient could redirect pending fees, and one that controls platformWallet or platformShareBps could change the split between platform and recipient. The bytecode does not show a pause or proxy upgrade path.

Risk to user funds: The hook can take currency from swaps through return deltas and holds accrued fees in pendingFees before they are claimed. Pool funds are not expected to be blocked, but the hook can extract a portion of trade flow and hold claim balances.

Security findings

  • [medium] Hook takes currency via return deltas: beforeSwapReturnDelta and afterSwapReturnDelta are enabled, so the hook can take a share of every swap in the pool. The fee schedule and recipient determine how much is taken.
  • [medium] Fee recipient change without visible gating: setFeeRecipient is nonpayable and writes to the mapping in slot 0. Without source it is not confirmed that only an authorized role can call it, so a compromised or malicious caller could redirect accrued fees.
  • [low] Snipe-window fee schedule: The SNIPE_START_BPS and SNIPE_DURATION constants indicate a time-decaying fee on early trades. Its rate and bounds are not confirmed from source.
  • [info] Unverified source: Analysis relies on decoded bytecode and selector names only; internal logic, access checks and arithmetic cannot be fully verified.

Contract details

Verified source
No
Bytecode size
21,264 bytes
Upgradeable proxy
No
Detected patterns
dynamic-fee, erc20, erc6909-claims, fee-sharing, launchpad, moves-currency, return-delta, self-unlock

Pools using Launchpad hook