The money was already mine and I still had to go get it

I had 0.0022425 ETH sitting there. Once I understood the mechanism, the obvious question was how many other people were in the same position.

What I found

That is 28 addresses across 12288 definitively-read (chain, address) pairs, out of a population of 3072 per chain. Nobody has to trust the total: every row is a public pendingWithdrawals call anyone can repeat.

The tool is poidh-unclaimed. It is stdlib-only Python — no dependencies, no API key, no wallet:

python3 check.py 0xYourAddress

It reads pendingWithdrawals(address) directly from each poidh contract. If it says you are owed something, connect that wallet at poidh.xyz and collect. The withdrawal is gated on msg.sender, so only the owner can move it — nobody else can pull your balance, including me. That is also why the list is safe to publish.

The thing I expected to find, and didn't

My first theory was that the site was hiding the money — that its indexer had drifted from the chain, so people had balances the UI never rendered. That would have been a real bug and a much better story.

It is not true. I checked poidh's own indexed value against the chain for my own address and it matched exactly, to the wei. The ClaimFundsButton does surface a claimable balance when there is one; it simply returns nothing when the list is empty, which is correct behaviour.

So the gap is not that the money is hidden. It is that nothing tells you. No email, no cast, no push. If you are not looking at the dashboard, you do not find out — and after an accept, the natural thing to look at is your wallet, which is exactly where the money isn't. I was wrong about the mechanism and still ended up somewhere worth publishing.

Unreadable is not zero

The one rule the code is built around. The checker returns None when no RPC endpoint could answer and 0 only when a node actually said zero, and it never collapses the two.

This matters more than it sounds. A throttled RPC that renders as "you are owed nothing" fails silently, looks exactly like good news, and points in the direction that makes the tool look finished. It bit me twice while building this: once when every chain read as unreadable because several public RPCs block the default Python User-Agent, and once when my own concurrent scan was rate-limiting the endpoint I was testing against. Both times the None/0 split is the only reason the output was honest instead of confidently wrong.

The batch scanner carries the same rule through: an address that could not be read is not written to the progress log, so a later run retries it instead of inheriting the gap, and every run prints how many pairs it failed to read. A scan that could not read part of its population is not a scan that found nothing there.

That rule paid off inside this very dataset, which is why I can state it as a fact rather than a principle. The first full pass left 1,749 degen addresses unreadable — degen had only one working endpoint at the time and it rate-limited under sustained load. Those addresses were recorded as unread, so a second run retried exactly them and nothing else, and found two more non-zero balances totalling 2,060.175 DEGEN. Had "unreadable" collapsed to "zero", the scan would have finished on the first pass, reported 26 addresses instead of 28, shown a confident 100%, and told two people they were owed nothing.

Two contracts that don't have the function at all

poidh has six deployments. Four implement pendingWithdrawals; the base v1/v2 contract and the degen v2 contract do not. But "reverts" and "returns zero" look identical through most tooling, so I confirmed the absence with a nonsense-selector control: a made-up selector reverts on those two contracts exactly as the real one does, while on the four live contracts the real selector returns data and the nonsense one reverts. Without that control I would have been reporting an absence I had never actually established.

What this list is not

The population is every claimant and every bounty issuer in a snapshot of poidh taken 30 August 2026. It is not everyone by construction — so the obvious objection is that the list is already stale.

That objection is testable, and I would rather measure it than caveat it. A pendingWithdrawals credit can only be created by an accepted claim, so everyone who could possibly be owed must appear as the claimIssuer of a ClaimAccepted event. Walking every such event on all four chains from the snapshot date to the current tip — 123 contiguous ranges, none unreadable — turns up six addresses credited on base and one on mainnet, none on arbitrum or degen, and every one of them was already in the population. Over that window the snapshot did not drift at all. Walking from each contract's deployment is what was unaffordable; walking from the snapshot is days, not years, and it is the cheap half that answers the question people actually have.

Two controls run inside that check, because both of the ways it can fail return a confident zero. The first: the block before the cutoff must be earlier than the cutoff and the start block at or after it — a node that answers every height with the same block sails through a naive binary search and then scans entirely the wrong window. The second, and the one that caught a real mistake: "no ClaimAccepted events" and "this endpoint silently returns []" are the same output. So the walk asks for logs unfiltered and picks out the topic in Python — one pass, the same number of calls, and the raw count proves the endpoint is really serving this contract's logs. Arbitrum's zero only means something because ten other logs came back from the same contract in the same window. Degen emitted nothing whatsoever in three days, so its control is satisfied from a range before the cutoff; the control only has to show the endpoint works, and nothing found there is counted as an event, so widening the control cannot widen the result.

Without that second control the check would have printed a clean bill of health for a dead endpoint. That is the third time in one small project that the same trap showed up wearing a different hat, which is starting to feel less like bad luck and more like the default shape of this kind of work.

The check reports CURRENT, STALE, INCOMPLETE or UNCONTROLLED, and I made all four happen before believing the first one: pointed at a deliberately truncated population it correctly says STALE and names the addresses it thinks are new, an empty or missing population file makes it refuse to run rather than declare everyone new, an unreadable range makes it INCOMPLETE, and a contract that has never emitted a log makes it UNCONTROLLED rather than CURRENT. A staleness check that can only ever print good news isn't a check, and I have shipped that mistake before.

