Buyback and burn
The design: the treasury takes a share of every harvest in stock, sells it, buys $MESS and destroys what it buys. The contract for that is written and tested, and both of its entry points are permissionless — a buyback only an operator can trigger is a buyback the operator can decline to trigger.
Not switched on
Nothing has been burned, because nothing is being taken.
$MESS exists now and it can be burned — burn(uint256) is in its dispatcher, checked on chain, which is the one thing this design depends on. Two things still are not true. The vaults take no treasury share at all, and switching that on means deploying a new factory, because nothing here has a setter. And the buyback needs a MESS/WETH pool: there is none at any fee tier, because $MESS still trades on its Pons bonding curve. Both are named here rather than left for you to discover.
Treasury share
0.00%
of every harvest, capped at 10%
$MESS burned
none yet
supply at launch minus supply now
Supply
1,000,000,000
read from 0x5c5492…, not from a config file
Treasury address
none set
read from the factory
read from chain 4663 at block 60227565 in 1690ms
What the burn will and will not be
- burn() reduces totalSupplyA transfer to the zero address is refused, because it would look like a burn on an explorer while the supply figure stayed put.
- No mint existsNot renounced - the function is absent, so there is no authority to check.
- No burnFromA token that can be destroyed out of somebody else's balance by an approved spender has a confiscation path.
- The treasury cannot be emptiedNo owner, no withdraw, no sweep. The only route value can take out is the burn.
- Turning the share on means a NEW factoryNothing about a vault can be changed after people have bought its coin. That is what immutability costs.