The default ranking algorithm on hive.blog and peakd.com actually already account for this, as you can see if you look at d.buzz community on hive.blog or peakd.com.
Edit: misunderstood the first part of your comment. Filters are good in general, but I don't think they need to default filter based on the cap, because many users will have legitimate reasons to raise their cap (high effort posts, for example).
I think but can't say for certain that the curators end up splitting a smaller curation reward if the post exceeds the cap. I think basically all curators get cut in the same way. Curators will thus need to be more careful about how they vote, but IMO that is a positive thing. Lazy voting and auto voting should be discouraged. There will still be just as much curation rewards up for grabs as before, it will just take greater care to get your max rewards.
My understanding is that the excess remains in the pool.
But if what you’re saying is true, that all curators get cut equally, then voting on such a post risks that some lazy voter after me will over vote and cost me an unknown (and perhaps large) portion of my curation rewards.
It looks like it does work that way. Aside from the one late voter, and some smaller votes that might be affected by rounding errors, everyone got the same rewards per rshare.
It's not ideal, because it does mean there's a risk of getting a lower reward per rshare when you vote on a post with a cap as opposed to an uncapped or very highly capped post.
There are ways to fix this but it goes straight back into hard fork territory 😕
Edit: A not too complex fix is to use current curation reward logic but apply rewards on a first-vote-first-paid basis. Thus only late voters are penalized when there is a cap. It's still a hard fork.
I will try and double check if my understanding is correct. I have an example here of one of my buzz's that would have gone over the cap, later in the day I'll look into it to see how it worked out for curators.
https://hiveblocks.com/hive-193084/@demotruk/1f7uq9p6yx7anq7ln61xgp
@trostparadox pointed out an issue we noticed in 2020/2021
We were interested in a change at the blockchain level that switched the algorithm for max-accepted-payout settings to burn author rewards above the max instead harming curators
@dbuzz may submit a PR for this. #HiveCore
Posted via D.Buzz