Launchpad hook on Ethereum
Uniswap v4 Hook Contract 0xbe3ee88690d4c4999fff908d151823715b6325cc on Ethereum · Launchpad
- Volume (24h)
- $0
- Value locked (TVL)
- $0
- All-time volume
- $0
- Pools using this hook
- 1
- Swaps (24h)
- 468 (180 traders)
- Total swaps
- 468
What it does
This launchpad hook taxes early buys during a protection window, limits how much each address can buy, and sends the collected fees to configured recipients, with normal trades after protection paying only the base pool fees.
How it works step by step
- Initializes a pool with a launch protection window, recording the launch time and a protection end time at pool initialization
- During an early protection period, applies a buy tax that decreases over time and limits how much each buyer address can purchase
- Tracks per-address purchases in a mapping and enforces a buyer limit, reverting with BuyerLimitExceeded when exceeded
- Routes collected fees to configured recipients (dev recipient, platform recipient, fee vault, opening tax vault) and uses a distributor component
- Uses return deltas in beforeSwap and afterSwap to take a fee from swaps, and mints or claims ERC6909 balances for fee accounting
- Counts swaps and records per-epoch data after the protection period ends
- Swap behaviour
- Swaps pass through beforeSwap and afterSwap with return delta permissions enabled; during the protection window buys are taxed by a buy fee that depends on the buyer and time, and buyers exceeding the per-address limit are rejected. Sells and buys after protection likely pay only the base fees, but exact fee amounts cannot be confirmed from decoded bytecode.
- Liquidity behaviour
- afterAddLiquidity and afterRemoveLiquidity callbacks are enabled and may update accounting or claims; beforeAddLiquidity and beforeRemoveLiquidity selectors exist but their gating logic cannot be confirmed from bytecode alone.
- Fee behaviour
- Fees are set through totalFee, LP_FEE, PLATFORM_FEE, DEV_FEE and a per-address buyFee during protection; these are split between platform, developer, fee vault and tax vault recipients. Exact split logic is not verifiable from decoded bytecode.
- Owner & admin controls
- A deployer-only check (NotDeployer error) appears to restrict some setup functions such as bind or initialize; a protection module and distributor are referenced, but whether the owner can change fees, recipients or pause trading cannot be determined from the decoded bytecode.
Enabled Uniswap v4 callbacks
beforeInitialize, afterAddLiquidity, afterRemoveLiquidity, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta
beforeInitialize sets launch and protection parameters; afterAddLiquidity and afterRemoveLiquidity update liquidity-related accounting; beforeSwap applies buyer limits and protection tax; afterSwap records purchases and swap counts; beforeSwapReturnDelta and afterSwapReturnDelta let the hook take a fee from swap amounts.
Security & trust assessment
Risk level: medium, estimated (decoded bytecode, low confidence).
Who controls it: A privileged deployer or beacon owner may be able to set recipients, fee parameters or upgrade logic, which could redirect protection taxes to chosen addresses.
Risk to user funds: The hook can take tokens from swaps through return deltas and route them to recipient addresses, and it may hold balances in ERC6909 claims for fee accounting.
Security findings
- [medium] Return deltas take a swap fee: beforeSwapReturnDelta and afterSwapReturnDelta are enabled, so the hook can take a portion of swap amounts from traders during protection.
- [medium] Buyer limit can block purchases: The BuyerLimitExceeded error and per-address purchase mapping mean buys can revert once a limit is reached during the protection window.
- [info] Deployer-gated setup: A NotDeployer error and deployer() accessor suggest privileged setup functions are restricted to one address.
- [info] Upgradeable beacon reference: A beacon() accessor suggests the contract may sit behind a beacon proxy, which would allow implementation upgrades by the beacon owner.
- [info] Fee recipients are configurable: Multiple recipient addresses (dev, platform, fee vault, tax vault) are stored, so fee destinations depend on configuration that could be set by privileged roles.
Contract details
- Verified source
- No
- Bytecode size
- 10,608 bytes
- Upgradeable proxy
- No
- Detected patterns
- erc6909-claims, launchpad, liquidity-management, return-delta, tax