Last 24hassertions verified615discrepancies0feed lead p50+694mschain head27,766,350rollup0x23A19d…2D94
Observatory · measured continuously

What this chain does, as opposed to what it says it does.

Every row pairs a claim about Robinhood Chain with a request whose answer settles it. The requests run on a timer, mostly against the chain’s own public endpoint — the one in the documentation, the one a library gets pasted into — and every row says which endpoint answered it. Results are published unedited, including the row that measures us. Nothing here was typed in by a person who remembered it being true.

2
contradict their claim
documented one way, behaves another
7
behave as claimed
measured, not assumed
0
no answer yet
counted as neither
0
behaviour changes recorded
re-asked every 30 min
questionwhat it claimswhat we measuredlast checked
Is a submission refused when it arrives after the block window closes?
eth_sendRawTransactionConditional · asked of the chain’s public RPC
Documented as enforced, alongside the other three.contradicts the claim2026-08-04 16:21 UTC
unchanged since 2026-08-03 20:41 UTC
Does the chain’s own public RPC answer a contract call five million blocks back?
eth_call · asked of the chain’s public RPC
Nothing says otherwise, and every library assumes a block tag works. Standard JSON-RPC accepts a historical block on eth_call and this endpoint accepts the argument without complaint.contradicts the claim
metadata is not found, 22763548
2026-08-04 16:21 UTC
unchanged since 2026-08-03 20:11 UTC
Is a submission refused when it arrives before the block window opens?
eth_sendRawTransactionConditional · asked of the chain’s public RPC
Enforced.behaves as claimed
BlockNumberMin condition not met
2026-08-04 16:21 UTC
unchanged since 2026-08-03 20:11 UTC
Is a submission refused when the state it assumed has changed?
eth_sendRawTransactionConditional · asked of the chain’s public RPC
Enforced. This is the guard the bundle relay is built on.behaves as claimed
Storage root hash condition not met
2026-08-04 16:21 UTC
unchanged since 2026-08-03 20:11 UTC
Is a submission refused when it arrives after its deadline?
eth_sendRawTransactionConditional · asked of the chain’s public RPC
Enforced.behaves as claimed
TimestampMax condition not met
2026-08-04 16:21 UTC
unchanged since 2026-08-03 20:11 UTC
Does OUR node answer the same call?
eth_call · asked of our node
It must. We sell archive access, and this is the request that defines it.behaves as claimed
0x00000000000000000000000000000000000000000000000000011d4248558565
2026-08-04 16:21 UTC
unchanged since 2026-08-03 20:11 UTC
Is the debug namespace exposed?
debug_traceTransaction · asked of the chain’s public RPC
No.behaves as claimed
the method debug_traceTransaction does not exist/is not available
2026-08-04 16:21 UTC
unchanged since 2026-08-03 20:12 UTC
Does a priority fee buy anything?
eth_maxPriorityFeePerGas · asked of the chain’s public RPC
No. Ordering is strictly first-come-first-served.behaves as claimed
0x0
2026-08-04 16:21 UTC
unchanged since 2026-08-03 20:11 UTC
Is there a public mempool?
txpool_content · asked of the chain’s public RPC
No. Nothing is visible before sequencing.behaves as claimed
the method txpool_content does not exist/is not available
2026-08-04 16:21 UTC
unchanged since 2026-08-03 20:11 UTC

Each row is a claim about this chain beside the result of a request that settles it. Conditional probes state a condition that cannot hold, so the expected answer is a refusal — and a refused conditional is discarded before inclusion, which is why running this costs nothing unless something is wrong.

Findings

2 things this chain is documented to do and does not.

Each of these was found by a request, not by reading. They are listed here because the cost of not knowing them falls on whoever relied on the documentation, and that person is currently never told.

eth_sendRawTransactionConditional

Is a submission refused when it arrives after the block window closes?

Documented: Documented as enforced, alongside the other three.

Measured as NOT enforced: a transaction naming a maximum block a hundred blocks in the past is accepted and included. Anybody relying on this guard is relying on nothing, and would only find out from a transaction that landed when it should not have.

eth_call

Does the chain’s own public RPC answer a contract call five million blocks back?

Documented: Nothing says otherwise, and every library assumes a block tag works. Standard JSON-RPC accepts a historical block on eth_call and this endpoint accepts the argument without complaint.

It refuses, with "metadata is not found". Five million blocks is under a week on a chain this fast, so anything reconstructing last Tuesday — an indexer backfill, an audit, a liquidation post-mortem — hits this immediately, and finds out only when the job is already running.

Method

Why this costs nothing to run, and what that buys.

A probe that has to be paid for gets run once, written up, and never repeated — which is how documentation becomes stale in the first place. These are shaped so that the expected outcome is free.

Each conditional probe submits a real, signed transaction carrying a precondition that cannot hold — a storage root that was never that value, a block window that closed a hundred blocks ago. If the sequencer enforces the guard it refuses the submission before inclusion, and a refused conditional costs nothing at all. So a probe only ever spends gas when the chain fails to enforce something it claims to, which is precisely the case worth paying for.

The read-only probes cost nothing either way. Nearly all of them are put to the chain operator’s public RPC rather than to ours, because the question is what somebody gets when they use the endpoint they were given — and because our node refuses to accept transactions at all by configuration, so aiming a conditional at it would measure our own settings and call the result the sequencer’s behaviour. The one row aimed at our node is there to hold our archive claim to the same test as everybody else’s.

An unreachable endpoint is recorded as no answer and counted as neither agreement nor contradiction. It also cannot write to the change history: a bad hour at an RPC provider must never be published as “the chain stopped enforcing this, then started again”. On a page whose only claim is that it reports what it measured, inventing an event would be the one unforgivable bug.

What accumulates is the interesting part. Any single answer here is dull and repeats every half hour; the record of when an answer changed is what turns “this chain does not enforce that” into “this chain stopped enforcing that on a date” — a statement somebody can act on.

This measures behaviour, not intent
A guard that is not enforced is not evidence of anything but a gap between documentation and implementation, which is ordinary and common. What it is evidence against is building on the documentation without checking. Where a finding here changes what we tell customers, we change what we tell them — the bundle conditions table is driven by these same probes, and this page is why the advice on it was rewritten.