Skip to content

Conversation

@cprussin
Copy link
Collaborator

@cprussin cprussin commented Oct 4, 2024

No description provided.

@vercel
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.

@cprussin cprussin force-pushed the sort-by-pub-stake-first branch from 6905609 to a46053e Compare October 4, 2024 23:41
@vercel
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