Robinhood Chain · 4663 · hourly
MEVHOOD runs a bot on Robinhood Chain. It works the spread between pools — memecoins today, tokenized stocks next door — and once $MEVHOOD trades on its own launchpad, a 0.7% creator fee lands in that same reserve wallet on every trade, on top of whatever the bot made. Half of the hour's combined income goes to registered holders, three-tenths stays as the bot's next bid, and a fifth buys $MEVHOOD back on the open market and burns it.
The hour
Profit isn't modelled or quoted. It's the reserve balance now minus the reserve balance written into the last epoch's log, and the explorer will show you both sides of that subtraction. A trade the bot closed and a creator fee from someone else's trade both land in the same wallet, so that one subtraction counts either without needing to tell them apart.
Before $MEVHOOD trades anywhere, there's no fee and no router to swap through, so the burn is skipped and its fifth just sits in the reserve — that's the honest pre-launch state, not an error. And once the burn does run, this page never takes the operator's word for how much: BURNED comes straight off the token's own transfers to the dead address, the same place you'd check it yourself.
The stock board below is a field the bot does not work yet. It is here because you can check it yourself, the same way you check everything else on this page. Chainlink publishes the exchange price for each stock on-chain, the pool sets its own, and the gap between the two is what's worth watching: oracle from the chain RPC, pool from Dexscreener.
| Ticker | Oracle | Pool | Premium | Liquidity | 24H Vol | Oracle age | |
|---|---|---|---|---|---|---|---|
| reading the field… | |||||||
Dead pools (under $5k liquidity or a gap over 50 %) are listed without a premium. A pool with zero 24h volume is asleep — listed without a premium even if its liquidity looks real. An oracle older than six hours means the exchange is closed — that is when the gap grows.
State
Three-tenths of each hour's income never leaves this wallet — that's the bot's bid for next hour, and the only reason one hour can get bigger than the last. The rest goes out: half to holders, a fifth spent buying $MEVHOOD back to burn.
Legs the bot moved through each token in this window, not what it made. Profit only shows up once there’s an epoch log to read it from.
Your browser talks to the public RPC directly. There's no API in front of it, so a number that's wrong here is wrong on the explorer too.
Paired with HOOD. Robin Hood's cut, on Robinhood's chain, priced in Robinhood's stock. HOODon / USDG pool ↗
HOOD here is Ondo's token of Robinhood Markets stock; it has no Chainlink feed, so it never appears on the field.
Bots take the spread. This one gives it back.
Mechanics
Pool against pool: the same memecoin prices against USDG in one venue and against WETH in another, and the two quotes drift from what the USDG/WETH rate says they should. The bot trades the triangle back into line.
Backrunning a swap: a large buy or sell knocks a pool off its own price for a block or two, and the bot trades into that window right after it lands.
Working thin books directly: PONS, CASHCAT and the smaller names in the bot's inventory don't need a second venue to drift — a single pool can sit lopsided on its own, and that's spread enough.
Reserve balance now, minus the reserve balance recorded in the previous epoch's log. Two numbers, one operation, both visible on Blockscout. Nothing about strategy or fill quality enters the calculation.
Half the hour's income becomes the pool, three-tenths stays in the reserve, and a fifth buys $MEVHOOD on the open market and sends it to the dead address — 5000/3000/2000 basis points, always summing to 10000. The pool is divided pro-rata by snapshot balance, so a wallet holding 2% of the registered supply gets 2% of that hour's pool and nothing more.
Payouts go out in batches of 300, and anything under 0.00001 ETH is skipped rather than burned on gas.
An hour without profit closes as a zero epoch. It shows up on the board like every other hour.
Board
| Epoch | Profit | Paid | Burned | Holders | Reserve after | Tx |
|---|---|---|---|---|---|---|
| before the first epoch | ||||||
The last 24 epochs. Each row is one Epoch log, pulled with eth_getLogs walking back from the head of the chain; the transaction hash on the right is the payout itself. Ticker touches are counts of transactions the MEV contract sent or received in the epoch's window, not per-ticker profit. BURNED is what that epoch's own log reports; TOTAL BURNED above is checked separately, straight off the token's transfers to the dead address, so the two can be compared against each other rather than taken on faith.
The contract writes your address into a list and stops there. It never asks for an allowance, so it can't move your tokens, and it reads your balance only at the snapshot block.
Contract wallets without a receive() get marked ✗ and their share stays in the reserve.
Lookup
Paste an address and the page replays its payout logs from the deploy block. It doesn't have to be yours, and nothing is stored.
| Epoch | Amount | Status |
|---|---|---|
| nothing searched yet | ||
Fourteen questions about how the contract and the operator actually behave, answered without a single number typed in by hand.
It runs on Robinhood Chain and works the spread between pools that price the same asset differently. Right now 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.
Tokenized stocks are a separate field entirely — they carry a Chainlink oracle and their own pools, and the bot hasn't traded a single one of them yet. The mechanic would look similar if that ever changes, which is exactly why the board stays on this page.
Seven tokens, named in the constants at the top of the script and never typed by hand: USDG and WETH as the liquid core, then PONS, CASHCAT, BOING, LAMBO and PEPONS as inventory. It does not trade any of the 35 tickers on the stock board below — no stock token, no Chainlink feed, not yet. If that changes, it'll show up here, because the numbers on this page come from querying those seven addresses directly, not from a claim about strategy.
One hour, closed at :00 UTC by the operator script. Income for that hour is the reserve's balance right now minus the balance recorded in the log of the epoch before it — one subtraction, checkable on the explorer, that doesn't care whether the money came from the bot's trades or from $MEVHOOD's own creator fee landing in the same wallet. Half goes out to registered holders, three-tenths stays as working capital for the next hour, and a fifth buys $MEVHOOD back and burns it. An hour with nothing to distribute still closes, just with a payout of zero and nothing burned, and it still shows up on the board like any other row.
Two sources, one wallet. The bot's own spread is the first, the same as it's always been. The second showed up once $MEVHOOD started trading on its launchpad: PONS takes 1% off every trade there and splits it 70/30 between the token's creator and the protocol itself, so a token whose creator address is set to the reserve wallet earns 0.7% of every trade that happens, automatically, with no code of ours involved.
Both land in the reserve. That's exactly why one subtraction — balance now minus balance at the last epoch — measures both without anyone having to separate a trading profit from a fee.
One transaction: the operator swaps ETH for $MEVHOOD on a router and sends the output straight to 0x000…dEaD as part of the same swap. The bought token never sits in the operator's wallet, not even for a block, so there's no step where anyone could redirect it.
Check it the same way the page does: pull up the burn transaction on Blockscout and read its Transfer log for $MEVHOOD — the recipient is the dead address, and the amount is what TOTAL BURNED adds up. Before $MEVHOOD graduates off the bonding curve there's no router to swap through, so the burn is skipped on purpose; that epoch's burned figure is zero and the fifth that would've bought it stays in the reserve instead.
You send one transaction calling register() on the distributor contract. It writes your address into a list and nothing else: no allowance, no approval, no way for the contract to move your tokens. Your balance only gets checked once, at the snapshot block, which sits ten blocks behind the current head so a sequencer reorg can't reach it.
Pro-rata by whatever balance your wallet holds at the snapshot block, split among everyone who registered before that block. Wallets under 0.01% of supply get skipped entirely, and any computed payout under 0.00001 ETH stays in the reserve instead of getting burned on gas. Payouts then go out in batches of at most 300 addresses per transaction, which is as many as the contract will accept at once.
If your wallet is a contract with no receive() function, the transfer fails, the epoch's log marks you with an ✗, and your share goes back into the reserve rather than vanishing. If a batch fails partway through a run, the operator journals exactly what shipped and picks up from there on the next hourly pass, so nobody gets paid twice. Faced with a number it can't verify on-chain, the operator closes a zero epoch instead of guessing.
Everything here comes straight from your browser, with no API reshaping it in between: the reserve balance from eth_getBalance on the public RPC at rpc.mainnet.chain.robinhood.com, the epoch history and every payout from eth_getLogs against the distributor's Epoch and Paid events, oracle prices from latestRoundData() on the Chainlink feeds, and pool prices from Dexscreener. Pull up Blockscout, paste in the distributor address, and cross-check whatever looks off. It should match exactly, because both pages are reading the same chain.
For each stock, the oracle's Chainlink price against whatever the pool is actually quoting. A pool with under $5k in liquidity or a gap over 50% gets listed without a premium number, because at that point the price isn't trustworthy enough to mean anything. A pool with zero trading volume over the past 24 hours is marked asleep and dropped from the median, and an oracle older than six hours gets the same asleep label; that's simply what a closed exchange looks like from the chain's side.
A count of transactions the MEV contract sent or received during that hour's window, grouped by whichever token was on the other side of the transfer — one of the bot's own memecoins, or a ticker from the field below if that ever starts happening. A high touch count on one token says the bot was busy there; it does not say the bot made more money there than anywhere else. The hour's actual profit is a single figure, and it comes from one place: the Epoch log, not a sum of transfers.
Two eth_getLogs calls against the seven tokens the bot actually holds — USDG, WETH, PONS, CASHCAT, BOING, LAMBO, PEPONS — scoped to the last 36,000 blocks, about an hour: one for Transfer events where the executor is the sender, one where it's the receiver. Add every log up and you get legs, not transactions; a single trade can move through two tokens, so the tx count on the page will always sit lower than the leg count. None of it is profit, and the page never says otherwise.
The executor's own balance is read the same way and split into a liquid core — USDG and WETH, marked at pool price — and inventory, everything else it's holding, in units with a dollar estimate alongside wherever Dexscreener has a quote. That balance is the bot's working capital, not the reserve. The reserve is a separate wallet, and it doesn't exist until the token deploys.
Not a share of the MEV contract, not a claim on the reserve, and not an obligation on anyone's part. What you get is a pro-rata cut of whatever landed in the reserve the hour before — bot profit, creator fee, or both — using the same subtraction the epoch log documents, and on plenty of hours that number lands on zero. Register because you want in on that split, not because anyone promised a fixed return.