FAQ

These fifteen questions used to live in an accordion on the front page. They are here now, answered at the length they deserve, with a link into the page that covers each one properly. The front page keeps a short version of the four that get asked most and sends the rest here, so there is one copy of each answer rather than two that drift.

The bot

What does the bot actually do?

It runs on Robinhood Chain and works the spread between pools that price the same asset differently. In practice that means memecoins: PONS, CASHCAT and a handful of smaller names, traded against USDG and WETH. A pool drifting from another pool, or from the rate implied between USDG and WETH, is a gap, and the bot closes it and keeps the difference. It also backruns: a large swap knocks a pool off its own price for a block or two, and the bot trades into that window right behind it.

Tokenized stocks are a separate field entirely, with their own Chainlink feeds and their own pools, and the bot has not traded one. Full detail on the bot.

What does the bot trade?

The observer tracks seven tokens: USDG and WETH as the liquid core, then PONS, CASHCAT, BOING, LAMBO and PEPONS. It queries only these addresses; activity in other assets requires separate inspection. See token addresses and decimals.

Where do the bot's numbers come from?

The Transfers tab reads incoming and outgoing Transfer events for the executor over 36,000 blocks. It shows the actual block timestamps, deduplicates events and groups them by transaction hash. A transfer count is not a trade count or a profit figure. Balances are read separately at one block and valued with available pool quotes.

None of it is profit and the page does not say otherwise. The executor's balance is read the same way and split into a liquid core, USDG and WETH marked at pool price, and inventory, which is everything else it is holding, listed in units with a dollar estimate alongside wherever a quote exists. That balance is the bot's working capital, not the reserve. More at how the page reads the bot's numbers.

What are ticker touches?

Older versions used ticker touches to group transfer events by token. The current observer shows recent transactions with their token names and leg counts. Neither version measures per-token profit. An Epoch event records the operator-published reserve-balance delta, which is not independently verified trading profit.

The hour

What is an epoch?

One hour, closed at :00 UTC by the operator script. Income for that hour is the reserve's balance at the snapshot block minus the balance recorded for the epoch before it: one subtraction, both sides readable on the explorer, indifferent to whether the money came from the bot's trades or from the token's own creator fee landing in the same wallet. Half is funded into the distributor under that hour's Merkle root, three tenths stays as working capital, and a fifth buys $MEVHOOD back and burns it.

An hour with nothing to distribute still closes, with an empty root, nothing funded and nothing burned, and it appears on the board like any other row. The whole sequence, in the order the operator performs it, is the hour.

Where does the money come from?

Two sources, one wallet. The bot's own spread is the first. The second arrives once $MEVHOOD trades on its launchpad: PONS takes 1% off every trade and splits it 70/30 between the token's creator and the protocol, so a token whose creator address is the reserve wallet collects 0.7% of its own turnover automatically, with no code of ours in the path.

Both streams are intended to reach the reserve, but the conversion and transfer path from the executor is still a launch blocker. Creator-fee routing and current launchpad terms also need confirmation. See two streams, one wallet.

How does the burn work?

One transaction. The operator swaps ETH for $MEVHOOD on a router and the swap's recipient argument is 0x000…dEaD, so the bought token is delivered to the dead address as part of the swap and never sits in anyone's wallet. There is no step at which the recipient could be changed after the fact.

Check it the way the page does: open the burn transaction on Blockscout and read its Transfer log for the token. The recipient is the dead address and the amount is what the burned total adds up. Before $MEVHOOD graduates off the bonding curve there is no router to swap through, so the burn is skipped on purpose, that hour's burned figure is zero, and the fifth that would have bought stays in the reserve. Five other conditions skip it too, all listed on buyback and burn.

Claiming

Why you claim instead of being paid

Pushing ETH to every holder cost one transfer per wallet per hour, forever, out of the same reserve the holders were being paid from. A Merkle root costs one transaction an hour no matter how many wallets are under it, about 118,000 gas measured against roughly 11.4M for the 300-recipient push it replaced, and the gas for taking a share is paid by whoever takes it. All of that difference stays in the pool.

Registration went with it. It only existed so the push knew where to send; a claim needs no list, because the snapshot is replayed from the token's own Transfer logs and the filter is the button itself. Nobody pays gas to get in line any more.

What MEV NOW does and does not do

The planned interface will call claim(epochId, amount, proof) from an eligible wallet. The distributor then sends its funded share in ETH. No claim action is available on the current site.

A claim does not start a trade, place an order or request token approval. The homepage robot is an artistic visualization, independent of trade and payout records. See claim mechanics.

How is my share computed?

The planned share is pro rata by snapshot token balance among eligible wallets holding at least 100,000 MEVHOOD. Shares below 0.00001 ETH are omitted. A ten-block snapshot delay is not a guarantee against reorgs; production finality must be addressed before launch.

Leaves are keccak256(abi.encode(address, amount)) with sorted pairs, which is the format the contract's own verifier expects, so the proof the operator publishes verifies against the same root the contract stores. Your amount and proof are in a static file at /proofs/epoch-<id>.json; the root they hash to is on chain, so a wrong file cannot buy you anything. See the root.

What can go wrong with a claim?

Seven distinct reverts, each with its own meaning, tabulated at every way a claim can revert. The common ones: pressing twice reverts on the contract's own flag; a wallet that cannot receive ETH within the 30,000 gas the contract forwards reverts the whole call, which leaves you unmarked and the money in the epoch; a proof that does not match the published root is rejected outright.

The seven-day window expires independently of the sweep. After block.timestamp > closedAt + CLAIM_WINDOW, a claim reverts even if the money is still in the distributor. The operator may then sweep the remainder to the reserve.

Checking things yourself

How do I check any number on this page myself?

The current observer reads balances and tracked transfers from public Robinhood Chain RPC endpoints, and pool quotes from Dexscreener. The separate stock research view reads its own price sources. Claims and epoch history require a deployed, configured distributor and are not currently available.

Open the executor on Blockscout to cross-check its balances and transfers at the displayed block. Pool quotes may update independently. After launch, the distributor events will be another source to inspect. See what a reader can verify.

Which addresses am I trusting?

Four are load-bearing and none of them exists yet: the token, the distributor, the reserve wallet and the burn router. The bot's operator and executor do exist and are published. Multicall3 and the dead address are conventional addresses nobody controls. Every one of them, with who created it and what trusting it exposes you to, is on addresses.

The neighbouring field

What does the premium board measure?

For each stock, the Chainlink oracle's price against whatever the pool is quoting. A pool with under $5,000 of liquidity, or a gap wider than 50%, is listed without a premium figure, because at that point the quote is not a price. A pool that traded exactly $0 in the past 24 hours is marked asleep and dropped from the median, and an oracle older than six hours gets the same label, which is simply what a closed exchange looks like from the chain's side.

The board is a field the bot does not work. It stays on the site because you can check it with the same two sources the page uses. Detail at the premium board.

What this is not

What is $MEVHOOD not?

Not a share of the bot, not a claim on the reserve, and not an obligation on anyone's part. What a holder gets is a pro-rata cut of whatever landed in the reserve during one specific hour, measured by the subtraction the epoch log documents, and on plenty of hours that number is zero. There is no floor, no accrual, no smoothing and no top-up from anywhere.

Hold it because you want in on that split, with the risks read and the launch gates understood. Not because anyone promised a return, because nobody here has and the mechanism does not contain one.