1. 1Supply cannot increase. The token declares no mint function of any kind, and totalSupply() at launch equals LAUNCH_SUPPLY. Falsified by any transaction that raises totalSupply() above 21,000,000 · 10¹⁸.
2. 2The rates cannot be changed. β_in and β_out are constant, compiled into the hook’s runtime bytecode rather than stored in a writable slot. There is no setter, no proxy, and no governance. Falsified by any transaction after which BUY_BURN_BPS() or SELL_BURN_BPS() returns anything other than 100 and 500.
3. 3No one is in charge. Neither contract implements owner(), so the call reverts, and a revert is stronger evidence than a renouncement because renouncement requires trusting that ownership was the only lever. The hook binding is single-shot: setHook reverts on any second call, so even the deployer cannot re-point the token at a hook they control. Falsified by any successful call to owner() on either address.

One more property worth naming, because it is enforced on-chain and most projects only assert it in a document: there is exactly one pool. The hook records the first PoolKey it is initialized with and rejects every subsequent one with NotCanonicalPool. Nobody, including the deployer, can stand up a second Ponzi pool that shares this hook and quietly routes around the burn.

Ponzi trades through the standard Uniswap interface and the standard UniversalRouter. It needs no custom frontend and no special routing. There are three things an integrator should know.

1. 1Slippage is measured post-burn. The hook takes its cut out of the swap output via the return delta, so the amount that reaches the trader is already net of 1% or 5%. Set amountOutMinimum against the post-burn amount, not the raw quote, or the swap will revert on slippage every time.
2. 2Exact-input only. The burn model is defined over exact-input swaps. Exact-output swaps revert with ExactOutputUnsupported rather than settling at a rate the model does not describe.
3. 3The PoolKey is load-bearing. Routing requires the exact struct: native ETH as currency0, Ponzi as currency1, fee 0, tickSpacing 60, and the hook address. Any other combination is a different PoolId and a pool that does not exist.

The LP fee on the canonical pool is zero. This is deliberate: the burn is the only charge the design intends, and stacking a conventional LP fee on top would push total trader cost above the advertised figures. What a liquidity provider earns here is not fee income but exposure to a supply curve that only contracts.

The guarantees above are narrow and they are about supply. They are not guarantees about price, and a document that blurred the two would not be worth reading. Some things this design does not protect against:

1. 1Supply mechanics do not set price. A monotone non-increasing supply is compatible with a price that falls indefinitely. Burning removes tokens; it does not create demand for the ones that remain.
2. 2The contracts are unaudited. They are tested end-to-end against live mainnet state, which catches integration failures, but testing is not auditing and neither is a fork test. The hook re-enters its own pool by design, and re-entrancy is exactly the class of thing that rewards a second and third set of expert eyes.
3. 3Immutability cuts both ways. No owner means nobody can rug the parameters. It also means nobody can pause, patch, or compensate if a bug is found after launch. There is no recourse, by construction.
4. 4Low liquidity amplifies the buyback. The sell-side buyback executes at whatever price the pool shows at that instant, with no price limit. In a thin book it will buy at a worse price and burn fewer tokens than the headline ratio implies. The ETH still leaves the seller, but it buys less.

Read the source before transacting. The mechanism described here is only as true as the bytecode deployed at the addresses in the footer, and that is something you can verify yourself rather than take on trust, which is, in the end, the entire point.