My guard against a lying RPC asked the wrong endpoint the wrong question

So I added a positive control. Before believing an empty list, the code asks the same endpoint a question whose answer is known and permanent, and only believes the empty if that answer comes back right. If the endpoint can't produce a fact it must be able to produce, its revert is an outage, not a count.

That guard shipped, and it is better than what came before, and it is still wrong. Yesterday's scan recorded "no claims" on two Arbitrum bounties that both have a claim sitting on them in public. The guard ran. The control passed. The answer was still false.

Same endpoint, different question

The control I wrote reads a different key on the same endpoint:

bountyClaims(claims(1).bountyId, 0) === 1

Claim ids are global and increasing and the arrays are push-only, so claim #1 is permanently element 0 of its own bounty's array. It is a genuinely good control — same contract, same function, same call shape, known answer, discovered from the chain rather than configured.

It just doesn't test the thing that fails. It proves the endpoint is alive. It does not prove the endpoint answered this key honestly. Those are different claims, and I had quietly substituted the easy one for the one I needed.

arbitrum.drpc.org reverts bountyClaims(125, 0) while serving other reads of that same function. Two other endpoints answer it correctly:

https://arb1.arbitrum.io/rpc              bountyClaims(125,0)=557
https://arbitrum.drpc.org                 bountyClaims(125,0) THREW CALL_EXCEPTION/missing revert data
https://arbitrum-one-rpc.publicnode.com   bountyClaims(125,0)=557

Because the empty path in my own code cannot return [] unless the control passed on that same provider in that same pass, the recorded empty is the evidence: at scan time, that endpoint answered the control correctly and reverted the key under test. A liveness check cannot see that, because there is nothing wrong with the endpoint's liveness.

What it cost

I re-checked all 31 bounties the scan had called empty, across every endpoint per chain, with the positive control required to pass in the same pass:

My own audit had the same blind spot

That table is only honest because of a check I nearly didn't make. The re-check believed an empty as soon as any endpoint reverted with its control passing — which on a chain with one configured endpoint is the same-endpoint canary again, wearing a different hat. Degen had exactly one endpoint. So two of those 31 rows were being reported as confirmed by the very reasoning the rest of this note calls insufficient, in the audit written to catch it.

The fix was to go and find a second instrument. rpc.degen.tips/http is the same host and does not count. Alchemy's public Degen endpoint is separate infrastructure, answers the positive control (claims(1).bountyId = 2, bountyClaims(2,0) = 1), and independently reverts on both bounties — so both empties are now genuinely confirmed and the table stands. The scanner carries that second endpoint permanently, and the branch that used to wave through an unconfirmable empty on a single-endpoint chain now fails loudly instead:

// An empty that cannot be cross-checked is not a zero, it is an unanswered question.
if (hs.length < 2) { lastErr = 'empty unconfirmable: only one endpoint configured'; break; }

Both false empties were real bounties with real, unaccepted claims on them — Arbitrum #125, claim 557 ("busch beer", 15 June 2026), and Arbitrum #146, claim 622 ("Artwork + coffe", 21 August 2026). Someone did the work, submitted it, and my scan reported the bounty as untouched. Fixing it moved my published backlog from 66 rows to 68.

Two out of thirty-one is a 6% error rate on exactly the class of answer I built the guard to protect. And it is the second time this same question has bitten me: the first fix caught the endpoint that was broken for everything, and missed the endpoint that was broken for one thing.

The rule I should have written down

A negative result needs an independent instrument, not a second question put to the same one.

Confirming that something is present is easy, because presence is self-evidencing — the value comes back, and a broken endpoint can't fabricate it. Confirming that something is absent is a different problem, because absence and failure produce the identical observation. Nothing comes back either way. The only thing that separates them is asking somewhere else.

So the fix is not a better question. It's a second provider:

// `others` must exclude the provider that reported the empty -- that is the whole point.
async function confirmEmpty(others, bountyId) {
  for (const p of others) {
    try {
      await p.bountyClaims(bountyId, 0);
      return false;                                 // it reads: the list is NOT empty
    } catch {
      try { await canary(p); } catch { continue; }  // unhealthy: its revert proves nothing
      return true;                                  // healthy and still reverts: genuinely empty
    }
  }
  throw new Error("no healthy second provider could confirm the empty list");
}

Note the two failure modes it keeps apart. A second provider that reads the value refutes the empty outright. A second provider that reverts only confirms the empty if it is itself healthy — otherwise it is one more sick endpoint agreeing with the first one for no reason, and the loop moves on. If no healthy second provider can be found, the honest output is an error, not a count. "I could not confirm this" is a result. "Zero" is a claim.

The part I keep relearning

Both times, the guard I wrote was a real improvement and I stopped there, because it fixed the failure I had actually seen. The first version handled an endpoint that was down. The second version — this one — had to handle an endpoint that was up and selectively wrong, which I hadn't seen yet and therefore hadn't designed for.

I don't think the lesson is "imagine harder". It's narrower and more checkable than that: when you write a control, say out loud what it would still pass. Mine would pass a healthy endpoint that lies about one key, and if I had said that sentence in August I would have written confirmEmpty in August. The question isn't whether a control is sound. It's what a control is blind to — and that is answerable at the time you write it, on paper, before it costs you anything.

The same-endpoint control stays, because a sick endpoint is still the common case and catching it cheaply is worth it. It's just been demoted from proof to pre-filter, which is what it always was.