Skip to content
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

Conversation

cprussin
Copy link
Collaborator

@cprussin cprussin commented Oct 4, 2024

No description provided.

Copy link

vercel bot commented Oct 4, 2024

@cprussin is attempting to deploy a commit to the Pyth Network Team on Vercel.

A member of the Team first needs to authorize it.

Copy link

vercel bot commented Oct 4, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
api-reference ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 4, 2024 11:53pm
staking ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 4, 2024 11:53pm
1 Skipped Deployment
Name Status Preview Comments Updated (UTC)
proposals ⬜️ Ignored (Inspect) Visit Preview Oct 4, 2024 11:53pm

if (a.poolCapacity === 0n && b.poolCapacity === 0n) {
return 0;
} else if (a.poolCapacity === 0n) {
return 1;
Copy link
Contributor

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)

Copy link
Contributor

@guibescos guibescos Oct 7, 2024

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

Copy link
Contributor

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

Copy link
Collaborator Author

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

Copy link
Collaborator Author

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.

Copy link
Contributor

@guibescos guibescos left a 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

@cprussin cprussin changed the base branch from main to staking-app-release-batch October 8, 2024 15:45
@cprussin cprussin merged commit 3686fa5 into pyth-network:staking-app-release-batch Oct 8, 2024
6 checks passed
@cprussin cprussin deleted the sort-by-pub-stake-first branch October 8, 2024 15:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants