Buyback and burn

A fifth of every hour's income buys $MEVHOOD on the open market and sends it to an address nobody holds the key to. One transaction does the whole thing, and the number the site prints for total burned supply is counted from the token's own transfer log rather than from anything we emit.

One swap, no middle stop

The operator calls the router once:

swapExactETHForTokens(BURN_MIN_OUT, BURN_PATH, DEAD, deadline)
  value    = the epoch's burn share
  DEAD     = 0x000000000000000000000000000000000000dEaD
  deadline = now + 600 seconds

The recipient argument is the dead address, not the operator. The bought token is delivered there by the router as part of the swap, so it never lands in the operator's wallet, not for a block, not for a single log line. There is no approval to grant, no intermediate balance to redirect, and no window in which anyone could decide to keep it. In the receipt this shows up as an ordinary ERC-20 Transfer whose to is 0x000…dEaD.

BURN_MIN_OUT is the slippage floor the router enforces itself. deadline is ten minutes, which on a chain producing blocks every tenth of a second is generous to the point of irrelevance and exists only so a stuck transaction cannot execute an hour later at a price nobody intended.

Why the figure is checkable without trusting us

Two separate counts of the same thing exist, and they are built by different parties from different data.

The operator's count goes into the Epoch event as burned, and even that is not the router's word for it. epoch.mjs pulls the receipt's own logs, filters to Transfer events emitted by the token contract whose recipient is the dead address, and sums their values. The function is four lines and it does not accept a return value from anything:

if (e.address.toLowerCase() === token.toLowerCase()
    && e.args.to.toLowerCase() === dead.toLowerCase()) sum += e.args.value;

The site's count ignores that event entirely. TOTAL BURNED on the front page is built from eth_getLogs against the token contract with topics fixed to Transfer and to = 0x000…dEaD, walked backwards from the head in windows of at most 50,000 blocks. It counts every token that has ever reached the dead address, whoever sent it and for whatever reason, and it would keep working if the operator vanished, if the distributor were never deployed, or if every Epoch event were fabricated.

So the two numbers should agree, and if they ever stop agreeing the discrepancy is visible to anyone with an RPC endpoint. That is the whole argument. We are not asking to be believed about the burn; we are pointing at a log that we do not write and cannot edit.

One deliberate asymmetry: an epoch's burned field can read zero while tokens really did reach the dead address, because the operator treats a fill below BURN_MIN_OUT as a skip and reports zero rather than a partial. The independent transfer count picks those tokens up anyway. The event under-reports in that case; it has no path that lets it over-report.

Every condition that skips the burn

A failed burn never blocks an epoch. attemptBurn is written so it cannot throw: every failure returns a skip reason instead of raising, and the publication of the root, which is what makes holders' money claimable, goes ahead regardless. In all of these cases burned is 0 in that hour's event and the un-spent wei is simply still sitting on the reserve, where the next hour's measurement picks it up as part of the baseline rather than as fresh income.

Every skip is logged with its reason to stderr and written into the journal as burnSkipReason, so the reason a given hour burned nothing is recoverable later rather than guessed at.

Where the burn sits in the hour

The burn runs before openEpoch, not after it. That ordering is the one place the shipped code deliberately departs from the earlier plan, which said the burn followed the publication, and the code is what runs.

The reason is honesty about a single field. Epoch.burned has to be the amount actually seen in the transfer logs, never a prediction and never a promise to reconcile later, and openEpoch is the only event the contract emits per epoch. To put a settled number in it, the swap has to be settled first. Nothing about holders' money is at risk from the reordering, because a burn that fails is a skip rather than an exception, so the root still gets published and funded in the same run.

The sequence inside one run, then, is: write the intent record and the proofs file to disk, buy and burn, sweep one expired epoch if there is one, and publish the root. The details of the first and third steps are on the operator page.

What the burn is not

It is not a price floor, and nobody should read it as one. Buying a fixed fraction of a variable income puts a variable amount of buying pressure into a market that does whatever it wants; an hour that earns nothing burns nothing, and hours like that are normal. The supply reduction is real and permanent, the market effect of it is not something anyone here can promise, and this documentation is not going to pretend otherwise.

It also does not touch your tokens. The burn spends ETH from the reserve to buy on the open market, the same way any other buyer would. No holder's balance is reduced by it, no approval exists that could reduce one, and the reason the dead address is used rather than a burn function is that $MEVHOOD is a launchpad token whose supply mechanics are not ours to change.