Overview

What MEVHOOD is made of, what happens in an hour, who is holding what at each moment, and the things the protocol refuses to claim.

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.

MEVHOOD is an arbitrage bot on Robinhood Chain with a token bolted to its income. Once an hour the wallet that bot pays into is measured, and whatever showed up since the last measurement is cut three ways: half goes behind a Merkle root that $MEVHOOD holders take for themselves, three tenths stays as the next hour's working capital, and a fifth buys $MEVHOOD on the open market and sends it to a dead address.

That is the whole product. There is no pool to deposit into, no lock, no position to open. You hold the token, the clock runs, and at the top of each hour a root either exists or it does not.

What the protocol is made of

Almost none of this is our code, and the parts that are get counted honestly below. The chain, the arbitrage, the token's market and the price feeds were all running before MEVHOOD had a name.

Layer	What provides it	How much of it we wrote
Blocks, gas, settlement	Robinhood Chain, an Arbitrum Orbit rollup, chain id `4663`	none
The arbitrage itself	an executor contract that was trading memecoin pools before the token existed	none; it predates `$MEVHOOD`
The token, its market, and the fee on it	the PONS launchpad, which takes 1% of every trade and splits it 70/30 between a token's creator and the protocol	none, and no code of ours collects it
Batched reads of balances	Multicall3 at its canonical address `0xcA11bde05977b3631167028862bE2a173976CA11`	none
Prices on the premium board	Chainlink feeds on one side, Dexscreener pool quotes on the other	none
The hourly split, the root, the claim, the sweep	`MevhoodDistributor`, one Solidity file with no proxy and no library beyond an inline `IERC20` interface	the entire on-chain surface
The snapshot, the tree, the buy-and-burn, the publication	`epoch.mjs`, node 24 and viem, fired by a systemd timer once an hour	all of it, none of it on chain
This documentation and the front page	static HTML that reads the public RPC from your own browser	all of it, and it holds nothing

The distributor is a ledger, not a router. It never asks for a token approval, it cannot move $MEVHOOD out of anyone's wallet, and the only asset it ever holds is the ETH of epochs still inside their claim window.

The lifecycle

One hour, left to right. Everything to the left of the split happens in a single run of the operator script; everything to the right of the root is a holder spending their own gas, on their own schedule, inside seven days.

Two income streams land on the same wallet, so one subtraction measures both. The bot's spread is one. The launchpad's creator fee is the other: PONS pays 70% of its 1%-per-trade cut to whoever created the token, which works out to 0.7% of every $MEVHOOD trade, and it arrives with no code of ours in the path. Neither stream is separated in the accounting, because the operator has no way to separate them and pretending otherwise would be a guess.

Who holds what, at each moment

Moment	Reserve wallet	Distributor	Your wallet
During the hour	everything the bot and the fee have brought in	only epochs still inside their window	your `$MEVHOOD`, untouched
At `:00`, before publication	the same balance, now being measured against the last epoch's record	unchanged	unchanged
The moment `openEpoch` lands	income, less the pool it just funded and the burn it spent	that hour's pool, funded in the same transaction as the root	unchanged
After you press MEV NOW	unchanged	that much less	your share, in ETH, minus your own gas
After seven days	whatever nobody claimed, returned by `sweep`	nothing left of that epoch	whatever you took

Your $MEVHOOD never moves through any of this. The snapshot reads balanceOf at a block; it does not transfer, lock or escrow anything, and the claim only ever sends ETH in one direction, out of the distributor and into the address that asked.

What MEVHOOD does not do

It does not promise a return. An hour that earned nothing closes as a zero epoch, with an empty root and nothing funded, and it goes on the board next to the hours that earned something.
It does not hold your tokens. No approval is ever requested, and the distributor has no code path that could move $MEVHOOD from anyone's wallet.
It does not start a trade when you press the button. MEV NOW withdraws a share that was computed and funded before you connected. The bot's hour was over by then.
It does not decide for you. Miss the seven days and your share returns to the reserve. That is the rule the contract enforces, not a penalty anyone chose to apply to you.
It does not pass someone else's numbers off as its own. Burned supply is counted from Transfer logs into 0x000…dEaD, so the figure survives an operator who lies in the event.
It does not hide a bad hour. Income is a subtraction, and both of its sides are balances you can read on Blockscout without asking us anything.

Honesty principles

These are constraints on the page, not claims about the protocol.

No number on this site is typed in by hand. Where there is nothing to show, the page prints a dash, never a zero, because those are different facts.
The bot's inventory is labelled an estimate at pool price, because that is not a price it could actually exit at.
Zero epochs get published exactly like profitable ones, in the same table, in the same colour.
When the RPC will not answer, the page says the network did not answer instead of showing the value it had a minute ago.
The backup RPC carries its measured limits in writing, including the log queries it cannot serve, so nobody reads it as full redundancy.

Where to go next

The hour is the one page to read if you only read one: the snapshot, the subtraction, the two streams and the split, in the order the operator performs them.
The observer reads executor balances and tracked transfers. The holder plan describes planned allocations. Epoch history, wallet lookup and claims are not live in the current interface.
Blockscout settles any argument with this documentation. Both read the same chain; only one of them is a static file.

The rest of the tree in the sidebar covers the parts this page compresses: MEV NOW and every revert a claim can hit, the bot and the difference between its working capital and the reserve, the burn and the six conditions that skip it, the premium board as the field next door, what can go wrong including the gates still open before launch, the operator with its exit codes and its recovery, addresses with what each one costs you to trust, and the FAQ.

This is the first page.