The poidh payout queue

poidh escrows a prize on chain and holds it until the issuer names a winner. Nothing expires: the contract has no deadline field, so a bounty with entries on it stays exactly where it is, indefinitely, until somebody sends a transaction. Right now 70 bounties are in that position, holding $4,025, and 1 of them has a vote in progress.

Most of this is not neglect. A bounty three days old with two entries is doing exactly what it should. That is why the table carries the age of the bounty and the age of its newest claim: 40 of these were posted 30 or more days ago, and that $1,995 is the part worth looking at.

There are two different payout calls, and picking the wrong one reverts

Which one an issuer needs depends on whether anyone else has ever put money into the bounty:

• Solo bounty (28 of the rows below) — the issuer funded it alone. acceptClaim(bountyId, claimId) pays out immediately.
• Open bounty (42 of the rows below) — somebody else contributed, so the contract requires a vote of the contributors. acceptClaim reverts with NotSoloBounty(). The issuer calls submitClaimForVote(bountyId, claimId), which starts a two-day window and counts the issuer's own stake as a yes; contributors call voteClaim; then anyone can call resolveVote(bountyId) once the deadline passes.

The flag the contract actually reads is everHadExternalContributor, and it is sticky: once an outside contributor has joined, the bounty needs a vote forever, even if that contributor later withdraws. poidh-app#1457 is my open pull request for the case where the web app reads a live participant count instead of that flag and offers the issuer a button that can only revert.

The queue

Method, and what this does not show

Every bounty id on all four chains was walked one at a time against the deployed contracts — bounties(id), then getClaimsByBountyId(id, 0), bountyCurrentVotingClaim(id) and everHadExternalContributor(id). A row is in the queue when all of the following hold: the prize is non-zero (so it has not been cancelled or already withdrawn), the winner address is still zero, and page 0 of the claim list decodes to at least one real claim.

• Claim counts stop at 10. getClaimsByBountyId returns a fixed page of ten and its offset argument does not advance (contracts #1441), so a count shown as 10+ is a floor, not a total.
• 0 bounties could not be read and are excluded from every number on this page rather than assumed empty. An earlier pass of this scan reported zero waiting bounties on Degen; that was a rate-limited RPC returning errors that the script counted as "no claims", and the corrected figure is 2. Because that failure mode is silent, the census was then re-walked end to end by a second script that classifies every id as read, reverting, settled or waiting and counts hard RPC errors separately: 739 ids, 0 hard errors, and the funded-and-unpaid counts reconcile against this table as candidates = shown here + have no claim on them at all (base 73 = 55 + 18; arbitrum 17 = 10 + 7; mainnet 5 = 3 + 2; degen 4 = 2 + 2).
• No deadline lives on chain. Several of these bounties state a closing date in their description text. The contract does not know about it and neither does this page, so a long age here is not by itself evidence that anything is wrong.
• poidh.xyz numbers bounties differently from the contract. The links above add a per-chain offset (base +986, arbitrum +180, mainnet +0, degen +0) to the on-chain id; the id column is the on-chain one. Each offset is checked by requiring the site's own record to report the same onChainId and the same title as the contract.
• The 2 Degen rows are not linked, because that check fails there. Asking the site for Degen id 137 returns something that calls itself onChainId: 137 and carries a different bounty's title from the one the contract at 0x18e5585ca7ce31b90bc8bb7aaf84152857ce243f returns — the same address the app's own config uses. I cannot tell you which side is wrong: Degen has exactly one reachable public RPC, so there is no second reading of that chain to break the tie, and a link would send you to a bounty that is not the one in the row. The amounts and claim counts in those two rows come from that single unconfirmed source and should be read that way.

Prices: ETH $2,453.26, DEGEN $0.001008, at build time. The raw scan is queue.json.