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

docs(x/accounts/defaults/lockup): Add slash document for lockup account #22783

Merged
merged 4 commits into from
Dec 6, 2024
Merged
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 25 additions & 1 deletion x/accounts/defaults/lockup/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@
* [PeriodicLockup](#periodiclockup)
* [PermanentLocked](#permanentlocked)
* [Genesis Initialization](#genesis-initialization)
* [In An Event Of Slashing](#in-an-event-of-slashing)
* [Examples](#examples)
* [Simple](#simple)
* [Slashing](#slashing)
Expand Down Expand Up @@ -108,6 +109,29 @@ type PermanentLockingAccount struct {

<!-- TODO: once implemented -->

## In An Event Of Slashing

As defined, base lockup store `DelegatedLocking` by amount. In an event of a validator that the lockup account delegate to is slash which affect the actual delegation amount, this will leave the `DelegatedLocking` have an excess amount even if user undelegate all of the
account delegated amount. This excess amount would affect the spendable amount, further details are as below:

Spendable amount are calculated as
`spendableAmount` = `balance` - `notBondedLockedAmout`
Whereas `notBondedLockedAmout` = `lockedAmount` - `Min(LockedAmount, DelegatedLockedAmount)`

As seen in the formula `notBondedLockedAmout` can only be 0 or a positive value when `DelegatedLockedAmount` < `LockedAmount`. Let call `NewDelegatedLockedAmount` is the `delegatedLockedAmount` when applying N slash

1. Case 1: where originally `DelegatedLockedAmount` > `lockedAmount` but when applying the slash amount the `NewDelegatedLockedAmount` < `lockedAmount` then
* When not applying slash `notBondedLockedAmout` will be 0
* When apply slash `notBondedLockedAmout` will be `lockedAmount` - `NewDelegatedLockedAmount` = a positive amount
2. Case 2: where originally `DelegatedLockedAmount` < `lockedAmount` when applying the slash amount the `NewDelegatedLockedAmount` < `lockedAmount` then
* When not applying slash `lockedAmount` - `DelegatedLockedAmount`
* When apply slash `notBondedLockedAmout` will be `lockedAmount` - `NewDelegatedLockedAmount` = `lockedAmount` - `(DelegatedLockedAmount - N)` = `lockedAmount` - `DelegatedLockedAmount` + N
3. Case 3: where originally `DelegatedLockedAmount` > `lockedAmount` when applying the slash amount still the `NewDelegatedLockedAmount` > `lockedAmount` then `notBondedLockedAmout` will be 0 applying slash or not

In the 3 cases, case 1 and case 2 seen the `notBondedLockedAmout` decrease when not applying the slash, makes the `spendableAmount` higher.

Due to the nature of x/accounts, as other modules cannot assume certain account types exist so the handling of slashing event would have to be done internally inside x/accounts's accounts which in the case of lockup account would make the logic over complicated. As the above effects are only an edge case that affect a small number of users, so here we would accept the trade off for a simpler design. The same design intention is also present in the legacy vesting account.

## Examples

### Simple
Expand Down Expand Up @@ -206,7 +230,7 @@ It can still, however, delegate.
BC = 2.5 + 5 = 7.5
```

Notice how we have an excess amount of `DV`.
Notice how we have an excess amount of `DV`. This is explained in [In An Event Of Slashing](#in-an-event-of-slashing)

### Periodic Lockup

Expand Down
Loading