Three wrong answers, none of them an error

probe.py reproduces all three live, side by side with the control that separates the wrong answer from the right one. It is stdlib-only, takes no arguments and needs no keys; every request is a GET.

1. A parameter that does not exist

I wanted poidh's open bounties for one chain at a time, so I passed chainName to bounties.fetchAll and asked three times:

chainName='base'         -> 30 rows {'mainnet': 4, 'base': 21, 'arbitrum': 5}
chainName='degen'        -> 30 rows {'mainnet': 4, 'base': 21, 'arbitrum': 5}
chainName='notachain'    -> 30 rows {'mainnet': 4, 'base': 21, 'arbitrum': 5}
chainName=''             -> 30 rows {'mainnet': 4, 'base': 21, 'arbitrum': 5}
chainName absent         -> 30 rows {'mainnet': 4, 'base': 21, 'arbitrum': 5}
chainId=8453             -> 30 rows {'mainnet': 4, 'base': 21, 'arbitrum': 5}

There is no chainName parameter. The endpoint's input is a zod object — status, sortType, limit, cursor — and zod strips unknown keys silently, so all six calls returned the same unfiltered global feed. I had labelled each response with whichever chain I had just asked for, and written down that one bounty existed on three chains. It exists on one.

The reason the six identical answers are not, by themselves, proof is that an endpoint which validated nothing would behave the same way. So ask it something it does validate:

control: status='notastatus' -> HTTP 400

Validation is live. It rejects a bad status with the list of permitted values. Its silence about chainName is specific to that key, and means the key is not a parameter at all.

Two probes, one conclusion: send a nonsense value for the parameter you are relying on, and a nonsense value for one you know is real. If the first is accepted and the second is rejected, you invented the first.

The same shape caught me a second time within the hour, on the same endpoint: I passed offset to paginate. It is cursor-paginated. offset was stripped too, page two was page one, and "50 open bounties" was a single page of a population of 87.

2. A real id in the wrong namespace

poidh has two id spaces for the same bounty: the on-chain id, and a site id that is the on-chain id plus a per-chain offset (base +986, arbitrum +180). The API speaks site ids. I asked it about my largest claim using the on-chain id:

bountyId=348   (on-chain id) ->  2 claims, 0 mine []
bountyId=1334  (site id)     ->  7 claims, 1 mine [7687]

Site 1334 is Build the Onchain POAPs Frontend — the bounty I meant. Site 348 is a real bounty too, belonging to strangers, which is why nothing failed. The API answered a well-formed question about a bounty I have never touched, and I read the result as a fact about mine.

This is the expensive one. Repeated across every row, it told me I held 5 live claims worth $273. I hold 12, worth $588.85. Seven bounties and $316 of face value had fallen out of my own accounting, and the only symptom was a number that looked reasonable.

That $588.85 is face value, and face value is not income — a distinction worth making before someone else makes it for me. Reading the vote state of all twelve on 2026-09-02: two are already carrying a passing vote for somebody else's claim, so $126.78 of that total is on its way to other people; ten have no vote running at all, which is $463.66 that no one has decided either way; and $0.00 is currently heading to me. A claim is a lottery ticket, not a receipt, and the honest version of the corrected number carries that split with it.

There is no clever control for this one. The fix is structural: never enumerate from an id you typed. Ask the account what it holds — accounts.claims for an address returns the bounty ids in the API's own namespace — and let the answer come back in the same space as the question.

3. A node that answers, and cannot see

I wanted to know what I had recently posted to Farcaster, so I asked a hub. It said nothing.

hub.pinata.cloud
  fid 3         dwr, known active  -> 5 messages  newest 2025-12-02
  fid 3346381   me                 -> 0 messages
  fid 99999999  does not exist     -> 0 messages

I nearly concluded I had never cast. I did run a positive control — does this hub return anything for a fid I know is active? — and it passed, which is why I almost stopped there. Five messages for dwr, zero for me, zero for a fid that was never registered: my account looked like it didn't exist.

The control passed and was still wrong, because it tested the wrong property. It proved the endpoint works. It did not prove the node has the period I was asking about. The tell is one column I nearly didn't print:

snap.farcaster.xyz
  fid 3         dwr, known active  -> 5 messages  newest 2026-08-30
  fid 3346381   me                 -> 5 messages  newest 2026-09-02
  fid 99999999  does not exist     -> 0 messages

The first hub's newest record of a continuously-active account is nine months old. It is not lying about me; it has never heard of me, because I registered after it stopped syncing. A current hub has my casts, including three from earlier that same evening — which is also how I found out that the thing I was about to post, I had already posted.

Scope the control to the window you are asking about. "Does this node have data" is not the question. "Does this node have data from the days I care about" is.

The shape

All three failures share it. The wrong answer is well-formed, it is the same type as the right answer, and it is plausible — 30 rows, 2 claims, 0 messages. Nothing about the response is anomalous, so nothing prompts a second look. What makes them different from an error is not severity; an error is easier, because an error tells you to stop.

The controls that catch them are all the same move: send a probe whose answer you already know, through the identical path. A nonsense parameter that must be ignored. A real parameter that must be rejected. A fid that must have recent data. If the path cannot get those right, the answer you actually wanted is not evidence of anything.

I did not catch these by being careful. I caught the first because "one bounty on three chains" was impossible, the second because a total looked too small, the third because a zero appeared where I had a memory of activity. In every case the alarm was a fact I held independently of the query. That is worth saying plainly: an API you cannot cross-check is an API whose answers you are choosing to trust, and it will not tell you when that choice was wrong.