Likely access control hook on Monad

Uniswap v4 Hook Contract 0x854413fb25b51cf4f48bedaa8235885a695ec440 on Monad · Access control

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

What it does

A hook with owner-managed configuration that runs state-changing logic after swaps and liquidity additions, apparently tracking a token reference and random-like counters, with no clearly identified fee or pricing effect for traders or LPs.

How it works step by step

  • Enables afterAddLiquidity and afterSwap callbacks only
  • afterSwap updates storage counters (slots 1 and 2) and reads the token reference
  • afterAddLiquidity runs a nonpayable handler that reads the token reference
  • Owner can set the token address via setToken and the other address setter
  • Ownable access control with two-step ownership handover
  • Exposes randomSeed() and randomCount() view getters
Swap behaviour
afterSwap performs a nonpayable state update after each swap; beforeSwap is a view stub with no visible effect.
Liquidity behaviour
afterAddLiquidity (0x9f063efc) is implemented and writes state; beforeAddLiquidity and beforeRemoveLiquidity are view stubs. afterRemoveLiquidity is present as a dispatched selector but its behaviour is unclear from the bytecode.
Fee behaviour
No fee logic identified; the hook does not appear to set or take fees (beforeSwap is a view stub and no return-delta or fee override is visible).
Owner & admin controls
Owner-controlled via Ownable-style functions: transferOwnership, renounceOwnership, and a two-step ownership handover (requestOwnershipHandover, cancelOwnershipHandover, completeOwnershipHandover). Selector 0x9218cf15 and setToken(address) (0x144fa6d7) are nonpayable setters that write the token slot (slot 0), so the owner can likely reconfigure the tracked token address. No pausing or upgrade function identified.

Enabled Uniswap v4 callbacks

afterAddLiquidity, afterSwap

afterAddLiquidity: executes a nonpayable state-changing handler after LP additions, apparently tracking or updating token-related state. afterSwap: executes a nonpayable handler after swaps that reads and writes counters (slots 1 and 2), possibly for a random seed or count. Only these two callbacks are enabled by the hook permissions.

Security & trust assessment

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

Who controls it: The owner holds the token-address setter and ownership transfer rights. A malicious or compromised owner could repoint the token reference used by the hook, and could transfer or renounce control at will. The two-step handover reduces accidental transfers but not malicious ones.

Risk to user funds: The hook does not take return deltas or fee overrides visible in the decoded callbacks, so it does not appear to hold or move pool funds directly. Risk to users comes from owner reconfiguration of the token reference and from any unknown logic in the state-changing afterSwap and afterAddLiquidity handlers.

Security findings

  • [medium] Owner can reconfigure the token reference: Selector 0x144fa6d7 (setToken) and 0x9218cf15 are nonpayable writers to the address stored in slot 0, which the afterAddLiquidity and afterSwap handlers read. Changing it alters hook behaviour for live pools.
  • [info] Ownership can be transferred: Ownable functions (transferOwnership, completeOwnershipHandover) let the owner move control of the hook to any address.
  • [low] State writes on every swap and LP action: afterSwap and afterAddLiquidity mutate storage (random seed and count slots) on every call, adding gas cost to trades and LP actions.
  • [info] Unverified source: Source is unverified; behaviour is inferred from selectors, storage writes and error names (TokenNotSet, OnlyPoolManager), so the exact logic is uncertain.

Contract details

Verified source
No
Bytecode size
3,882 bytes
Upgradeable proxy
No
Detected patterns
ownable

Pools using Likely access control hook