We built the challenge. We signed it. We are not allowed to send it.
Every other page here reports something we can do. This one reports the thing we cannot, and it does it the same way: by building the real transaction, putting it to the real contract on Ethereum, and printing what came back. The refusal is not our summary of the rollup’s rules — it is the rollup’s own words, in the same bytes anyone else can reproduce.
Deposit the stake that backs a rival claim. Losing a challenge forfeits it, which is what makes a challenge cost something to bring.
| asked as | what the rollup said |
|---|---|
0x69ec55952D9Abf922f57c1717fa92ba444e51858 our attester — signs every attestation, anchors the daily roots | NOT_VALIDATOR |
0x91af4aB115D19D42Cef1e5C6E63C4a0147230723 the key that signed the transaction below | NOT_VALIDATOR |
0xa0A1D8cd6f867a583a39232a477ff231aFD8eC4C the control — an address that is on the validator list | ALREADY_STAKED a different answer, and about the claim rather than the caller |
State a different end-state for the same range of blocks. This is the actual disagreement: same parent, same starting state, different claim about where the chain ended up.
| asked as | what the rollup said |
|---|---|
0x69ec55952D9Abf922f57c1717fa92ba444e51858 our attester — signs every attestation, anchors the daily roots | NOT_VALIDATOR |
0x91af4aB115D19D42Cef1e5C6E63C4a0147230723 the key that signed the transaction below | NOT_VALIDATOR |
0xa0A1D8cd6f867a583a39232a477ff231aFD8eC4C the control — an address that is on the validator list | EXPECTED_ASSERTION_SEEN a different answer, and about the claim rather than the caller |
Open the top-level edge of the bisection game between the two rival assertions. Everything after this is the two sides narrowing the disagreement.
| asked as | what the rollup said |
|---|---|
0x69ec55952D9Abf922f57c1717fa92ba444e51858 our attester — signs every attestation, anchors the daily roots | NotValidator(address) the error names the address it refused |
0x91af4aB115D19D42Cef1e5C6E63C4a0147230723 the key that signed the transaction below | NotValidator(address) the error names the address it refused |
0xa0A1D8cd6f867a583a39232a477ff231aFD8eC4C the control — an address that is on the validator list | EmptyEdgeSpecificProof() a different answer, and about the claim rather than the caller |
Halve the disputed range repeatedly until one machine instruction is in dispute, then execute that instruction on chain. Whoever is right wins; whoever is wrong loses the bond.
We do not build this. It needs the Arbitrum prover over the disputed range, which is a substantial piece of machinery we have not stood up. It is also unreachable: there is no challenge to bisect.
- disputes assertion
- 0x9b30edd7d5ace428ed0693777d739a0ddec0abefa31331f5b6928fdca587d0d7
- signed by
- 0x91af4aB115D19D42Cef1e5C6E63C4a0147230723
- transaction hash
- 0x0aa49cb64432f05e7006faefac95c77e9cc5cf60ef76544e789a5b12337591f2
- our claimed send root
- 0x95deb59243f05afb7ac622a325b775dd27667fc7819fd6049b9fcf77e33c5347
- rehearsed
- 2026-08-04 11:51 UTC
0x02f90330018083025990840c34ad18831e84809423a19d23e89166adedbdcb432518ab01e4272d9480b902c450f32f680000000000000000000000000000000000000000000000000de0b6b3a76400003ce60f5415d7ff9837cf31baed0b108cdc76151737504267fb04739df092c68de11fd5264340368fbf6bd8c6e6638976551aeb7980c5bec05ea57955a544cce9c10cd7ec6acaf1c441a3f6bd0900ad20f15855ba775a96f1939118cbc629dc970000000000000000000000000000000000000000000000000de0b6b3a76400000000000000000000000000006f38fc91105fc9a43931dca33450ab3315e3d4fa000000000000000000000000000000000000000000000000000000000000b2fa00000000000000000000000000000000000000000000000000000000000122168be6fc7d5fe53ad3a208bcb1923c9702c29d2500219003857f3e6767a93b00d695deb59243f05afb7ac622a325b775dd27667fc7819fd6049b9fcf77e33c534700000000000000000000000000000000000000000000000000000000000121e70000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000133d759cedea852452d79bb1ae29218ebff2752348bf066410ffc50ae3159a9e44b646cd7b80fa9b084a2b8dcbf1df2fce104060cfa433c0e11cb4a016536e6c095deb59243f05afb7ac622a325b775dd27667fc7819fd6049b9fcf77e33c5347000000000000000000000000000000000000000000000000000000000001221600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001e849be509c2885588184b5f48e7a586fb201a46be9b45bb6e01f16fbd1bd69ad9b30edd7d5ace428ed0693777d739a0ddec0abefa31331f5b6928fdca587d0d700000000000000000000000091af4ab115d19d42cef1e5c6e63c4a0147230723c080a0c49447042a7362cd13f5626092aca94e1b2835dfbe114289e8e3c3639ef9cef2a01416fb241055576add065f194578130758d2384efeeb9c1e6217ae353b408eaf
Recover the signer from those bytes and decode the calldata against the rollup at 0x23A19d…2D94. Nothing here has to be taken on our word.
The control is the experiment.
A refusal on its own establishes nothing. These two columns are what turn it into a measurement.
Each step sends identical calldata twice. Once as us, and once as an address that is already on the rollup’s validator list. If the refusals were the same, the cause would be the transaction — malformed, underfunded, badly encoded. They are not the same. We get NOT_VALIDATOR; the address on the list gets ALREADY_STAKED, then EXPECTED_ASSERTION_SEEN, then EmptyEdgeSpecificProof() — three complaints about the substance of what was submitted, which is what it looks like when a contract actually reads your transaction.
That ordering is the whole finding. The rollup checks who is calling before it looks at what they brought. However good the evidence, it is never reached. At the third step the contract does not even use a generic error: it reverts with NotValidator(address) and writes our address into the revert data, so the chain itself records which party it turned away.
Asking as another address costs nothing and takes nothing from them. eth_call is a hypothetical put to a node — no transaction, no signature, no state change. We are not acting as them; we are asking the contract what it would say if they asked.
Four things we will not let this page imply.
There is no discrepancy. We have checked every assertion this rollup has posted and found none wrong. The rival claim in the transaction above therefore states exactly what the operator stated — because we looked, and they were right. It is a challenge that would lose on its merits, and it never gets far enough for that to come up.
We did not broadcast it. Sending it would spend real ether on Ethereum to buy a revert reason that eth_call returns for free, and the receipt would say less than the paired probe above already does. The service that builds this has no code path that can send a transaction, and a test fails if one ever appears.
We do not build the proving step. Bisecting down to a single machine instruction needs a WAVM execution trace from the Arbitrum prover, which we have not stood up. Steps one to three are real and are put to the chain; step four is listed so you can see how far the road goes, and it is marked as not built. It is also moot — a road we are refused at the first gate is one whose fourth gate never arises.
This is not an accusation. A permissioned validator set is a normal stage for a young rollup and the operator has never hidden it. What is not normal is that nobody outside can check the claim, and that is the only thing this page changes.
A dated record of standing ready.
One screenshot of a revert is an anecdote and can be waved away as a misconfiguration at our end. A series of them, each with its signed transaction and its control run, is a fact about the chain.
2 addresses may propose or challenge state roots on this rollup, and both belong to the chain operator. So on the day a discrepancy does appear, the only parties permitted to dispute it are the party that posted it. That is the situation this rehearsal documents, every six hours, with a date attached.
The day the list opens, the argument is not that we would have been ready. It is that we were — here is the machinery, here are the dated refusals, and here is the transaction that only ever needed one thing changed: permission.
Until then, the Bond Vault holds a reserve against that day, and it is labelled a reserve because that is all it currently is.