Burn & delivery
The burn cascade, parked deliveries, the held-forever ledger, and why a swap never bricks.
Everything the pot buys or absorbs must go somewhere — and no destination, however hostile, may ever revert the swap that carried it. This chapter is the full delivery pipeline: the burn cascade, parked deliveries, and the held-forever ledger.
The two framing rules
The network token has no supply to destroy, so initPot and setRecipient reject address(0) when main is native — a native-main pot always names a live recipient.
A live recipient that bounces the transfer (a blocklist, a reverting receive()) parks the main on the hook, booked per pool in parkedDirectOf. Anyone may retry it any time with flushDirect(poolId) — it pays the pot's current recipient. Native main is pushed with a 30,000-gas stipend so a hostile treasury can never brick the carrying swap.
The burn cascade
When the recipient is address(0), a burn runs a cascade — cheapest and most final first:
Step 3 exists for deliberately "weird" tokens — a blocklisted dead address, no burn function. The amount is booked in heldOf and is out of circulation as surely as a 0xdEaD balance: the hook has no withdrawal path of any kind for it. On the first fall-through the asset is flagged unburnable, and every later burn of it settles straight to the held ledger without re-running the probes.
It can look like stranding; it is the opposite. The alternative — any retrieval path, however gated — would be a burn someone can reverse, and a reversible burn is not a burn. Custody with provably no exit is the strongest destruction available for a token that refuses both of its own exits. Step 1's native burn is also verified, not trusted: it is accepted only on a measured balance drop, so a token faking its burn function falls through the cascade instead of pretending.
The delivery modes, named
| mode | meaning |
|---|---|
DIRECT | sent straight to the pot's live recipient |
BURNED | burned through the token's own burn(amount) |
DEAD | transferred to 0xdEaD |
HELD | neither burnable nor dead-sendable: held on the hook forever, out of circulation by custody |
PARKED | a refused live-recipient delivery — retryable by anyone via flushDirect |
COMPOUNDED | credited to the LP program's carry by the buyback split — becomes pool liquidity on the next harvest (see Buy back management) |
Every delivery emits Delivered(poolId, to, amount, mode), so an indexer can account for every unit of main the machine ever moved.
Full attribution — the solvency view
FAQ
What is the burn cascade, in one line?+
Try the token's own burn(), else send to 0xdEaD, else hold the tokens on the hook forever — whichever step succeeds first, the supply is out of circulation.
What does "parked" mean?+
A delivery the recipient refused (reverting receiver, blocklist, gas-hungry fallback). The value is booked instead of lost, and anyone can retry it later with flushDirect — the swap that carried it already landed.
What is the held-forever ledger?+
heldOf(asset) counts tokens that could be neither burned nor sent to 0xdEaD, held on the hook with no withdrawal path, across all pools. Custody with no exit IS the burn — the view makes it auditable.
Why bounded-gas pushes?+
A hostile recipient could otherwise burn the whole swap's gas. Deliveries get a fixed gas stipend; if that's not enough, the value books to the ledger and the trade completes.
Can a weird token brick the machine?+
No — every external token interaction is wrapped in try/catch with a fallback, and the never-stop test matrix (hostile receivers, unburnable tokens, re-entrant recipients) proves a swap always lands.