Hook 0x6b70…4040 on Arbitrum

Uniswap v4 Hook Contract 0x6b70fef40d3925881251c018164dbcec6bc94040 on Arbitrum · Other

Volume (24h)
$2.45M
Value locked (TVL)
$4.98M
All-time volume
$319.51M
Pools using this hook
2
Swaps (24h)
1,313 (293 traders)
Total swaps
621,457

What it does

A hook with an afterSwap callback that appears to apply address-based access checks, managed by an admin who maintains allow or deny lists.

How it works step by step

  • Runs logic after every swap via the afterSwap callback
  • Reads a stored address in slot 1 that is likely a token or configuration reference
  • Checks a per-address mapping (slot 4) during afterSwap
  • Maintains a second address mapping (slot 5) through admin-only setters
  • Supports a two-step admin handover via transferAdmin and acceptAdmin
Swap behaviour
afterSwap runs after each swap and reads a stored address and a per-address mapping; the exact effect on the swap is not confirmed from the bytecode.
Liquidity behaviour
beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity and afterRemoveLiquidity are present as dispatched selectors, but their bodies were not analysed in detail; no liquidity-altering behaviour was confirmed.
Fee behaviour
Does not set or take fees directly; no fee logic was identified in the decoded functions. Uses the pool's static fee unless the afterSwap logic does otherwise, which cannot be confirmed.
Owner & admin controls
Two-step admin transfer: transferAdmin(address) sets a pending admin in slot 3 and acceptAdmin() completes it. The admin can also add or remove addresses from two mappings (slots 4 and 5) via functions 0x48d7d768/0x82e2d568 (address[],bool) and 0xcf6dba7a/0xd54e987f (address,bool). The role these mappings gate is inferred from the afterSwap read of slot 4 and 5 and cannot be confirmed without source.

Enabled Uniswap v4 callbacks

afterSwap

afterSwap: the only enabled callback. It reads slot 1 (a stored address, possibly the USDC or an associated token) and the allow/deny mapping in slot 4, suggesting address-gated post-swap logic.

Security & trust assessment

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

Who controls it: The admin can grant or revoke addresses in two access mappings and can hand off admin rights. If those mappings gate swap behaviour or any fund movement, the admin key controls which addresses can trade or be affected.

Risk to user funds: No evidence in the decoded bytecode that the hook takes tokens via return deltas or holds pool funds. Exposure is limited to the possibility that afterSwap reverts or restricts specific addresses, which cannot be confirmed without source.

Security findings

  • [medium] Privileged admin key controls access lists: Admin controls two address mappings (slots 4 and 5) and admin rights are transferable via a two-step process, so a single key governs access.
  • [low] Address-gated afterSwap may block specific traders: The afterSwap callback reads a mapping keyed by address; if it reverts or blocks for listed addresses, swaps by those addresses could fail.
  • [info] Unverified source limits analysis: The contract is not verified, so the exact logic of the afterSwap body and the purpose of the mappings was inferred from storage reads and selectors only.

Contract details

Verified source
No
Bytecode size
6,953 bytes
Upgradeable proxy
No

Pools using Hook 0x6b70…4040