Uniswap v4 replaced the one-pool-per-contract model with a single singleton PoolManager and a callback interface called a hook. A hook is a contract that the PoolManager invokes at defined points in a pool’s lifecycle: before and after initialization, liquidity changes, donations, and swaps. Within those callbacks the hook can inspect the swap, and, if it holds the right permissions, alter its settlement.

The permission system is the part worth understanding, because it is what makes a hook auditable. A hook does not declare its permissions in storage where they could be changed. It declares them in its own address. The low fourteen bits of the deployed address are a bitmap of which callbacks the PoolManager will invoke, and the PoolManager validates that bitmap on every pool initialization. To deploy a hook with a given permission set you must mine a CREATE2 salt that produces an address whose low bits equal that set.

The fourth permission, afterSwapReturnDelta, is the one that makes Ponzinomics possible at all. It lets a hook return a signed claim against the swap’s output currency: the PoolManager computes what the trader would have received, the hook says “I am taking this much of it”, and the books balance. This is a first-class settlement primitive rather than a side-effect. There is no window during which the trader holds the tokens and no transfer that another contract could observe as a transfer. The burn is part of the swap, in the same sense that the LP fee is part of the swap.

Call a burn event any swap the PoolManager dispatches against the canonical (ETH, Ponzi) pool. Let w be the gross output that swap produces, and β the burn ratio for its side. The quantity burned is:

The two sides differ in more than magnitude. They differ in what actually happens to the value.

1. 1Inbound.The output currency is already Ponzi. The hook withholds r from the buyer’s proceeds via its return delta, draws exactly that amount out of the PoolManager, and burns it. The buyer receives 99% of the raw quote. One burn, no market interaction, no price impact beyond the swap itself.
2. 2Outbound.The output currency is ETH, and Ponzi cannot be burned with ETH. So the hook claims 5% of the seller’s ETH proceeds and, still inside the same unlock, before the transaction has settled, spends it on a second swap against the same pool, buying Ponzi on the open book. Every token that purchase returns is burned. The seller keeps 95% of their ETH. The other 5% became a market bid and then became nothing.

That second path is the design. A conventional buyback-and-burn accumulates fees in a treasury, and then a keeper, a bot, or a governance vote decides when and whether to spend them. Each of those is a party who can fail to act, act late, act in their own interest, or be compelled not to act. Ponzinomics has no treasury because the buyback happens in the same transaction as the sell that funded it, atomically, with no intermediate state in which anyone holds anything. There is nothing to steward and therefore no steward.

The outbound path deliberately re-enters the pool it is currently inside. That is an unusual thing to do on purpose, so it is worth walking through exactly what the PoolManager sees.

1. 1A trader submits an exact-input sell to the UniversalRouter, which dispatches it to the PoolManager and takes the lock.
2. 2beforeSwap fires. The hook classifies the side as outbound and parks that classification in transient storage. EIP-1153, so it costs ~100 gas instead of ~5,000 and clears itself when the transaction ends.
3. 3The swap executes. The trader is now owed ETH; the PoolManager records the delta but has settled nothing.
4. 4afterSwap fires. The hook computes the 5% cut, raises a buyback flag in transient storage, and calls poolManager.swap again, this time buying Ponzi with exactly that much ETH.
5. 5The nested swap re-enters beforeSwap. The hook sees its own buyback flag raised and returns immediately without charging anything. Without that guard, every sell would burn a burn, compounding instead of charging the flat 5%.
6. 6The hook takes the Ponzi the buyback purchase produced and calls burn, the token’s only supply-reducing function, which accepts calls from precisely one address in the world.
7. 7afterSwap returns its delta. The ETH nets flat: the +5% credited by the outer swap is cancelled exactly by the −5% the buyback consumed. The only thing that ever leaves the PoolManager is Ponzi, and it leaves directly into a burn.

Because it is one atomic transaction, there is no block in which the hook holds ETH, no block in which it holds Ponzi, and no block in which a MEV searcher could position against a pending buyback. There is no pending buyback. The buyback is not scheduled, announced, or queued. By the time it is observable it has already happened, and the tokens are already gone.

Write S(t) for circulating supply at time t and R(t) = S(0) − S(t) for everything burned to date. For burn event i of gross size w:

Both terms on the right are non-negative, so the sequence never increases. R(t)/S(0) reads directly as the fraction of the launch supply permanently burned. There is no emission schedule to model, no unlock cliff to price in, and no vesting contract holding tokens that will arrive later. The entire supply exists at block zero and only ever shrinks from there.

How fast it shrinks depends entirely on turnover, which is the one variable the protocol does not control.