-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(staking): sort by publisher self-stake first #1997
feat(staking): sort by publisher self-stake first #1997
Conversation
@cprussin is attempting to deploy a commit to the Pyth Network Team on Vercel. A member of the Team first needs to authorize it. |
6905609
to
a46053e
Compare
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
if (a.poolCapacity === 0n && b.poolCapacity === 0n) { | ||
return 0; | ||
} else if (a.poolCapacity === 0n) { | ||
return 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a weird case here is that pools with 0 capacity always appear at the end no matter what. (whether it's inverse or not)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is weird because when you inverse a sort you expect the bottom of the first to be the top of the latter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it not okay to just return remainingPoolB - remainingPoolA
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah so this was actually intentional -- we had discussed just after launch and we basically never wanted to move drained pools to the top even if the sort was reversed to avoid people accidentally staking to an empty pool -- remember we were originally going to hide these entirely.
I'm cool with revisiting but I'd prefer to do it in a separate PR since this isn't anything new
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's also worth noting that sorting for pools that have zero capacity, or those that are over capacity, is not well defined in this sort.
This sort is specifically the amount of tokens remaining until the cap. In those cases, all such pools would be 0. So once you reach pools that have zero cap or are over-utilized, this sorting definition becomes nondeterministic.
As a result, reversing the sort order and adding these to the top is somewhat nonsensical.
We could revisit the definition of "sort by pool capacity" so that it isn't undefined in those cases but again I'd prefer to hold that for a separate change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think perhaps RemainingPool can be simplified
3686fa5
into
pyth-network:staking-app-release-batch
No description provided.