-
Notifications
You must be signed in to change notification settings - Fork 208
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
batched undelegations #1195
batched undelegations #1195
Conversation
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.
looks good, ty for the detailed description
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.
LGTM, thank you for explaining new fields.
As the github alerts point out, this change to the protos means that this PR alone has some inconsistent types now -- like in icacallback_undelegate on line 48 it still refers to the old field called SplitDelegations instead of the new SplitUndelegation but I assume that these are fixed in the later PRs which actually update the callbacks
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.
Looks great, thanks a lot for doing this! Will drop more questions if they come up as I go through the other PRs, but this looks great
Context
Base PR for the batched undelegation work. This PR consists of only proto changes, but subsequent PR's will be merged into this before main.
Changelog
New Fields on HZU
Now that the StToken and NativeToken amounts are decremented in different places, I think it makes more sense to add explicit fields for each purpose. In this vein, I added the following:
NativeTokensToUnbond
StTokensToBurn
ClaimableNativeTokens
UndelegationTxsInProgress
New Status Field
Additionally, we need to differentiate EUR's that are in a retry state vs those that are new unbondings. For this, I added the new status field
UNBONDING_RETRY_QUEUE
Updated Callback Data
Finally, the callback data was updated to also store the number of stTokens. Given the fact that there's some precision error when breaking down a total stToken amount across validators, I think there are two options:
I opted for option 2 as it seems less error prone.