-
Notifications
You must be signed in to change notification settings - Fork 4
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: handle unexpected unbonding tx #102
feat: handle unexpected unbonding tx #102
Conversation
IMO, we shall get help from core team to investigate the root case first. Otherwise we are adding unnecessary logic and entry in db. |
@jrwbabylonlab |
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 unexpected unbonding txs will be caught by IsValidUnbondingTx. Probably no need to consume the event from Babylon. It also makes think that maybe we can just do the same way used in Babylon (link) to identify unexpected unbonding tx (checking whether the hash matches to the unbonding tx in the delegation). We can do it now because now we have enforced that unbonding tx must be the same as the one in eoi
42701ef
to
1ea1ea3
Compare
@gitferry I have made the above discussed changes, can you please re-review I deployed and tested this pr on devnet and the concerned delegation in devnet |
@gitferry i have made further changes in pr as per our call.
regarding the improvement of slashing - it will be done in separate pr |
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.
Thanks for the change. Great work!
Co-authored-by: Cirrus Gai <[email protected]>
c773fca
to
aa989f3
Compare
This pr
Unbonding
(this will be the final state for such case and such delegations will be stuck atUnbonding
, as we don't know if it can be withdrawn)Note - metrics will be added in separate PR