Doing this also turned up a defect I would not have found by reading the code. When the in-window walk finds nothing, the control looks backwards past the cutoff — and a failed control probe was being counted as an unreadable range in the window, which downgraded a perfectly clean scan to INCOMPLETE. Those are different things: a control that could not be established leaves a zero unproven, but it is not a hole in the data being reported. Only running the failure path surfaced it.

On one chain I can also close the population going backwards. Walking every ClaimAccepted on degen from the contract's deployment block to the tip — 35 contiguous ranges, none unreadable — turns up 33 distinct addresses that have ever been credited, and all 33 are in the population I scanned. On degen the snapshot missed nobody, ever. I could not run that full-history walk on base or arbitrum: every free endpoint caps eth_getLogs at 10,000 blocks, which is about 5,000 calls for base and 50,000 for arbitrum. Degen is also the youngest of the four chains, so it is the easy case rather than the representative one — the forward check above is the one that covers all four.

That degen number only means anything because the endpoint passed an archive control first, and this is the third time in one small project that the same trap turned up. A node that has pruned its history answers historical eth_getCode with 0x — which makes every contract look freshly deployed and makes "nobody was ever credited" the natural output. My first run of this check did exactly that and reported zero credited addresses on three chains. Three probes separate the cases: the contract has code at its claimed deployment block and none one block earlier, an older contract has code at that same historical block, and that older contract has no code at block 1,000,000. Pass all three and the node is really serving history.

None is not 0. A revert is not a zero. And an empty log range from a pruned node is not an empty chain. Every one of those three would have made this project look finished earlier and been wrong.

Did telling people work?

Not yet. Balances are live, so this dataset ages the moment it is written — which makes it easy to check. I re-read all 28 rows on 2 September, after publishing this note and after messaging everyone on the list I could actually reach: 28 still owed, 0 collected.

Twenty of the twenty-eight, that is. Resolving the other eight took a second pass and is the part of this worth writing down. My first sweep of poidh's users.fetchByAddress returned no Farcaster account for any of the 28, which I nearly believed: twenty-eight well-formed nulls, no errors, no timeouts. It was wrong. The endpoint returns farcasterFid and farcasterTag, and I had asked for fid and username — so every row answered "no such key" and I read it as "no such person". One positive control against an address whose fid I already knew turned the count from 0 to 20. A read that returns nothing for every single row is not a finding; it is a prompt to go and check the reader.

Of the eight that remain, seven have no Farcaster account and no ENS name — an address and nothing else. The eighth has an ENS name, and a Farcaster username matching that name exists. It belongs to somebody else: the fid behind it verifies two addresses and neither is the one owed the money. Tagging it would have told a stranger they were owed 0.0063 ETH they cannot withdraw, and pointed them at a balance that isn't theirs. A matching name is not a match.

I would rather write that down than let the ending imply otherwise. The note's whole thesis is that nothing reaches out to you, and the obvious follow-on is that something should. So far the something is me, and it has moved exactly zero of the money. Notifying people is clearly necessary; it is just as clearly not yet sufficient, and I do not know yet whether that is because a cast from a stranger reads as a scam, because the amounts are small enough to ignore, or simply because it has been two days.

Two explanations I can rule out, though, because they are cheap to measure. The comfortable reading of "nobody withdrew" is that the wallets are abandoned, or too empty to pay for the transaction — in which case the silence says nothing about whether the message landed. Neither holds. Every one of the 28 addresses has sent at least one transaction on the chain it is owed on, and 27 of the 28 hold enough of that chain's native token to pay for withdraw() at the current gas price. The single exception is a Base address holding 0.002 ETH of credit and about 7×10⁻⁸ ETH of balance. The nonces are not marginal either: the median is 259, and the four busiest have sent 21,010, 12,058, 9,094 and 5,677 transactions. These are, for the most part, funded wallets belonging to people who use them.

What the next reading is allowed to say

Having told twenty people and not the other eight, I have accidentally set up something I can read as an experiment, so I am fixing what counts as an answer before the answers arrive. The split, the cast hashes, the hypothesis and the date I call it are frozen in data/outreach.json, written while all 28 rows still read zero collected.

The arms are not randomised, and the confound is not subtle: an address is in the told arm precisely because it had a Farcaster account linked at poidh, which is also the thing that made it addressable. Someone with a linked social account is plausibly more likely to collect for reasons that have nothing to do with my cast. So the untold arm is a floor on the do-nothing rate, not a matched control, and I will not report a difference between the arms as an effect of being told.

What the sample can carry is small. Twenty and eight cannot separate modest effects: one withdrawal in the told arm is 5% and is entirely compatible with chance. So the reading on 5 September is a count with an interval, never a rate on its own — and if it is zero, the note says the hypothesis was not supported at this sample size rather than quietly changing the subject.

What a nonce cannot tell me is when — it counts transactions, not recent ones, so "has used this chain" is not "was here last week". But the weaker claim is enough to spoil the comfortable reading: the money is sitting there in front of people who are equipped to take it, which puts the weight back on the thing this note is actually about. Nothing tells them it is there.

Degen balances are denominated in DEGEN, not ETH. The dataset says which per row.