MEVHOODDocs
Contents

The hour

The planned snapshot and 50/30/20 split, with reserve-delta accounting limitations and launch prerequisites.

Pre-launch documentation. Token, vault and distributor are not connected. Claims are not open. Allocation rules describe the planned mechanism. Reserve balance growth alone does not prove trading profit; deposits and earned income must be reconciled before payouts launch.

An epoch is one hour, closed at :00 UTC by a script on a timer. Nothing about it is continuous: there is no streaming balance, no accruing position, no number that ticks up while you watch. There is a moment when the operator reads two balances, subtracts one from the other, and publishes what it found.

This page describes the planned epoch process, not a live payout service. The observer currently shows executor balances and transfers. Epoch history will require a configured distributor and funded, verified publications.

The snapshot

The share table is built on balances at latest − 10: ten blocks behind the RPC head when the run starts. This is a delay, not a finality guarantee. A reorg can still invalidate an insufficiently finalized snapshot; the production finality policy remains a launch consideration.

Buying $MEVHOOD after the snapshot block does not get you into that hour. It gets you into the next one, which begins immediately.

The holder list itself is not a registry. There is nothing to sign up for and no gas to spend getting in line. The operator replays the token's own Transfer logs from the block the token was created in, which reconstructs every balance at the snapshot block, and then checks the replay against totalSupply(). If the replayed balances do not add up to the supply, the list is incomplete and the run refuses to publish anything rather than pay out a tree it cannot vouch for.

Income is a subtraction

income = balance(reserve) at the snapshot
       − reserveAfter recorded in the previous epoch's log

This computes a reserve-balance delta. Both inputs can be checked on chain, but the result alone cannot distinguish earned income from capital contributions, refunds or other deposits. An accounting and reconciliation layer is required before this value can be labelled distributable profit.

For the very first epoch there is no previous event, so the baseline is RESERVE_START_WEI, written into the operator's config by the deployment script and non-zero by requirement. A first run with a zero baseline refuses outright.

The current operator treats any positive reserve-balance increase as income, including top-ups, refunds and mistaken transfers. That is a launch blocker: contributed capital must be separated from earned income before payouts start. Do not fund or operate this mechanism as though that accounting problem were already solved.

To repeat the calculation yourself for any past hour: take that epoch's row on the board, note the reserveAfter of the epoch before it, then read the reserve's balance at the later epoch's snapshot block. The difference is the income that epoch reported.

Two streams, one wallet

StreamWhere it comes fromWhat we had to write for it
The bot's spreadan executor contract working memecoin pools against each other, against the rate implied between USDG and WETH, and behind large swaps that knock a pool off its own pricenothing; it was running before the token existed
The token's creator feePONS charges 1% on every trade of a token launched there and pays 70% of that to the token's creator, so a token whose creator address is the reserve wallet collects 0.7% of its own turnovernothing; no code of ours is in the path

Both streams are intended to reach the reserve. The executor-to-reserve conversion and transfer path has not been implemented, and creator-fee routing and current launchpad terms still need confirmation. A reserve-balance subtraction does not identify either stream.

Fifty, thirty, twenty

ShareBasis pointsWhere it goes
Holders5000funded into the distributor under this hour's Merkle root
Reserve3000stays on the reserve as working capital for the next hour
Burn2000buys $MEVHOOD on the open market and sends it to 0x000…dEaD

The three must be integers summing to exactly 10000. An operator config where they do not sum to 10000 exits before a single transaction is broadcast, which is deliberate: a misconfigured split is the one error where continuing would move real money to the wrong place.

The pool and burn shares floor-divide independently, and whatever the two floors leave over is folded into the reserve share, so the three always add back up to the hour's income exactly. No wei is created or lost to rounding.

The pool is then divided pro rata by snapshot balance among the wallets above the threshold. A wallet holding 2% of the eligible supply is a leaf worth 2% of that hour's pool. The leaves are keccak256(abi.encode(address, amount)) with sorted pairs, which is the format the contract's own proof check expects, and the root and its funding go on chain in one transaction: openEpoch requires msg.value to equal the tree's total, and requires the epoch id to be exactly one past the last one closed.

Publishing costs about 118,000 gas no matter how many wallets are in the tree, measured by forge test --match-test test_gas_openEpoch -vv and repeatable on any checkout. The 300-recipient push this replaced cost roughly 11.4 M gas for the same hour, out of the same reserve the holders were being paid from. A holder's own claim runs about 60,000 gas, paid by the holder.

The thresholds

  • 100,000 $MEVHOOD at the snapshot block. Below that a wallet is not a leaf in the tree at all. The threshold is a number in the operator's config and in the contract's published constants, not a judgement made per wallet.
  • 0.00001 ETH minimum share. Amounts under that are left out rather than written into a proof that would cost more gas to spend than it is worth. The skipped dust stays on the reserve.
  • Excluded addresses. Pools, the launchpad, the reserve wallet and the distributor itself are removed from the share table before it is built. They hold token balances that are not anybody's position.
  • A gas ceiling. Robinhood Chain reports a block gasLimit of 1125899906842624, which is 2^50 and an Arbitrum-style placeholder rather than a budget; recent blocks actually use around 10.3 M. The real ceiling is the Orbit per-transaction cap of 32,000,000, and a publication estimating above 90% of it refuses rather than broadcasts.

The zero hour

An hour where the subtraction comes out at zero or below closes exactly like any other hour. The epoch id advances, the event is emitted, the row appears on the board, and the fields that would have carried money carry zero: an empty root, nothing funded, nothing burned.

That is not the script failing. It is the script reporting, and a documentation site that buried those rows would be worth less than no documentation. Two more things can be zero without anything going wrong:

  • burned is zero whenever the swap was skipped, which is the honest default before $MEVHOOD graduates from the launchpad's bonding curve onto a real pool, and also what happens when a swap reverts, fills below its floor, or would cost more than a tenth of the burn share in gas. Every one of those is a skip, never a refusal to close the epoch, and the un-burnt wei stays on the reserve.
  • holders is zero when no wallet cleared the threshold at the snapshot block.

What the hour leaves behind

One Epoch event, indexed by id, carrying the snapshot block, the income, the amount burned, the reserve balance afterwards, the number of holders in the tree, the root and the amount funded under it. That is the whole field list as the contract emits it; an earlier plan had an asset field and a paid field, and neither survived the move to Merkle claims, so nothing reads them. That event is the record. The operator also keeps a local journal and the proof files holders need to build a claim, but neither of those is where the site reads its numbers from, and neither can contradict the chain without the contradiction being visible.

The claim itself, the seven-day window and the sweep that follows it are the next page, along with every revert a wallet can hit on the way. What the operator does between the snapshot and the publication, and what happens when a run dies halfway through it, is on the operator page.