What Are Uniswap v4 Hooks? A Complete Guide to Mechanics, Permissions, and Marketplaces

A Uniswap v4 hook is a smart contract that plugs into a Uniswap liquidity pool and runs custom code at specific points in that pool's life, before or after a swap, a liquidity change, or a donation. Hooks let a v4 pool behave like a purpose-built financial product instead of a generic AMM. This guide covers the mechanics, the permission system, what has gone wrong, and what you actually get from a hook marketplace on Robinhood Chain.

I'm Rick Bakas. I run Bakas Media and hold a live LP position on Robinhood Chain. I have no affiliation with Robinhood, Uniswap, or any project named below. Nothing in this article is financial advice or a signal to buy any token.

What is a Uniswap v4 hook?

A hook is a smart contract that Uniswap v4's pool manager calls at defined moments in a pool's life. There are 10 callback functions arranged in 5 pairs: beforeInitialize/afterInitialize, beforeAddLiquidity/afterAddLiquidity, beforeRemoveLiquidity/afterRemoveLiquidity, beforeSwap/afterSwap, and beforeDonate/afterDonate. A hook developer implements only the callbacks they need. Everything else falls through to Uniswap's default behavior.

Before v4, adding custom logic to a pool meant forking the entire Uniswap contract, one deployment per pool. v4 replaced that with a single shared PoolManager contract that holds every pool's liquidity, plus flash accounting that nets token balances across an entire transaction using EIP-1153 transient storage. Creating a pool now costs roughly 99% less gas than it did on v3, and that cost drop is the reason custom, per-pool logic became normal instead of a luxury reserved for large protocols.

How do hook permissions work in Uniswap v4?

A hook's permissions are encoded directly into its deployed contract address, not stored in a registry or a config file. Each of the 10 callbacks (plus four related flags, described below) maps to a specific bit in the low bits of the address. A developer runs a tool called a HookMiner that brute-forces a CREATE2 salt until it produces an address with exactly the right bits set, then deploys the contract to that address.

PoolManager never checks a permissions table. It reads the hook's own address and calls only the callbacks whose bits are flipped on. There is no way to claim a permission a developer didn't mine into the address ahead of time, and no way to add one later without a new deployment. The hook address gets locked into the pool's identity at creation, as part of the PoolKey that derives the pool's ID. A live pool can never swap out its hook for a different one. The only way to change hooks is to abandon the pool and launch a new one.

This is the single most elegant piece of v4's design, and also the reason a hook's address is worth reading before trusting anything else about it.

What can a malicious hook actually do?

Most of the 10 callbacks can only observe a transaction or block it entirely (revert it). Four of them are different. They're called "return-delta" flags: beforeSwapReturnsDelta, afterSwapReturnsDelta, afterAddLiquidityReturnsDelta, and afterRemoveLiquidityReturnsDelta. A hook carrying any of these flags can rewrite the actual BalanceDelta, meaning the real quantity of tokens that moves in a swap or a liquidity change, not merely observe it.

A hook without return-delta flags has one failure mode: it can deny a transaction. A hook with return-delta flags can silently take a cut of a trade or short a liquidity provider's position without their knowledge, because it controls the number that actually settles.

Uniswap runs its own allowlist review, and it treats these two classes differently. A hook with no return-delta flags is auto-approved. Anything with return-delta flags goes into manual review. Upgradeable hooks are not approved at all, under any circumstances.

Is Uniswap's hook allowlist an audit?

No. Uniswap's allowlist checks the scope of what a hook's address permits it to do, not the correctness of the code inside it. A hook that has no return-delta flags gets auto-allowlisted because it structurally cannot rewrite balances, regardless of whether its internal logic has bugs. "Auto-allowlisted" is a claim about permission scope. It is not a claim that the contract is safe, bug-free, or has been reviewed by a security firm. Treating allowlist status as an audit result is a category error that shows up repeatedly in hook marketing copy.

What is the proxy-upgrade gap in hook security?

Address immutability, the promise that a live pool's hook can never be swapped, only holds for hooks deployed as ordinary, non-upgradeable contracts. If a hook is deployed behind an upgradeable proxy, the contract address stays fixed forever, but whoever controls the proxy's upgrade key can change what code runs behind that address at any time. The pool's identity looks unchanged. Its actual behavior isn't.

