Auction hook on Robinhood Chain

Uniswap v4 Hook Contract 0x124a777e543b650d99ca7bbaeef230bbb2e4ea64 on Robinhood Chain · Auction

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

What it does

This hook runs an auction over pool fees where bidders deposit into bids, accrued fees are burned or claimed, and swaps can have a share taken via return deltas, but the exact fee amounts and which trades pay more cannot be determined from the bytecode alone.

How it works step by step

  • Runs an auction-style mechanism over pool fees: bidders deposit into bids via depositIntoBid and withdrawFromBid, tracked per pool key in storage slots 0 through 2 and 4
  • Accrues fees per pool and lets them be claimed with claimFees and collect, with getFees exposing the balances
  • Burns accrued value through crankBurn and updateStateMachine, tracked by totalBurned, totalBurnSpent, lastBurnBlock and burnBucket
  • Refunds bidders through claimRefund and getRefund, keyed by pool id and address
  • Uses return deltas in afterSwap (afterSwapReturnDelta is enabled) and calls the pool manager's unlock flow via self-unlock with unlockCallback
  • Gates pool initialization in beforeInitialize, storing per-pool flags, and hooks liquidity add and remove and donate callbacks, which appear to return default behaviour
Swap behaviour
afterSwap is implemented and can adjust the swap's return delta, so the hook may take a share of swap output or input. Exact direction and size cannot be determined from decoded bytecode.
Liquidity behaviour
beforeAddLiquidity and beforeRemoveLiquidity are enabled and afterRemoveLiquidity is present in the dispatch table; positions(bytes32,address) is exposed for reading. Whether liquidity changes are restricted or taxed cannot be confirmed from bytecode alone.
Fee behaviour
currentFee(bytes32), DEFAULT_FEE, FEE_CAP, WITHDRAW_FEE and BURN_SHARE indicate a configurable fee with a cap and a share directed to burning and withdrawal; the exact fee computation is not recoverable from decoded bytecode.
Owner & admin controls
No owner or pause selector is visible in the dispatch table, but the decoded selectors do not establish who may call setup or fee functions. Admin controls cannot be confirmed without source.

Enabled Uniswap v4 callbacks

beforeInitialize, beforeAddLiquidity, beforeRemoveLiquidity, afterSwap, beforeDonate, afterSwapReturnDelta

beforeInitialize gates pool setup; beforeAddLiquidity and beforeRemoveLiquidity run checks around LP changes; afterSwap updates accounting and sets return deltas; beforeDonate and afterDonate are present for donation handling.

Security & trust assessment

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

Who controls it: Without source, it is unknown whether a privileged key can alter fee parameters, the burn share or bid settlement; any such control would directly change what users pay.

Risk to user funds: The hook holds bid deposits and accrued fees in its own balances and moves currency through take and unlock during swaps and claims, so user funds in those balances depend on the correctness of this logic.

Security findings

  • [medium] Hook takes value via return deltas: afterSwapReturnDelta is enabled and afterSwap writes accounting, so the hook can take a portion of swap flows from users and redirect it to bids, burns or fee withdrawals.
  • [medium] Currency movement through take and unlock: The bytecode references the take(address,address,uint256) selector and self-unlock via unlockCallback, meaning the hook moves pool currency itself during callbacks.
  • [medium] Unverified source: No verified source is available, so fee bounds, burn logic and withdrawal permissions rest on decoded selectors and storage inference only.

Contract details

Verified source
No
Bytecode size
20,300 bytes
Upgradeable proxy
No
Detected patterns
auction, fee-sharing, moves-currency, return-delta, self-unlock

Pools using Auction hook