Launchpad hook on Robinhood Chain

Uniswap v4 Hook Contract 0x88d312dd935719d54ffb4aeae7d3943a823620cc on Robinhood Chain · Launchpad

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

What it does

This launchpad hook takes a fixed fee on swaps that is split between the treasury and the token creator, and it also handles token launch and lot bookkeeping; the exact fee rate and which trades pay more could not be confirmed from the bytecode alone.

How it works step by step

  • Exposes a launch(string,string,string) entry point that deploys and initializes a new token paired in a Uniswap v4 pool, with lot bookkeeping (lots, lotCount, lotOfPool, lotOfToken).
  • Implements beforeInitialize and afterInitialize to register the pool and its lot during pool creation.
  • Uses beforeSwap and afterSwap with return-delta permissions, so the hook can take or give currency during swaps and records per-lot state (mapping of lot to uint128 and bool flags).
  • Accrues an owed balance per address (owed, claim, claimFor) that is credited during swaps and paid out to recipients, indicating a creator or treasury share of trading flows.
  • Calls unlock/settle/take/sync on the pool manager, meaning the hook itself moves currency to and from the pool manager and holds funds before distributing them.
  • Exposes constants for a creator share, treasury cut, fee, tick spacing, range, supply and opening FDV, which parameterize how fees and proceeds are split.
Swap behaviour
beforeSwap and afterSwap are both enabled with return-delta permissions, so the hook can alter the swap amounts or take a cut of currency on each swap; the exact percentage charged on swaps is set by the FEE_BPS and TREASURY_CUT_BPS constants and the creator share, which could not be read directly from the decoded bytecode.
Liquidity behaviour
beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity and afterRemoveLiquidity selectors are present in the dispatch table, but the corresponding permission flags are not set, so the pool manager does not call them; liquidity is effectively unrestricted by the hook.
Fee behaviour
Fees appear to be a fixed basis-point cut on swaps (FEE_BPS, with TREASURY_CUT_BPS and CREATOR_SHARE_BPS dividing the proceeds between treasury and creator), taken via the afterSwap or beforeSwap return delta; the pool itself uses a static pool fee (POOL_FEE).
Owner & admin controls
No owner, pause or upgrade functions were identified among the dispatched selectors; treasury() and launcher() reads suggest a treasury address and a launcher address that are set at deployment, but whether they can be changed could not be determined.

Enabled Uniswap v4 callbacks

beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta

beforeInitialize registers the pool and lot at creation; afterInitialize completes lot setup; beforeSwap and beforeSwapReturnDelta let the hook intercept swaps and adjust amounts; afterSwap and afterSwapReturnDelta let the hook take fee currency after each swap.

Security & trust assessment

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

Who controls it: Without source it is not clear whether a privileged key can change fee or treasury parameters; the treasury and launcher addresses are read from storage, so a key that controls them could redirect the treasury share of fees.

Risk to user funds: The hook holds and moves currency through the pool manager during swaps and launches and tracks owed balances per address, so user and pool funds pass through hook-controlled accounting, and a bug in owed or claim logic could lock or misdirect funds.

Security findings

  • [medium] Hook takes currency via return deltas: beforeSwapReturnDelta and afterSwapReturnDelta are enabled and the bytecode calls take, settle and sync, so the hook moves user swap currency to itself and to the treasury and creator owed balances on every swap.
  • [medium] Owed balances are withdrawable by claim functions: The owed mapping is credited during swaps and paid out through claim() and claimFor(address); correct accounting between these paths was not verifiable from bytecode alone.
  • [info] Self-unlock pattern: The hook calls unlock on the pool manager and handles unlockCallback itself, a common pattern for moving currency during launch and fee collection; its correctness depends on the callback checks, which could not be confirmed.
  • [info] Unverified source: No verified source is available, so exact fee percentages, access checks on launch and claim paths, and whether treasury or launcher can be changed remain unconfirmed.

Contract details

Verified source
No
Bytecode size
13,929 bytes
Upgradeable proxy
No
Detected patterns
erc20, launchpad, moves-currency, return-delta, self-unlock

Pools using Launchpad hook