This is the detail worth checking before trusting any hook "blueprint" from a marketplace: is the contract upgradeable, and if so, who holds the key. Uniswap's own allowlist refuses upgradeable hooks outright, which tells you how seriously the core team treats this gap.

Have hooks actually lost people money?

Yes, in two documented 2025 incidents. In both cases, the hook primitive worked exactly as designed; the bugs were in the logic someone wrote inside it.

• Cork Protocol lost $11 million in May 2025 to a missing access-control modifier on a hook callback, a straightforward permissions bug in the code someone wrote inside the hook.
• Bunni lost $8.4 million on September 2, 2025, to a rounding error in the hook's own idle-balance accounting. The attacker exploited it through a flash loan combined with 44 small withdrawals, despite the protocol having passed prior audits from both Trail of Bits and Cyfrin. Bunni was the largest LP-focused hook deployed at the time. It shut down after the exploit.

Both cases prove the same point: the return-delta and callback mechanism worked exactly as designed. The vulnerabilities were ordinary smart-contract bugs, access control in one case, arithmetic in the other, sitting inside logic that a hook's structural permissions did nothing to catch. Passing an audit did not save Bunni. A hook marketplace's self-reported "audited" label deserves the same skepticism.

Which hook marketplaces are live on Robinhood Chain?

Four marketplaces for adopting pre-built hooks exist on Robinhood Chain as of this writing (all checked 2026-08-26). Their actual state varies widely from their marketing.

Marketplace	What it actually is
Hookr (@Hookrfun)	The most substantive of the four. Five stackable modules (no Solidity required) plus a royalty marketplace: a designer publishes a blueprint and earns a royalty every time someone launches a pool with it. None of the other three replicate the royalty layer.
HookPad (hookpad.org)	Not a multi-hook marketplace despite the name. One shared fixed-tax hook (configurable 1-10%) wrapped in a launchpad UI. $823 in lifetime protocol revenue.
HookStreet (tradehook.fun)	A pre-deployment registry rather than a functioning marketplace. Seven documented hook "packs," every one tagged "AUDIT PENDING" on the site's own copy, and an active-markets counter that shows no number at all.
HoodPad (hoodpad.fun)	Domain does not resolve, confirmed on two separate checks. Do not treat as live without re-verifying.

What do you get when you buy a hook from a marketplace?

This is the part most coverage of hook marketplaces skips over.

• Never a bespoke contract. You select a pre-built template, sometimes called a "blueprint" or a "pack," and configure a handful of parameters at launch. On HookPad, it's literally the same shared on-chain contract instance reused across every pool that adopts it.
• The binding is permanent. The hook attaches to your pool at creation and stays there for the pool's entire life. Changing your mind means abandoning the pool and launching a new one.
• "Audited" rarely means what it implies. Across these four marketplaces today, audit status means provisional, incomplete, or absent, by each platform's own disclosures. HookStreet says so directly on its own site. Hookr discloses AI-assisted tooling review, not a named human audit firm.
• The allowlist is not a safety verdict. See the section above. A hook being auto-allowlisted tells you it can't rewrite balances. It tells you nothing about whether the logic inside has a Cork-style access-control hole or a Bunni-style rounding bug.
• What you're actually trusting: the template author's Solidity correctness, the platform's self-reported audit claims, and, for upgradeable hooks, the author's ongoing honesty with the upgrade key.
• The real cost stack: gas to mine and deploy the correctly-flagged address, the marketplace's own fee (Hookr routes a royalty to the blueprint's original designer on every launch), and whatever ongoing swap-fee cut the hook is configured to skim from every trade against that pool, for as long as the pool exists.

What does real hook engineering look like, versus recycled plumbing?

Two examples worth citing as the upper and lower bounds of what's happening on Robinhood Chain today.

Fables uses a hook for calendar-aware dynamic fees on tokenized equities, where the hook functions as both the fee schedule and the liquidity ledger. It holds no return-delta permissions by design, which is exactly what qualifies it for Uniswap's automatic allowlist. That's real financial engineering built on the primitive.

Hookr's five modules show published gas costs per feature: Anti-Snipe (~160K gas), Surge Fees (~120K), Auto Burn (~140K), LP Rewards (~150K), and Nth-buy Pot (~180K gas; the winner is chosen by a deterministic formula, not randomness). These are composable building blocks, not one-off engineering, but they're at least purpose-built instead of recycled launch plumbing.

