Launchpad hook on Arc

Uniswap v4 Hook Contract 0xbaba3f590b3661de78998d1576a73a4d726b2acc on Arc · Launchpad

Volume (24h)
$21
Value locked (TVL)
$2.61K
All-time volume
$3.05M
Pools using this hook
270
Swaps (24h)
3 (3 traders)
Total swaps
27,688

What it does

A router-style hook that registers one pool per token and, on swaps, takes part of the swap amounts through return deltas and sends them to external contracts. Liquidity changes and pool initialization are gated by registration checks.

How it works step by step

  • Keeps a registry that maps a token to its pool (poolForToken) and a registration entry per pool id (registrations). Both are written by one nonpayable registration function, selector 0xd7eddba5.
  • beforeInitialize, beforeAddLiquidity and beforeRemoveLiquidity read the registration mapping, so they probably allow only registered pools or restrict who can act. The exact rules cannot be confirmed from the decoded bytecode.
  • beforeSwap and afterSwap use return deltas, so the hook can take or credit currency during a swap. The bytecode references take(address,address,uint256) and balanceOf, which fits settling taken amounts.
  • It calls external contracts named by selectors: feeVault(), gateHook(), sharedHook(), adapter() and quoteAsset(). It also calls mint(address,uint256,uint256). Together these suggest fees are routed to a vault and swaps may be gated or delegated to other hooks.
  • It exposes launcherConfig(address), RAD_AMOUNT() and binder(), and checks expectedChainId(). These suggest a launcher-style setup bound to a specific chain and binder address, but their exact meaning is unknown.
Swap behaviour
beforeSwap and afterSwap are nonpayable and read the pool registration. The hook uses beforeSwapReturnDelta and afterSwapReturnDelta, so it can take part of the swap amounts or adjust what the swapper receives. It most likely forwards the taken value via take() to a fee vault or another contract. The exact fee math and gating logic cannot be determined without source.
Liquidity behaviour
beforeAddLiquidity and beforeRemoveLiquidity are view checks that read the pool registration mapping. They probably revert for unregistered pools or unauthorized actors. No liquidity return deltas are enabled, so the hook does not take funds on liquidity changes directly.
Fee behaviour
The pool's LP fee is not overridden by the hook. Through return deltas the hook takes an additional amount on swaps and probably routes it to an external feeVault. The rate and split are not visible in the decoded bytecode.
Owner & admin controls
A privileged registration function (0xd7eddba5) writes the registry, and a binder() address exists. The access check on this function is not visible, so who can register pools or change the external contracts it calls is unknown. No pause or upgrade functions are visible in the dispatched selectors.

Enabled Uniswap v4 callbacks

beforeInitialize, beforeAddLiquidity, beforeRemoveLiquidity, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta

beforeInitialize validates or binds pool creation to the registry. beforeAddLiquidity and beforeRemoveLiquidity check registration or access rules for liquidity changes. beforeSwap applies the swap-time gating and delta logic. afterSwap performs post-swap settlement. beforeSwapReturnDelta and afterSwapReturnDelta let the hook take or credit currency amounts during swaps.

Security & trust assessment

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

Who controls it: Whoever controls registration, the binder or the external vault and gate contracts could decide which pools are valid and where taken fees go. They could potentially also block swaps through the gate or change fee routing. The extent of these powers cannot be confirmed.

Risk to user funds: The hook does not appear to custody LP positions, but it can take currency from swaps through return deltas and may handle ERC6909 claims or tokens briefly. A faulty or malicious external vault or gate contract could cause loss of swap value or block swaps and liquidity actions.

Security findings

  • [medium] Hook takes value via return deltas: beforeSwapReturnDelta and afterSwapReturnDelta are enabled, and the bytecode calls take(address,address,uint256) and balanceOf. The hook can therefore divert part of swap amounts, and the amount cannot be verified without source.
  • [medium] Depends on external contracts: It calls feeVault(), gateHook(), sharedHook(), adapter() and quoteAsset() on other contracts. A fault or malicious change in those contracts could block swaps or redirect fees.
  • [low] Registration function access unclear: Selector 0xd7eddba5 is nonpayable and writes the pool registry. The caller restriction (probably the binder) cannot be confirmed from the decoded bytecode.
  • [low] Swaps and liquidity depend on registry state: Swap and liquidity callbacks read the registry. Pools that are unregistered or misconfigured may revert, which could block trading or LP exits.
  • [info] Unverified source: No verified source is available, so behaviour is inferred from selectors, storage and permissions. The chain-bound expectedChainId() suggests a deployment tied to chain 5042.

Contract details

Verified source
No
Bytecode size
10,711 bytes
Upgradeable proxy
No
Detected patterns
erc6909-claims, moves-currency, return-delta

Pools using Launchpad hook