Why this hook exists
Manual buybacks, oracle bots, and the two gaps this machine closes without trust.
Everyone wants buybacks and self-growing liquidity. Almost nobody can automate them — because every known design ends in a price oracle, a keeper bot, or someone on the team pressing buttons. This chapter is the argument for doing it inside the trades instead.
The two ways buybacks are done today
| approach | how it works | what you trust |
|---|---|---|
| manual | a multisig watches the price and clicks | the team's judgment, honesty and availability — forever |
| oracle-fed | a keeper bot reads a price feed and fires a transaction | the oracle, the keeper, AND the gap between them (a lagging feed is an arbitrage faucet) |
| GlueHook | the pot executes inside other people's swaps, priced by the pool's own arithmetic at the moment of execution | the code — verified, immutable, at one address everywhere |
The trade-off is stated plainly: the mechanism narrows who decides when — nobody decides, the market does — which removes discretionary control, and in exchange it automates the buyback on the users' own financial incentives. Buyers trigger pumps because buying is what they came to do; sellers trigger the shield because selling is what they came to do.
The second gap: fees that never compound
In Uniswap V2, fees accrued inside the reserves and every LP position grew automatically. V3 and V4 park fees outside the position, so in practice they are collected by keeper services, position managers… or never. The hook's LP program gives a pool native auto-compounding: a configurable share of every harvest is re-minted into the position inside the swaps that generated the fees — same no-keeper, no-oracle, traffic-powered trigger as the buyback itself.
The hook has no owner, is not upgradable and takes no protocol fee. Nothing you build on it can be rugged from above: no parameter anyone can flip on you, no fee switch, no proxy admin. The code you see is the code that runs, on every network, forever.
Why a V4 hook and not a wrapper or a router
Only a hook executes inside the swap: the shield needs to intercept the sell before the pool prices it (beforeSwap), and the pump needs to ride the buy that unlocked it (afterSwap). A router can be bypassed; a wrapper fragments liquidity. The hook is part of the pool's identity — every venue, aggregator and bot that routes through the pool feeds the machine, whether it knows it or not.
FAQ
Why not just run a buyback bot?+
A bot needs a funded EOA, a price feed, gas management and someone you trust to keep running it — and everyone can see its transactions coming. The hook's buyback executes inside the buy that funds it, at the pool's own price, with nothing to operate.
Why is an oracle a problem for buybacks?+
An oracle is an extra trust assumption and an extra attack surface: manipulate the feed, and the buyback buys at the wrong moment. The hook never asks what the price is — it trades against the pool's own curve, which IS the price.
Couldn't the team just market-buy manually?+
They can — that's exactly the opaque, trust-me pattern this replaces. Manual buybacks are unverifiable promises; the hook turns them into code anyone can read and quotes anyone can call.
What are the two gaps the intro talks about?+
First: no credible, automatic way to spend treasury on defending a price without trusting someone. Second: V3/V4 concentrated positions never auto-compounded their own fees. The pot closes the first, the LP program closes the second.
Does this replace a token locker or vesting product?+
No — the hook is deliberately not a locker. Surrendering the owner role locks liquidity forever, but time-locks, vesting and escrow are meant to be built ON TOP by composing with the roles.