Have hooks actually been used for anything beyond meme-coin launches?

Mostly not yet, and this is the gap worth naming plainly. An independent on-chain analysis (source: robinhood-chain.netlify.app; the author is unidentified, so treat this as directional rather than authoritative, and note the data window runs from Robinhood Chain's mainnet launch on 2026-07-01 through 2026-07-13, making it well over a month stale at the time of publication) scanned every PoolManager initialization event on the chain during that window. Of 7,415 hook-enabled pools created, 88.7% routed through just two third-party meme-launch factories, Doppler and Clanker. Genuinely novel, one-off hook contracts numbered roughly 15 to 20 across those 12 days. 97.6% of tokens that passed through a hook-enabled pool had zero market data anywhere.

Hooks are the feature that makes Robinhood Chain's DeFi structurally different from any other low-fee L2. Right now, most of that capability is being spent recycling meme-launch infrastructure. The calendar-aware fee schedules, royalty economies, and leverage-on-a-standard-LP products the primitive was actually built to enable are still the exception, not the rule.

Frequently Asked Questions

Q: Can a hook see or change my trade before it executes?
A hook with beforeSwap permission runs before your swap settles and can revert it entirely. Only a hook that also carries the beforeSwapReturnsDelta flag can change the actual token amounts involved, not just approve or block the trade.

Q: Can I remove or replace a hook on a pool I already created?
No. The hook address is locked into the pool's identity (its PoolKey) at the moment of creation. There is no function to detach or swap a hook on a live pool. The only path is creating an entirely new pool with a different hook address.

Q: Does an "audit pending" label mean a hook is unsafe?
It means the platform itself has not completed or does not claim a completed third-party security review. It doesn't prove the code is unsafe, but it does mean nobody outside the development team has verified it. Cork and Bunni show that even completed audits (Bunni had two) don't guarantee a hook is free of exploitable bugs.

Q: What's the difference between Uniswap's hook allowlist and a security audit?
The allowlist is an automated scope check: it looks at which permission bits are set in a hook's address and approves anything without return-delta flags automatically, since those hooks structurally cannot rewrite trade balances. A security audit is a human or firm reviewing the actual code logic for bugs. A hook can pass the allowlist and still contain the kind of logic bug that caused the Cork and Bunni losses.

Q: Is a hook the same thing as a fork of Uniswap?
No, and that's the point of v4. Before v4, custom pool logic required forking the entire AMM contract, one deployment per pool. A hook is a separate, smaller contract that plugs into a single shared PoolManager at specific lifecycle points, so custom behavior no longer requires forking anything.

Q: Are Robinhood Chain's hook marketplaces audited by Robinhood?
No. Robinhood Chain is the settlement layer; it does not audit or endorse individual hook marketplaces or their contracts. Audit claims on any marketplace (Hookr, HookPad, HookStreet, HoodPad) are self-reported by that platform, not verified by Robinhood or by Uniswap's core team beyond the automated allowlist scope check described above.

Sources

• Uniswap v4 core documentation, for callback structure, PoolManager, and flash accounting.
• Uniswap v4 hook allowlist criteria, for return-delta permission classes and manual-review policy.
• robinhood-chain.netlify.app, an independent on-chain pool-creation analysis covering mainnet launch (2026-07-01) through 2026-07-13. Author unidentified; cited here as directional and explicitly stale.
• Cork Protocol post-mortem coverage (Dedaub, Hacken), May 2025, $11M loss from a missing access-control modifier.
• Bunni post-mortem coverage (Trail of Bits, Cyfrin, DARKNAVY writeups), September 2, 2025, $8.4M loss from an idle-balance rounding bug.
• Hookr, HookPad, HookStreet, and HoodPad (hoodpad.fun, domain does not resolve), all checked directly on 2026-08-26.

---

About the Author

Rick Bakas is the founder of Bakas Media, an independent operator covering RWA tokenization and the Robinhood Chain ecosystem. He holds a live LP position on Robinhood Chain and writes from direct on-chain testing rather than secondhand summary. He has no affiliation with Robinhood, Uniswap, or any protocol named in this article, and nothing here is financial advice or a recommendation to buy or sell any asset. Questions or corrections: contact via bakas.media.