Custom pricing hook on Ethereum

Uniswap v4 Hook Contract 0x6d3e3447440359911f2e715f332e3609d3d0aacc on Ethereum · Custom pricing

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

What it does

This hook appears to run a genesis-phase token launch in which buys and sells are adjusted by fixed BUY_BPS and SELL_BPS rates and liquidity changes are gated by a phase flag, but the exact direction of fee adjustments and which trades pay more cannot be confirmed from the decoded bytecode.

How it works step by step

  • Proxy delegates to an implementation whose functions include poolKey, poolId, tickSpacing, manager, vault, token, treasury, hook, genesis, phase, open, SELL_BPS and BUY_BPS, indicating a token launch or genesis-style pool with buy and sell fee tiers
  • beforeInitialize sets a single storage flag (slot 0) that is also written by open(), so the pool's launch state is gated by one uint8 phase variable
  • beforeAddLiquidity and beforeRemoveLiquidity are view functions that appear to gate liquidity actions based on the phase value read from slot 0
  • beforeSwap and afterSwap take permissions that allow return deltas, so the hook can take or give part of the swap amounts; the implementation also references a mint call and a NotGenesis error, suggesting minting of tokens or claims during the genesis phase
  • open() is nonpayable and writes slot 0, moving the pool out of the genesis phase; the exact transition rules cannot be confirmed from bytecode alone
Swap behaviour
beforeSwap and afterSwap are called on every swap; the hook can adjust the swap via before-swap and after-swap return deltas, and buy and sell rates are defined by BUY_BPS and SELL_BPS constants, so buys and sells are likely taxed or adjusted at different rates, but the exact direction and amount cannot be confirmed from decoded bytecode.
Liquidity behaviour
beforeAddLiquidity and beforeRemoveLiquidity are view checks that read the phase value; they appear to restrict or allow liquidity changes depending on the launch phase, without modifying state.
Fee behaviour
Swap fees or adjustments are driven by the BUY_BPS and SELL_BPS constants combined with the return-delta mechanism; exact fee values and how they are routed to the treasury or vault cannot be determined from the input.
Owner & admin controls
The implementation exposes treasury, vault and hook addresses and an open() function; no owner or pause function was decoded, but the proxy is upgradeable, so the implementation (and therefore all behaviour) can be changed by whoever controls the proxy admin, which cannot be determined from the input.

Enabled Uniswap v4 callbacks

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

beforeInitialize initializes the hook state for the pool; beforeAddLiquidity and beforeRemoveLiquidity gate liquidity changes by phase; beforeSwap and afterSwap apply the buy and sell adjustments; beforeSwapReturnDelta and afterSwapReturnDelta let the hook take a share of swap amounts.

Security & trust assessment

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

Who controls it: A privileged key controlling the proxy admin could upgrade the logic to change fees, redirect the taken amounts to another address, or mint claims; the open() function and phase transition may also be restricted to a single controller, which cannot be confirmed from bytecode.

Risk to user funds: The hook can take a share of swap amounts through return deltas and route it to treasury or vault addresses, and its phase gating can block liquidity removal or swapping while the phase is unchanged; user funds can therefore be taxed or temporarily locked by the hook's logic.

Security findings

  • [high] Upgradeable proxy: The hook is a proxy delegating to implementation 0x2f2c374e2c8a8af3ea8f0c23b3c3e4fabfd5b19d; whoever controls the upgrade path can replace the logic, including the swap and fee code, at any time.
  • [medium] Return deltas on swaps: beforeSwapReturnDelta and afterSwapReturnDelta are enabled, so the hook can take tokens from swap amounts; the rate is set by BUY_BPS and SELL_BPS constants and the destination by treasury and vault addresses.
  • [medium] Mint call in implementation: The bytecode references a mint(address,uint256,uint256) selector, which indicates the hook can mint ERC6909 claims or tokens, a possible source of dilution if called without strict gating.
  • [low] Phase flag controls liquidity and swaps: A single uint8 in slot 0 is read by liquidity and swap paths and written by open(), so the phase transition is a single point of control over when trading and liquidity are allowed.

Contract details

Verified source
No
Bytecode size
960 bytes
Upgradeable proxy
Yes
Detected patterns
erc6909-claims, liquidity-management, return-delta, upgradeable

Pools using Custom pricing hook