How to track memecoin trades on Robinhood Chain and Solana

TL;DR: Robinhood Chain has no public mempool, so a transaction is invisible until the sequencer has already decided its order. Two open-source Chainstack Labs tools work around that: robinhood-chain-sequencer-feed reads the sequencer’s own broadcast feed, and fomo-solana-rh-listeners joins that feed with Solana’s to reconstruct trades that cross both chains. We cloned both, ran them against live mainnet, and deployed a real Chainstack Robinhood Chain node to check the other side of the claim. This walks through installing them, running them, and what the numbers in their own output mean, with real transactions and stats from our own runs.

Why this is harder than a normal RPC call

On most EVM chains, a transaction sits in a public mempool before it lands in a block — that’s the whole basis for MEV, front-running protection, and most trade-detection tooling. Robinhood Chain, an Arbitrum Orbit L2, skips that step entirely. A transaction is invisible to any RPC endpoint, explorer, or indexer until the sequencer has already committed an ordering and built the block. Everything downstream has to re-execute the block before it can tell you what happened, so it finds out later than the sequencer did.

The sequencer does broadcast one thing early: a WebSocket feed carrying the ordering and the raw calldata, with no result attached. robinhood-chain-sequencer-feed turns that feed into structured data. It’s a narrower promise than a mempool — the sequencer has already decided the ordering by the time it broadcasts, so this is soft-confirmation visibility, not front-running opportunity.

Memecoin trading on Robinhood Chain is also increasingly not confined to one chain. FOMO, an experimental cross-chain social trading app, settles one leg of a trade on Solana and the other on Robinhood Chain, linked only by a shared Relay order ID with no shared contract state. fomo-solana-rh-listeners is Chainstack Labs’ reference implementation for reconstructing those trades from both sides at once — and, as we found once we read past the README, a seller’s payout is identifiable only by matching order IDs across chains, not by anything in the transfer itself.

robinhood-chain-sequencer-feed

Setup

Requirements: uv, which fetches its own Python 3.11+.

git clone https://github.com/chainstacklabs/robinhood-chain-sequencer-feed.git
cd robinhood-chain-sequencer-feed
uv sync

On our run, uv sync resolved 33 packages and built the project in about a second, pulling in coincurve and pycryptodome for the signature-verification path.

Before touching the live network, the repo’s own test suite runs entirely offline, against 143 real transactions captured from mainnet and bundled into the repo:

uv run --extra dev pytest

On our run: 130 passed in 8.20s — every test that checks the decoder and the ECDSA verifier against the libraries they replace.

Running it against live mainnet

The CLI, rhfeed, normally sits behind a local Docker relay (Offchain Labs’ official relay binary, which re-serves one upstream connection to as many local consumers as you like — useful because Robinhood rate-limits per client, not per connection). We didn’t have Docker available in our environment, so we used the CLI’s other mode, which skips the relay and connects straight to the public feed:

uv run rhfeed --feed mainnet --seconds 15

Real output from our own run against wss://feed.mainnet.chain.robinhood.com, unedited except for truncating the list:

# connecting to wss://feed.mainnet.chain.robinhood.com
# live — 528 backlog messages skipped, at seq 64400750
seq 64400751  10 tx
    0xa44b4c07cfdf4d95b00a477e455409100fe45416d22aa944ced44d409cb31066  transfer 0x8ad80f88Cb…
    0xc6a9eed0f7c27272dfef81e5fe126b275537eaebbd76ed1464e2f392ecac381b  transfer 0xF9De3EC2AB…
    0xf66bf5b415fa1967390f68134622925f80476af6508d600385fab08a42db6335  call     0x656111aC22…  0x00000002
seq 64400760  85 tx
    0x7e698891eba94283196448a83836d8e2bf73b963c786cc5b6d5ebce3499c3e9b  transfer 0x9cbabC8E9c…
    ...
# 852 transactions seen | 167 live messages, 736 backlog skipped, 0 failed connections

852 transactions over 15 seconds, across 167 live sequencer messages — one message can carry anywhere from a handful of transactions to, in block 64400760 alone, 85 of them in a single burst.

Filtering works the same way live. Adding uv run rhfeed --feed mainnet --verify --selector 0x095ea7b3 --seconds 12 checks the 65-byte ECDSA signature every message carries (dropping anything that fails it) while filtering to ERC-20 approvals only. Real summary line from our run: 47 transactions matched | 134 live messages, 651 backlog skipped, 0 unverified dropped, 0 failed connections. Every message that reached us carried a valid signature from the sequencer’s key — worth stating explicitly, because the repo’s own README is unusually blunt that a local relay does not do this verification for you by default; the check has to happen at your end.

Reading the benchmark numbers

The repo ships an offline replay mode that decodes the same 143 test transactions from disk — no relay, no network — and ranks what’s in them:

uv run python examples/replay_capture.py

Real output from our run:

39 blocks, 143 transactions, 0 deploys
0 messages entered through Ethereum rather than the sequencer
envelope types: {2: 136, 0: 7}

most-called contracts
  0xcaf681a66d020601342297493863e78c959e5cb2      15  10.5%
  0x65050a9b7e5075a2ba5ced7b1b64ee66262c40dc      15  10.5%
  ...
recovering 142 senders took 14 ms, 96 us each — the reason a live filter matches on `to` and `selector` first

And the field-cost benchmark, which explains why:

uv run python examples/bench.py

Real numbers from our machine:

What you read	Per transaction
to_bytes, selector, value, nonce, gas	1.9 µs
+ hash	7.0 µs
+ to (checksummed)	9.7 µs
+ sender	36.7 µs

One core, full decode including sender recovery: ~27,008 tx/s on our hardware — comfortably ahead of Robinhood Chain’s own throughput of roughly 71 transactions a second, but the table is the actual point: recovering a sender costs nearly 20× a cheap field, which is why a production filter checks to and selector before ever touching sender. The repo’s own reference numbers (run on different hardware) put full decode at ~14,000 tx/s and sender recovery at ~70 µs — same shape, different machine, which is exactly why the benchmark ships as a script you run yourself rather than a number you take on faith.

What it won’t tell you

Two things worth stating plainly, because the repo’s own README does:

These are soft confirmations, not settled transactions. The sequencer has already committed the ordering and built the block by the time a message reaches you, but a transaction here can still revert, and Robinhood Chain’s ArbOS 61 compliance-filtering layer can void it after the fact — it still lands in a block, with status 0x0, no logs, and gas fully burned. rhfeed.is_filtered_call(tx_hash) builds the eth_call that answers whether a specific hash has been voided; send it to a node, not to the feed.

There’s nothing to front-run. The feed reports what the sequencer has already decided and already executed. You’re reading, not racing.

fomo-solana-rh-listeners

Reading Robinhood Chain alone misses a growing share of memecoin activity. FOMO deploys no contracts of its own — its footprint is ERC-4337 wallets carrying an EIP-7702 delegation, Relay’s settlement contracts, and ordinary AMM pools, split across Solana and Robinhood Chain. A crossing trade lands as two separate transactions, one per chain, joined only by a shared 32-byte Relay order ID.

The two legs are not equally easy to resolve. Whichever leg happens first carries the order ID, so that side is never in question. A sell’s payout is predictable in destination — it lands on Solana — but not in identity: it’s a plain USDC transfer signed by the solver, calling no Relay program and emitting no event. Matching it to a specific sell already seen on Robinhood Chain, via order ID, is exactly why the repo ships two dedicated scripts (05_listen_relay_payouts_blocks.py and 06_listen_relay_payouts_grpc.py) just for that leg, keyed on Relay’s solver rather than on FOMO’s own wallets. A buy is the reverse problem: the payment leaving Solana is clearly identifiable, but its destination chain isn’t fixed to Robinhood Chain — resolving where the token lands means tracking every chain FOMO supports, not just this one.

git clone https://github.com/chainstacklabs/fomo-solana-rh-listeners.git
cd fomo-solana-rh-listeners
uv sync

Running the Robinhood Chain leg live

00_listen_fomo.py joins both chains into one feed, but each transport also runs standalone. We deployed a real Chainstack Robinhood Chain node to test the Robinhood-side listener against production infrastructure rather than a public, rate-limited endpoint:

curl -X POST YOUR_CHAINSTACK_ENDPOINT \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'
# {"jsonrpc":"2.0","id":1,"result":"0x3d6ca34"}   → block 64,408,116

With ROBINHOOD_MAINNET_WSS pointed at that endpoint:

uv run scripts/01_listen_robinhood_logs.py 60

Real output from our 60-second run, unedited except for truncating the address column:

   time  kind              gave    got                  wallet       venue      where      trade
  +1.1s  BUY                       1.963M WAIFU         0x051F…5B97  UniV3+Uni… b64402921  0xfae8…d868#36
  +1.3s  BUY                       7.48M Chad           0x6be0…7866  UniV4      b64402923  0x9091…73a5#24
  +1.8s  SELL         1,553 par -> 3.050031 USDG        0xF8E6…05Fc  UniV4+Pan… b64402928  0x4636…9663#15
 +18.2s  PAY         101.2 USDG -> an unnamed token     0x7Ba4…fa32             b64403090  0x295b…4f68#6

That PAY … -> an unnamed token line is the README’s claim, live: the deposit is visible the instant it lands, but the token it’s paying for genuinely isn’t named anywhere in this event — it only shows up later as a BUY once the solver delivers it.

Over the full 60 seconds we logged 115 FOMO trades: 60 BUY, 48 SELL, 7 PAY. musebook was the single most-bought token in the window (24 buys), ahead of everything else combined — a snapshot of whatever’s trending on Robinhood Chain at the moment you happen to run this, not a stable ranking. Every recorded event carries a order_id field: the same 32-byte Relay ID that would let 00_listen_fomo.py match this transaction against its other half on Solana, extracted straight from the calldata of the call to Relay’s router.

Limitations, as observed (both tools)

• Soft confirmations only, on both tools. Nothing here is a substitute for confirming against a node — the sequencer feed’s messages and the FOMO listener’s on-chain events can both still be reverted or voided by compliance filtering after you’ve already seen them.
• The relay doesn’t verify anything by default. Passing --verify on rhfeed costs about one signature recovery per message and is the only way to know a message actually came from the sequencer’s key rather than a compromised hop in between.
• One live node per chain, per test. Our test account’s node quota let us run one mainnet node at a time, so we verified the Robinhood Chain side of fomo-solana-rh-listeners live and read the Solana Yellowstone gRPC path from source rather than running it side by side — in production you’d want both endpoints live simultaneously to get 00_listen_fomo.py‘s actual joined feed, not just one half of it.
• A sell’s payout needs its own subscription. As above: it doesn’t look like anything without one.

From a shared relay to your own node

Everything in the sequencer-feed sections ran through the public feed directly, and the FOMO listener ran through a real but disposable test deployment. In production, both tools want an endpoint that isn’t shared, rate-limited, or torn down after a test: a Chainstack Robinhood Chain node feeds 01_listen_robinhood_logs.py‘s WebSocket subscription the same way our test node did above, and a Solana node with the Yellowstone gRPC Geyser plugin enabled is the direct upstream for 03_listen_solana_grpc.py and 06_listen_relay_payouts_grpc.py — the lower-latency, processed-commitment path the repo’s own docs recommend over a plain WebSocket subscription once you’re past testing.

1. Log in to the Chainstack console (or create an account).
2. Create a new project
3. Select Robinhood Chain or Solana as your blockchain protocol
4. Deploy the node
5. Open Access and credentials and copy your HTTPS and WebSocket endpoints

Need testnet ETH first? Grab some from the Chainstack Robinhood Chain faucet.

🤖 You can also access Chainstack Robinhood Chain and Solana RPC directly from Claude, Cursor, Codex, Windsurf, Gemini CLI, GitHub Copilot, Antigravity, Claude.ai, or ChatGPT using Chainstack MCP.

💰 Promo: New to Robinhood Chain on Chainstack, or expanding an existing account to it? Apply code ROBINHOOD50 for 50% off the Growth plan — $24.50/month instead of $49/month — for the first 3 months.

Conclusion

Both tools do exactly what their READMEs claim, and we checked rather than took that on faith: robinhood-chain-sequencer-feed decoded 852 live mainnet transactions in 15 seconds with zero failed connections, its offline test suite passed 130/130, and its live signature verification correctly checked every message it saw. fomo-solana-rh-listeners correctly classified 115 real cross-chain trades in 60 seconds against a Chainstack node we deployed for the purpose, including the exact “payment with no token named” behavior its docs describe. Neither tool is a substitute for a node you control — they’re both explicit about that — but they’re also both real, and now verified.

FAQ

Q: Does the Robinhood Chain sequencer feed let me front-run transactions?

No. The sequencer has already decided the ordering and executed the transaction by the time its message reaches you — you’re reading what already happened, seconds before a node would tell you, not racing to get ahead of it.

Q: What is the Relay order ID and why does it matter?

It’s a 32-byte identifier that both halves of a cross-chain FOMO trade carry — the payment on one chain and the delivery on the other. It’s the only thing that joins them; there’s no shared contract state. fomo-solana-rh-listeners extracts it directly from calldata to perform that join.

Q: Do I need my own RPC node to run these tools?

Not to test them — rhfeed has a mode that connects straight to Robinhood’s public feed, and the sequencer-feed repo’s test suite runs entirely offline. For production use, both repos’ own docs point at a dedicated endpoint: the public feed is rate-limited and explicitly not for production use.

Q: Can a transaction shown by these tools still fail or get reverted?

Yes, on both tools. Robinhood Chain’s ArbOS 61 compliance-filtering layer can void a transaction after it’s already been sequenced — it still lands in a block, with status 0x0 and gas fully burned. Confirm against a node before treating anything as final.

Q: Why does tracking a FOMO sell need a separate listener from tracking a buy?

Because a sell’s payout is nearly invisible on its own — it’s a plain USDC transfer on Solana that calls no program and emits no event. fomo-solana-rh-listeners ships two scripts specifically for this leg, keyed on Relay’s payout solver rather than on FOMO’s own wallets.

Q: How fast is the sequencer-feed decoder?

On our test machine, full decode including sender recovery ran at roughly 27,000 transactions per second on one core — well ahead of Robinhood Chain’s own throughput of about 71 transactions a second. The repo ships the benchmark as a script (examples/bench.py) precisely because the exact number depends on your hardware.

Additional resources

• chainstacklabs/robinhood-chain-sequencer-feed
• chainstacklabs/fomo-solana-rh-listeners
• Chainstack Robinhood Chain tooling documentation
• Chainstack Yellowstone gRPC Geyser plugin
• Robinhood Chain compliance filtering — Arbitrum docs (ArbOS 61)
• More Robinhood Chain tutorials and articles on the Chainstack blog