QuirkHookV5 on Robinhood Chain

Uniswap v4 Hook Contract 0xf3db1d79948e1c87fc8286fd0951d8432970aaec on Robinhood Chain · Launchpad · Verified contract

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

What it does

On this launch pool, buys and sells both pay a decaying fee that starts high and falls to a 1% to 10% base rate, with buys also limited by anti-snipe and wallet caps during the launch window, and LPs cannot remove or donate liquidity through the hook.

How it works step by step

  • Acts as the Uniswap v4 hook for a token launchpad pool that pairs a launched token against a quote asset, with the hook address mined so only the flagged callbacks are enabled.
  • Gates the initial liquidity add to the factory's vault, allowing exactly one full-range-style position at the configured initial tick before the pool is marked live.
  • Applies a decaying buy/sell fee (decay from a start rate down to a base rate over a configured duration) and optional anti-snipe per-block buy limits and max buy/wallet caps during the launch window.
  • Takes the fee as a before-swap return delta, mints the fee amount to the hook as ERC6909 credit, and routes it through a revenue engine that splits it between creator, dividend, king, burn, liquidity and protocol shares.
  • Runs an optional automation path where the revenue engine can buy back the token or add liquidity via the vault, guarded by a TWAP-style tick check and a per-pool processing threshold.
  • Restricts the swap path to registered routers and the unlock-based settlement flow so that public swaps must settle the exact token leg in the same transaction.
Swap behaviour
Buys and sells both pay a fee taken from the input amount: the fee starts at the configured decay start rate and falls linearly to the base buy or sell rate over the decay duration, when decay is enabled; otherwise the base rate applies. Buys may also be subject to anti-snipe rate limits, max buy and max wallet caps, and plague holding requirements during the launch window. Swaps must be made through an allowed router or an authenticated public path, must be exact-input, and revert on partial fills. The fee is taken as a before-swap return delta on buys and an after-swap return delta on sells.
Liquidity behaviour
Only the vault can add liquidity, and only once during preparation at the exact initial tick range; afterward the hook reverts liquidity changes except for automated liquidity operations it authorises during revenue processing. Remove liquidity and donate are always reverted.
Fee behaviour
Fees are set by the configured base buy/sell rates (1% to 10%), the decay schedule, and an optional king fee of up to 2% on buys. The total fee is split by the revenue policy: 30% of the base fee goes to protocol, the remainder and decay portion are divided among the configured creator, dividend, king, burn and liquidity shares, with pool-specific recipients and a protocol-only mode available.
Owner & admin controls
Pool registration is restricted to the sealed factory and seal occurs once via a deployment authority. The revenue engine's creator recipient can be changed by a fee controller address set at deployment. The contracts are immutable with no proxy or pause mechanism visible in the decoded interface, but the deployment authority and fee controller are privileged addresses and their exact powers depend on the sealed components, which were not provided. No pause function is visible.

Enabled Uniswap v4 callbacks

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

beforeInitialize restricts pool initialisation to the factory at the configured tick; beforeAddLiquidity gates the single initial liquidity add to the vault; beforeRemoveLiquidity and beforeDonate always revert; beforeSwap computes and charges the decaying fee and enforces launch limits, and also authorises revenue-engine automation swaps; afterSwap finalises fee accounting, dividend accrual, anti-snipe counters and settlement proof, and triggers automation attempts; beforeSwapReturnDelta and afterSwapReturnDelta let the hook take its fee from swap deltas; afterInitialize, afterAddLiquidity, afterRemoveLiquidity and afterDonate always revert.

Security & trust assessment

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

Who controls it: The deployment authority and fee controller are fixed addresses that can seal components and redirect the creator revenue recipient respectively; no owner can pause trading, upgrade the hook, or change fee rates after deployment in the visible interface. Full impact depends on sealed factory, router and vault code not provided here.

Risk to user funds: The hook holds fee credit and token balances through the pool manager and revenue engine, and the automation path can move accumulated quote revenue into buys or liquidity; LP positions are locked to the initial range and cannot be removed through the hook, so LP funds are effectively locked by design.

Security findings

  • [info] Hook takes fees via return deltas: beforeSwap returns a positive fee delta on buys and afterSwap returns a fee delta on sells, so the hook directly takes a share of every trade on the launch pool up to the configured maximum of 90 percent decay rate.
  • [medium] Privileged fee controller can redirect creator fees: setCreatorRecipient, callable only by the immutable feeController, can change the recipient of the creator revenue share for any non-protocol-only pool at any time.
  • [medium] Automation buys and LP adds use pool funds: processAtomic spends accumulated quote revenue to buy the token and burn or add liquidity; it relies on a tick-based TWAP check with a 100-tick deviation guard and a minimum-output bound, so pricing manipulation of a thin pool is constrained but not eliminated.
  • [low] Trust in router and tx.origin candidate: Public swaps without a known router use tx.origin as the candidate actor, which is only used for launch gating and is explicitly re-verified through settlement, but relies on that settlement check being correct.
  • [info] Launch-window limits and plague gating: Max buy, max wallet and anti-snipe per-block limits can block buys for their configured duration, which is intentional restriction rather than a freeze of existing holders.

Contract details

Verified source
Yes (QuirkHookV5)
Compiler
solc 0.8.30+commit.73712a01
Bytecode size
22,549 bytes
Upgradeable proxy
No
Detected patterns
erc20, fee-sharing, launchpad, liquidity-management, moves-currency, return-delta, self-unlock

Pools using QuirkHookV5