What can go wrong
Zero hours, a claim you forgot, a swap that reverted, an RPC that will not answer, and a protocol with one operator behind it.
This is the page that exists so the rest of the documentation can be trusted. Everything below is a real failure mode of the system as built, not a legal disclaimer, and most of it will happen to somebody eventually. A few of these are already true today.
The hour can be worth nothing
An hour where the reserve did not grow closes as a zero epoch: empty root, nothing funded, nothing burned, a row on the board like any other. There is no floor under it. The bot can have a flat hour, a losing hour, or an hour where it did not trade at all, and the protocol's response to all three is the same subtraction producing zero or less.
No mechanism anywhere in the contract or the operator smooths that out. There is no reserve draw to top a bad hour up, no rolling average, no accrual. What a holder gets is a pro-rata share of whatever actually landed in a wallet during one specific hour, and on plenty of hours that will be nothing at all. $MEVHOOD is not a share of the bot, not a claim on the reserve, and not an obligation on anybody.
The claim window really does close
Seven days from the publication timestamp, enforced by the contract against block.timestamp, after which claim reverts with WindowClosed and the operator may sweep the remainder back to the reserve. Nobody can extend it for you. There is no appeal, no manual payout, and no code path that lets the operator pay a late claimant even if they wanted to; the money is back in the reserve and has been re-measured as part of the next hour's baseline.
The practical shape of this risk is worse than the rule suggests. Claims cost the holder gas, so a small share is rationally left unclaimed, and a holder who decides to batch up a week of small shares and claim them all at once will find the oldest ones expiring first. Each epoch is a separate transaction with a separate proof and a separate seven days. Details on the claim page.
A swap can fail, and the hour still closes
The buyback is the part of the system most likely to silently do nothing. Six different conditions skip it, listed on the burn page, and the most common one right now is that there is no router configured at all because the token has not graduated from the bonding curve. A skipped burn is not an error and does not stop the epoch: the share stays on the reserve, burned is zero in that hour's event, and the next hour counts the un-spent wei as part of its baseline rather than as new income.
So an honest reading of the burn is that it is a rule the operator follows when it can, not a promise that a fifth of every hour is bought back. Whether it fired in a given hour is visible in that hour's burned field and, independently, in the token's own transfers to the dead address.
The network can stop answering
The observer reads balances and transfers from public RPC endpoints, and price estimates from Dexscreener. If a refresh fails, it retains a previously successful reading with an explicit unavailable/stale label and timestamp. If no reading succeeded, values remain unavailable. Missing quotes are not displayed as zero, and a missing core quote suppresses the total.
The primary endpoint, rpc.mainnet.chain.robinhood.com, intermittently answers with a duplicated Access-Control-Allow-Origin: *,* header, which browsers reject outright. A single failed fetch is retried; a JSON-RPC error response is not, because the node answered and the answer was no.
The fallback, rpc.ordofi.network, is not full redundancy and the site refuses to describe it as such. Measured on 2026-09-10: it keeps balances, the premium board and the countdown alive through a primary blink, but it cannot serve the log-heavy loaders. The bot panel's window of 36,000 blocks across seven token addresses comes back -32005 "the network is busy" after 25 to 50 seconds, where the primary answers in under a second, and smaller windows fail at random rather than by size, with 6,000 blocks answering in 7 seconds and 3,000 blocks refused in the same minute. When the fallback is carrying, the bot block and the epoch replay will honestly report that the network did not answer.
For the operator the same outage is cheaper: a run that cannot reach the RPC exits 3, having moved no money, and the next hour's timer tries again.
One key, one operator, and what the contract does not stop
There is a single operator key. It signs openEpoch and sweep, it is the reserve wallet, and the income measurement is the growth of its own balance. A short list of what that key can do:
- Publish a root that under-pays, over-pays, or omits a holder. The contract checks the epoch id, the funding, and that no epoch pays out more than it holds. It does not check that the tree is fair, because it cannot: the tree is built off chain from a snapshot nobody else took.
- Not run at all. A skipped hour is a skipped hour; the epoch id simply advances when the next run lands, and there is no keeper, no incentive for anyone else to call it, and no way for a holder to force publication.
- Move the reserve's ETH anywhere. It is an EOA holding funds, not an escrow.
- Sweep an expired epoch, which is the intended behaviour and also the only way money leaves the distributor other than a claim.
What that key cannot do is take your tokens. The distributor never requests an approval and has no code path that transfers $MEVHOOD; claim and sweep both move ETH in one direction only. It also cannot re-open a published epoch, publish out of order, or fund a root with less than its total, because all three revert.
If the key is compromised, the reserve is gone and epochs stop. The owner can point the contract at a new operator with setOperator, and money already funded into an open epoch stays claimable by its holders, since claim needs no operator involvement whatsoever. That is a small consolation and it is the honest size of it.
There is no proxy, no upgrade path, no pause switch and no admin function that can touch an epoch's funds. The contract is one file with no library beyond an inline IERC20 interface.
Anything sent to the reserve becomes income
Income is a balance delta, and a delta has no memory of where it came from. A top-up, a refund, a test transfer, a stranger sending ETH to the wrong address: all of it is measured as that hour's income, half published to holders and a fifth spent buying the token back, within the hour. The operator cannot ask a delta where it came from and does not pretend to.
This cuts the other way too. Anything that leaves the reserve between epochs reduces the measured income, including the gas the operator itself spends.
The gates that are still open
None of the following is fixed in code, and each is a real precondition for the protocol behaving as this documentation describes.
- The bot's profit is in the wrong asset, on the wrong address. The executor accumulates USDG and WETH;
epoch.mjsmeasures ETH on the reserve wallet. Something has to convert and move it, and neither the contract nor the operator does. Until that is settled, income is structurally zero no matter how well the bot trades. - The creator address on PONS must be the reserve wallet. The launchpad pays 70% of its 1%-per-trade fee to whoever created the token. If that is some other address, the 0.7%-of-turnover stream never arrives, and there is no way for the operator to detect or recover it.
- The router and burn path stay empty until graduation. Filling them before a real pool exists makes every swap fail, or worse, succeed against the wrong pool.
- The threshold is only meaningful against the supply. 100,000 tokens is an absolute number; whether it selects a sensible set of holders depends entirely on what the supply turns out to be at launch.
- The proofs directory has to ship with the site, every hour. It is the only copy of a published tree and cannot be rebuilt from the chain. If it stops being published, holders cannot construct a claim even though their money is sitting in the contract with their name hashed into the root.
Until those are closed, the addresses for the token, the distributor and the reserve do not exist, which is why the addresses page says so rather than showing something.
What a holder actually carries
Stated plainly, because everything above is a list of mechanisms and this is the summary a reader is owed:
You hold a launchpad memecoin. Attached to it is an off-chain process that, when it runs, measures one wallet's growth over an hour and commits half of it to a Merkle root you can claim against for seven days. The measurement is checkable, the commitment is enforced by a contract that cannot be upgraded, and the claim needs nobody's permission. Everything upstream of the measurement — whether the bot earns, whether the operator runs, whether the fee stream is wired up — rests on one person and one key, and the token's price is a market's opinion that has nothing to do with any of it.