VaultHook on Robinhood Chain

Volume (24h)

$0

Value locked (TVL)

$0

All-time volume

$0

Pools using this hook

1

Swaps (24h)

442 (177 traders)

Total swaps

442

What it does

VAULT/USDG trades pay a 5% USDG tax on both buys and sells, with launch-window buys and sells charged a decaying 97% tax, and sells also pay a parity VAULT burn of up to 25%; the tax is split 20% to ops and 80% to the reserve.

How it works step by step

• Gates pool creation and liquidity: only the hook can initialize the VAULT/USDG pool (inside seed()) and add liquidity; all external initializes and adds revert.
• Blocks swaps until the controller's launch time, then charges a tax in USDG: a decaying launch curve (97% down to 5%) over the first 120 seconds, then a steady 5%.
• Splits each tax into an ops bucket (20% of the tax) and a reserve bucket (80%), flushing to the ops wallet and to the Reserve (notifyCash) automatically above $50 or via the public flushTax().
• Burns a parity amount of VAULT on sells (controller.sellBurnBps(), clamped to 25%) via take-and-burn during the swap.
• Maintains a 2048-entry tick-cumulative oracle updated after every swap, exposing TWAP and spot price views, plus a volume counter and a per-epoch pool-VAULT minimum.
• Holds protocol-owned full-range liquidity seeded once by the deployer or launcher; lpOwner may extend the lock, burn it permanently, or withdraw liquidity only after lockUntil, with VAULT principal burned rather than transferred.

Swap behaviour

Before launch, swaps revert. After launch, every buy and sell pays a tax in USDG: during the first 120 seconds the rate decays from 97% to 5%, after which it stays at 5%. For buys with exact-in, 5% of the USDG input is taken before the swap; for buys with exact-out, the USDG input is grossed up so the tax equals the tax rate of what the buyer pays, taken after the swap. For sells with exact-out, the output is grossed up before the swap so the seller receives exactly the requested USDG; for sells with exact-in, the tax is taken from the USDG output after the swap. Sells also pay a VAULT parity burn of up to 25% of the VAULT input, which is burned. Partial fills are rejected, and the hook may run an epoch tick on the controller inside the swap. Sells therefore pay more (tax plus burn) than buys, and early trades in the launch window pay the most.

Liquidity behaviour

External liquidity additions revert; only the seed() path adds the initial full-range position owned by the hook. Liquidity removal is restricted to the lpOwner through withdrawLiquidity after lockUntil (default 2027-01-01) and only if the lock has not been burned. Fee collection (collectLpFees) is open to anyone and routes USDG fees to ops and VAULT fees to burn.

Fee behaviour

The pool's LP fee is static at 0, so the entire trade cost is the hook tax (launch curve, then 5%). Of each tax, 20% goes to the ops bucket and 80% to the reserve bucket (the launch-window split uses a configurable launchOpsBps share to ops). Buckets are flushed to the ops wallet and the Reserve, with failed legs deferred and retried rather than reverting swaps.

Owner & admin controls

No owner, pause, upgrade or fee-setting functions exist. The lpOwner can only extend the lock (to a later time), permanently burn the lock, or withdraw the protocol liquidity after lockUntil while the lock is not burned. wire() and seed() are one-shot and restricted to the deployer (and the optional launcher for seed). The controller and reserve addresses are set once and cannot be changed.

Enabled Uniswap v4 callbacks

beforeInitialize, beforeAddLiquidity, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta

beforeInitialize: reverts every external initialize, so the pool can only be opened by the hook's own seed(). beforeAddLiquidity: reverts every external liquidity add. beforeSwap: enforces the trading gate, runs the epoch tick, takes the USDG tax on buys (exact-in) and sells (exact-out) and the VAULT parity burn on sells (exact-in), and records the pre-swap decisions. afterSwap: takes the remaining tax, updates the oracle, volume counter and pool-VAULT minimum, and checks for partial fills. beforeSwapReturnDelta: lets the hook take USDG or VAULT from the swap as a specified-amount delta. afterSwapReturnDelta: lets the hook take the unspecified-side tax and burn after the swap.

Security & trust assessment

Risk level: medium (verified source, high confidence).

Who controls it: No single key can change fees, pause trading or upgrade the hook. The lpOwner can extend or burn the lock and, after the lock expires, withdraw the protocol-owned USDG liquidity to any address; the deployer controls only the one-shot wiring and seeding.

Risk to user funds: The hook holds protocol liquidity and transiently holds tax and burn amounts; it can take USDG and VAULT from every swap (tax plus sell burn), and can move USDG to the ops wallet and Reserve. It cannot take user funds beyond the stated tax and burn, and the VAULT removed from liquidity is burned rather than paid out.

Security findings

• [info] Taxes and burns charged through return deltas: beforeSwapReturnDelta and afterSwapReturnDelta let the hook take USDG and VAULT from every swap, so the hook can always skim up to the tax plus up to 25% sell burn; the tax is hard-coded (5%, launch curve up to 97%) rather than admin-adjustable, which is a deliberate and visible fee.
• [medium] Swaps depend on an external controller: Launch time, sell burn bps and the epoch tick come from an external controller contract whose behaviour the hook trusts; the tick is wrapped in try/catch with a capped gas stipend, but the launch gate and sell burn rate are read directly from it, so a faulty or malicious controller could block swaps or change burn amounts.
• [medium] Protocol liquidity can be withdrawn by lpOwner after lock: After lockUntil (2027-01-01 by default) and if not burned, the lpOwner can withdraw all protocol liquidity to an address of its choosing; USDG principal goes to that address, so the pool's depth can be removed, though the lock can be extended or burned permanently.
• [low] Flush and reserve transfers can fail silently inside swaps: Soft flushes inside swaps tolerate failing transfers to ops or the Reserve by restoring buckets and backing off for an hour; a frozen ops or reserve address therefore delays flushes rather than reverting swaps, which keeps trading live but leaves funds stuck in the hook until a later successful flush.
• [info] Partial fills revert the trade: afterSwap reverts with PartialFillNotSupported when the pool does not fill the full specified amount, so price-limited trades fail instead of settling partially, which protects tax accounting but can cause failed transactions.

Contract details

Verified source

Yes (VaultHook)

Compiler

solc 0.8.26+commit.8a97fa7a

Bytecode size

22,940 bytes

Upgradeable proxy

No

Detected patterns

erc20, launchpad, liquidity-management, moves-currency, oracle, return-delta, self-unlock, tax

Pools using VaultHook