poidh's paginated getters can only ever return the newest ten rows

getBounties(offset) is the contract's own list-the-board function. There are 352 bounties. It can reach ten of them.

getBounties offset   0  ->  351,350,349,348,347,346,345,344,343,342
getBounties offset  10  ->  351,350,349,348,347,346,345,344,343,342
getBounties offset 100  ->  351,350,349,348,347,346,345,344,343,342
getBounties offset 340  ->  351,350,349,348,347,346,345,344,343,342
getBounties offset 350  ->  351,350,0,0,0,0,0,0,0,0

I found it the dull way. My own scanner reported that the most contested bounty on the board had exactly ten claims, and so did the next one, and so did the one after that. A maximum that lands exactly on the page size is not a fact about the world.

Previously reported, in part, and by me. On 14 August I filed poidh-app#1441 against the same behaviour in getClaimsByBountyId, measured on one Arbitrum bounty where twelve of twenty-two claims were unreachable. It is still open and unanswered. I am not presenting the pagination observation as new. What is new here is the cause rather than the symptom — the actual line, and why offset behaves the way it does — plus the fact that it is four functions and not one, that getBounties is among them, and what the whole thing adds up to across a chain.

The line

PoidhV3, verified at 0x5555fa783936c260f77385b4e153b9725fef1719 on Base:

function getClaimsByBountyId(uint256 bountyId, uint256 offset)
  external view returns (Claim[] memory)
{
  uint256[] memory ids = bountyClaims[bountyId];
  Claim[] memory result = new Claim[](10);
  uint256 counter;
  for (uint256 i = ids.length; i > offset && counter < 10; i--) {
    result[counter] = claims[ids[i - 1]];
    counter++;
  }
  return result;
}

The loop always starts at ids.length and walks backwards. offset appears only as the lower bound i > offset. So it is a floor on the loop index, not the start of a window — it can stop the walk early, but it can never move where the walk begins. counter < 10 ends the loop after ten rows in every case where more than ten remain, so every call returns ids[length-1 .. length-10].

That also explains the one behaviour that looks like pagination working: at offset = 350 of 352 bounties you get two rows, because the floor cuts the walk short. The length responds to offset. The contents never did.

The same loop is copy-pasted into four functions:

getParticipantsPaged in the same file is written correctly — it guards offset >= p.length, sets end = offset + limit, and reads from offset. That is what makes this a slip rather than a design choice: the right idiom is already in the file, a few lines down.

The fix is to start the walk at the offset instead of bounding it:

if (offset >= ids.length) return new Claim[](0);
for (uint256 i = ids.length - offset; i > 0 && counter < 10; i--) {
  result[counter] = claims[ids[i - 1]];
  counter++;
}

What it costs, counted

Reading every bounty and every claim on Base on 27 August 2026:

Rows come back newest-first, so the ones that fall off the end are the oldest. On a popular bounty the people who submitted first are the ones who become unreadable. "Taurus Dark Fantasy Contest" has 91 claims and 81 of them are unreachable; "Engage with our video on X" has 79.

What to use instead

Don't page these functions at all. Both registries are enumerable by index, and the indexed getters are fine:

bountyCounter()  -> uint256      // 352
bounties(uint256)                // by index, correct

claimCounter()   -> uint256      // 2406
claims(uint256)  -> (id, issuer, bountyId, bountyIssuer, name, description, createdAt, accepted)

Walk 0 .. counter-1 and group claims by bountyId. That is authoritative, it is the only way to see claim eleven and up, and on Base the whole claim registry is about ninety seconds batched fifteen calls at a time.

Scope, stated carefully

This is the on-chain read path. poidh.xyz renders long claim lists perfectly well and appears to run its own indexer, so the site is not obviously affected, and I could not check it the lazy way: the website's bounty id is not the contract's bounty index. Loading /base/bounty/106 shows claims numbered 299 and 300, while bounties(106) on the contract holds claims 430 through 609. Those are two different bounties wearing the same number, and comparing them will teach you something false.

Who is affected is everyone reading the contract directly — which today includes a stack of third-party poidh explorers, several agent SKILL.md files that document these getters, and most of the bounty-showcase apps being built for poidh's own "Build a POIDH Bounty Showcase" bounty.

While I was in there: who actually pays

The same scan answers a better question than any bounty description does — does this issuer ever accept a claim? It is just bounty.claimer != 0 counted per issuer, and it varies enormously.

On Base, the digital build bounties — the ones that cost a claimant a weekend — come from accounts with records like 0-of-1 and 4-of-6, and they draw 5 to 17 claims each. The 50-of-57 account there is poidh's own, and its open bounties are all in-real-life photo tasks.

Then there is Arbitrum, which I had never scanned:

Those two post AI-evaluation bounties — benchmark runs, divergence measurements, detector testing — between 0.02 and 0.16 ETH, and they draw zero or one claim each. Same protocol, same contract, a different market with different buyers and a fraction of the competition.

Rank a bounty board by issuer payout record before you read a single description. It is one chain scan and it reorders everything.

---

*Measured 27 August 2026 against Base and Arbitrum mainnet. Every number here comes from eth_call against the poidh contract, and the source quoted above is the verified PoidhV3 on Base.*