The burn share
Main-side fees destroyed at the source: the cascade, the native-main rule, burn vs buyback.
The burnShare destroys a slice of the main-side fees at the source — the tokens the pool just earned are removed from supply before they ever circulate again. It is the machine's second deflation engine, and it works completely differently from the first.
Why burn lives on the main side only
Burning is for the asset you are defending. Main-side fees arrive already denominated in the token whose supply you want to cut — destroying them needs no trade, no price, no counterparty. The secondary side has no equivalent lever on purpose: burning the buyback currency would destroy the wrong asset, so the secondary side's special destination is the pot instead, where those fees buy main at market before the pot's own burn-or-deliver decision applies.
A native main (the network token) has no supply to destroy, so the validation forces burnShare = 0 when main is native — rejected when the config is written, never discovered as a silent no-op at harvest time. A native-main pool expresses deflation intent through the pot's buyback + a live recipient instead.
Burn vs buyback — two engines, one goal
| burnShare (fees) | buyback (the pot) | |
|---|---|---|
| input | main-side LP fees, already in main | pot secondary — donations + the buybackShare |
| market touch | none — no trade, no impact, no MEV surface at all | buys through the pool at market price, fee-bounded per buy |
| effect shape | pure supply cut, volume-indexed (fees scale with trading) | supply cut AND direct bid pressure riding every buy |
| timing | at every harvest | at every buy, paced by the spending curve |
They compose: a config with both a burnShare and a buybackShare (into a burn-recipient pot) attacks supply from two directions — fees burned directly, plus market buys whose output is burned. The volume-indexed nature is the elegant part: burned amount = burnShareWad · mainFees, and main fees are proportional to trading volume — so the token deflates exactly as fast as it is used, with zero discretion anywhere.
How the destruction actually happens
The burn leg goes through the same verified cascade as the pot's burns — cheapest and most final first, with each probe verified, never trusted:
A token that fakes its burn function falls through on the measured check; a token that blocklists 0xdEaD falls through to the held-forever ledger; and after the first fall-through the asset is flagged so later burns settle straight to the ledger without re-probing. Every outcome is out of circulation; every outcome emits its mode. The full pipeline — including why the terminal hold is stronger than any retrievable alternative — is in Burn & delivery.
Reading the burn
Summing the burned field across Harvested events gives a token's exact cumulative fee-burn — a supply-reduction figure a community can verify without trusting a single reported number.
FAQ
Why burn at the source instead of buy-and-burn?+
Main-side fees are already the defended asset — burning them directly removes supply with zero price impact and zero MEV surface. Buy-and-burn is what the pot's buyback share is for, on the other side.
What exactly happens when the burn share fires?+
The slice goes through the cascade: token burn() first, 0xdEaD second, held-forever custody last. Whichever step lands, the tokens are out of circulation.
Why is a burn share illegal on a native main?+
There's no honest way to destroy native coin from a contract — no burn(), and 0xdEaD custody of ETH is just parking. The config rejects it instead of faking it.
Is the burn visible on-chain?+
Every burn emits the delivery event with its mode, and unburnable amounts appear in heldOf(asset). Supply trackers can reconstruct the full burn history from logs alone.
Burn share vs buyback share — which defends the price more?+
The burn share shrinks supply silently; the buyback share adds buy pressure and refuels the defense. Most programs run both: burn on the main side, buyback on the secondary side.