The bot

The bot is two addresses, not one, and neither of them is the reserve. An EOA sends the transactions; a contract holds the inventory and does the trading. Both were working before $MEVHOOD had a name, neither was written by whoever wrote this documentation, and nothing on this page is a claim about strategy that you cannot check against the chain yourself.

Operator and executor

An unverified contract is exactly what it sounds like: the bytecode is on chain, the source is not published, and you cannot read what it does from the explorer. What you can read is every token transfer in and out of it, every hour, and that is what the front page's bot panel does. We are not asking you to take the strategy on faith; we are pointing at the transfers and saying the transfers are the evidence.

A third address, 0x8f10b468b06c6fd214b65f87778827f7d113f996, spent about forty minutes on the production site in early September labelled as the bot. It is not ours. It is a network-wide factory contract that dozens of unrelated EOAs call through RelayApprovalProxyV3 and the ERC-4337 EntryPoint, it holds nothing, and it was pulled the same day the mistake was found. The record of that is in the project's own notes rather than quietly deleted, because a documentation site that hides its own corrections is not worth reading.

What it actually trades

Memecoins on Robinhood Chain. Seven token addresses, listed in the front page's constants and queried directly rather than described:

The strategy is intended to exploit differences between memecoin pools, differences against the USDG/WETH exchange rate and temporary dislocations after large swaps. Transfer records alone cannot prove that a particular transaction used one of these strategies or earned a profit.

The 35 tokenized stocks on the premium board are a separate research view. The measurement on 2026-09-05 found 292 executor transfer legs: USDG 121, PONS 117, CASHCAT 29 and WETH 25, with none on stock tokens in that historical window. This does not establish current strategy. The new observer queries only the seven listed tokens and cannot detect activity outside that set.

Liquid core against inventory

The executor's working capital is split into two categories on the page, and the split is not cosmetic. USDG and WETH are the liquid core: deep books, a dollar value that means something, and the assets a trade actually settles in. Everything else is inventory, which is a bag of a memecoin that happens to be sitting on the contract between legs.

Measured on 2026-09-05, with Dexscreener quotes: USDG 60,996.34, WETH 14.9921 (about $37,164), PONS 203,492.58 (about $180,292), CASHCAT 706,543.88 (about $184,182), plus 5,000 BOING, 2,000 LAMBO and 11 PEPONS with no quote at all.

Add those dollar figures together and you get roughly $462k, and the page deliberately never prints that number. A pool price is what the last trade paid, not what the whole bag would fetch. Selling 700,000 CASHCAT into the pool that quoted it would not return $184,182 and everyone involved knows it. So inventory is listed in units of the token, with the dollar figure alongside and labelled an estimate at pool price, and only USDG plus WETH, about $98k on that date, gets described as liquid.

One formatting detail carries real weight here: USDG has 6 decimals, not 18. A generic formatter that divides everything by 1e18 reports the USDG balance wrong by twelve orders of magnitude, and it would have been the largest number on the page.

How the page reads the bot's numbers

Two eth_getLogs calls per refresh, both scoped to the seven token addresses above and to the last 36,000 blocks, which is about an hour at the 0.1 s blocks Robinhood Chain was producing when this was measured. One asks for Transfer events where the executor is the sender, the other where it is the receiver.

The two responses are deduplicated by transaction hash and log index. Transfer legs count individual events; transactions count distinct hashes. The interface displays the actual start/end block timestamps rather than assuming 36,000 blocks always equal exactly one hour. Transfers are asset movements, not necessarily trades.

None of that is profit, and the page never suggests it is. A high leg count on PONS says the bot was busy in PONS. It does not say the bot made money there, and the arithmetic that would turn transfers into profit does not exist: an atomic arbitrage closes inside one transaction and the gain shows up as a balance change, not as a transfer you can single out. An Epoch log records the operator's published reserve-balance delta, which is not independently verified trading profit, and it is a subtraction on the reserve wallet, not a sum of anything the bot touched.

The executor is not the reserve

Worth stating on its own, because it is the single most common misreading of the bot panel. The executor's balances are the bot's working capital. The reserve is a separate wallet, the one the operator script measures, and the one the hourly split is computed from. They are different addresses with different jobs, and a dollar sitting on the executor has not been earned by anyone yet.

There is an unsolved consequence of that, recorded here rather than smoothed over. This bot accumulates its gains as USDG and WETH on the executor, while epoch.mjs measures income as the growth of ETH on the reserve wallet. Something has to move value from the first place to the second before the first epoch means anything, and neither the contract nor the operator script does it. It is on the launch gates, still open, and it is the reason this documentation talks about how an hour is measured rather than about what any hour has paid.