Unable to delegate multiple times on vesting account #8812
Comments
|
Kudos for being a good steward of decentralization on the hub by supporting multiple validators! I'm curious of this is a regression or a bug in creating of new vesting accounts on a live chain? IIRC, delegating to multiple validators wasn't an issue with the genesis vesting accounts on hub-1. |
|
No idea, didn't use vesting accounts on previous versions. Note that it's not so much a problem with delegating to multiple validators, as it is a bug in fee payments when a vesting account has a delegation. If I understand this correctly, any vesting account that has delegated a larger amount of ATOM than the amount of free (non-locked/vested) ATOMs will be unable to pay fees for any transaction, including sending ATOMs and claiming rewards. In the example above, with 100 out of 300 vested ATOMs delegated, all fee payments will panic until I transfer 100 additional "free" (unvested) ATOMs into the account such that the amount of free ATOMs is greater than the amount of delegated ATOMs. |
|
Hmm... this seems concerning, adding it to the backlog. |
|
Removing from the v0.42.0 as this is not a PR and it's a bit late to include a fix in v0.42.0 anyways. But it'd be great to see a patch coming through 🙏 |
|
Agreed with @alexanderbez that this is a regression. I was able to stake to multiple validators with my previous account. |
This is certainly not how it used to be, nor how the vesting account was originally designed. The vesting account was designed to first delegate its vesting atoms before trying to delegate any free atoms. So in the case where you have 400 vesting atoms and 100 free atoms, and you choose to delegate 300 atoms. You will have 300 vesting delegated atoms, 100 vesting undelegated atoms, and 100 free atoms. If you choose to vest 450 atoms, you will still have 50 free atoms left. I would look to see if that logic has changed at all. |
|
Yeah, when I skimmed the code over the weekend it seemed like it calculated the available amount to use for fees like: available = balance - locked However, locked did not take into account the delegated amount (possibly due to #8601), so in my previous example it would use locked=300 (the total vested amount), but balance=200 (the undelegated amount remaining in the account). So 200-300=-100 → panic. |
On a |
|
I was not able to reproduce this on I delegated to two validators from both a Maybe we need to try delegating to a second validator w/ fees > spendable coins. I would recommend someone from the SDK picking it up from here. If that is an issue and is reproducible, I would say this has nothing to do with vesting accounts. |
|
I am experiencing the same issue on our chain and we are based on v0.42.1 This issue seems to affect all vesting accont types. In my scenario I am using Taking a quick glanace of the code that panic, my speculation is the same as @erikgrinaker
Once an account got into this state, no transactions (including unbonding) could go through and this account is in a "locked" state. One have to wait until the the token are vested before it can resume funds operations. Steps to Reproduce
|
… vesting accounts (#8865) Delegations and undelegations calculations performed during accounting operations for vesting accounts were correct but were not written back to the account store. closes: #8601 closes: #8812 Co-authored-by: Alessio Treglia <alessio@tendermint.com> Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com> Co-authored-by: Jonathan Gimeno <jgimeno@gmail.com> Co-authored-by: Frojdi Dymylja <frojdi.dymylja@gmail.com> Co-authored-by: Adam Bozanich <adam.boz@gmail.com> Co-authored-by: Amaury <1293565+amaurym@users.noreply.github.com> Co-authored-by: SaReN <sahithnarahari@gmail.com>
Summary of Bug
I have a
ContinuousVestingAccountoncosmoshub-4with some vested ATOMs in it, as well as 1 free ATOM for fees. I wanted to delegate this to three validators in equal parts. After delegating to the first, all subsequent operations (delegations, claiming rewards, etc) return a panic via RPC:After spinning up a full node and outputting the redacted panic I get this:
I suspect it doesn't take the already-delegated amount into consideration, such that the code sees the full vested amount as locked, tries to subtract that from my balance (which is now 2/3 of the vested amount), and panics because the remainder is negative.
This may be related to #8601.
Version
Gaia 4.0.4
Steps to Reproduce
Create a
ContinuousVestingAccountwith 300 vested ATOM (not sure how this is done), and send 1 free ATOM for fees.Delegate 100 ATOM to validator A:
panic message redacted to hide potentially sensitive system info: panicFor Admin Use
The text was updated successfully, but these errors were encountered: