The sequencer feed, in your browser
The stream
Robinhood Chain broadcasts every transaction its sequencer accepts on a public WebSocket, and the server takes connections from any origin. So your browser can read it directly. Below is that feed, decoded here: no server of ours in between, no API key, nothing uploaded.
Your browser connects straight to wss://feed.mainnet.chain.robinhood.com. Nothing is uploaded and there is no server in between. The broadcaster replays its buffer to every new client, so the first few seconds are blocks that already happened; those are counted and skipped, and the stream above starts at the first message that is both past the chain head and separated by a gap a replay never produces. Reading stops after three minutes, because this is a real feed and real bandwidth.
What you are looking at
Each row is one message from the sequencer. The number is its sequence number, which on this chain is also the L2 block number. The time beside it is the gap since the previous message reached you, which is this chain producing a block roughly every 100 ms. The marks are one per transaction, in the order the sequencer took them, and the ones in colour go to a contract listed in the toolkit: a router, a pool manager, a token, a lending market.
Underneath, the newest block is listed transaction by transaction. That list is the ordering rule of this chain made visible. Nothing in it was sorted by fee, because nothing here can be. Position one got there by arriving first.
The decoding follows Nitro's own message format. The payload is a batch whose sub-messages carry an eight byte length prefix, and a signed transaction is an EIP-2718 envelope whose hash is a keccak over exactly those bytes. That is why the hashes match a block explorer: they are not labels handed to us, they are computed here from the bytes that came off the socket.
Why this is the whole point
A searcher on this chain has no mempool to watch and no auction to bid into. What exists is this feed, and it is ahead of everything else: a transaction is in it the moment the sequencer accepts it, before any RPC will serve you the block that contains it. The check in the panel above measures that gap for one real transaction, by asking the public RPC for a hash the feed has already given you and counting the queries that come back empty.
That is the edge, and it is also the limit. Being told first is worth something only if you are close enough for first to mean anything. The intervals above are measured in your browser and can be read against the committed blck-probe run beside them. If your numbers look like that run, you are seeing the chain at its real rate. How long it then takes you to answer is a different measurement, and it is the one on Benchmarks.
One caveat that matters before anyone builds on this: a transaction can appear in the feed and never take effect. The sequencer can filter it. The feed is the earliest signal available, not a settled fact, and blck-sim exists because the only safe place to be wrong is before you send.