New measurements show that block production continued during the September incident. That does not establish that users could submit transactions without difficulty.
The claim that Robinhood Chain stopped producing blocks for at least 14 minutes on September 4 has been corrected following later measurements. In its September 30 report, CryptoSlate acknowledged that its earlier block-halt claim was wrong. The Ethereum layer 2 network kept making blocks, while successful transactions at apps fell sharply for roughly 40 minutes.
854,255 blocks: data posting paused, production continued
The current edition of Glass Hull’s full-day measurement, dated September 29, covers all 1,440 minutes of September 4. It counts 854,255 blocks, with a maximum interval of two seconds between consecutive blocks. Even the minute beginning at 12:57 UTC, the previously reported start of the halt, contained 592 blocks.
The two long pauses totalling 14 minutes occurred in a separate process: posting Robinhood Chain’s data to Ethereum. The study places them at 12:29:47–12:38:23 and 12:42:47–12:48:11 UTC. Both ended before the 12:57 time cited in the earlier reports.
Producing blocks does not mean accepting every user transaction. A chain can keep building blocks while a provider used by an app has problems. Delays in posting data batches to Ethereum are also distinct from a halt in the chain’s own block production.
Apps faced roughly 40 minutes of disruption
Walnut’s September 23 analysis reports a sharp drop in successful traffic at busy apps between 12:37 and 13:20 UTC. The median app in that group completed about one fifth of its usual number of successful transactions. That does not mean 80% of all users lost money, or that every transaction on the network failed.
Quicknode’s incident record provides separate evidence of user-facing problems. The infrastructure provider began investigating latency at 13:10 UTC on September 4. At 16:20, it reported issues with transactions landing and connections to the sequencer feed. Its service incident was marked resolved at 01:12 UTC on September 5. That duration measures something different from Walnut’s window of reduced app traffic.
In its statement on the day of the incident, Arbitrum said direct user transactions had not been delayed, while some infrastructure providers using the data stream had experienced a brief performance impact:
“Robinhood Chain experienced no downtime.”
Fees remain part of the debate, not a settled cause
Walnut argues that a low priority fee left the process posting data to Ethereum behind competing transactions. Glass Hull says the included on-chain records alone do not establish the cause of the delays. The link between fee competition and the disruption experienced by users should therefore not be presented as a settled root cause.
In layer 2 economics, posting data to Ethereum is a separate cost. The incident also calls for three distinct indicators to be read together: blocks produced, data posted to Ethereum and transactions completed by apps. For readers following blockchain infrastructure developments, the distinction is practical: an uninterrupted stream of blocks does not by itself prove an uninterrupted user experience.
