CIP: lockup account & staking rewards#253
Conversation
|
suggest including the option to apply a reward-rate discount for staking locked tokens protocol is overpaying for security, since it's much easier to attract locked tokens to staking than unlocked |
cips/cip-31.md
Outdated
|
|
||
| # Backwards Compatibility | ||
|
|
||
| No backwards incompatibilities are introduced for non-lockup accounts. Existing lockup accounts not subject to the new reward integration will continue to operate as before. For accounts that do use the new functionality, the changes are additive and maintain the original lockup semantics. |
There was a problem hiding this comment.
Existing lockup accounts not subject to the new reward integration will continue to operate as before.
Which existing lockup accounts are not subject to this CIP? It's not entirely clear to me if this CIP impacts existing lockup accounts or only newly created lockup accounts. I assume the former but then this sentence doesn't make sense to me.
| - **If it is:** | ||
| - Verify that it is of a modifiable lockup type. | ||
| - Calculate the new lockup amount: | ||
| `New Lockup Amount = Original Lockup Amount + Claimed Rewards` |
There was a problem hiding this comment.
[question] In this context is "Claimed Rewards" only applicable to the claimed rewards at a particular moment in time? Put another way, this CIP only impacts claimed rewards after this feature has been added. Lockup accounts that have already claimed staking rewards (i.e. on celestia-app v3) don't contribute to the "Claimed Rewards" in this calculation.
There was a problem hiding this comment.
correct, claims prior to the upgrade are not subject to locking at this would require large amount of offchain data
| # Parameters | ||
|
|
||
| When upgrading to v4 we propose introducing a migration that will set the Parameter in [`x/Staking`](https://github.com/cosmos/cosmos-sdk/blob/release/v0.50.x/x/staking/types/staking.pb.go#L934) to 25% disallowing new validators from creating validators with \>25% commission rates. | ||
|
|
There was a problem hiding this comment.
2 questions:
-
do I misunderstand the parameter in the referenced GOlang file or is the line item referring to a minimum commission, as opposed to a maximum commission that you are proposing?
-
So somebody operating an active validator today with delegations today with a 100% commission set (e.g., for anti-money laundering reasons) would not be affected by this change for the existing validator? But if that operator wants to split his delegations to 2 validators (e.g., to mitigate slashing impact radius), the newly created validator would be restricted to a maximum 25% commission?
There was a problem hiding this comment.
do I misunderstand the parameter in the referenced GOlang file or is the line item referring to a minimum commission, as opposed to a maximum commission that you are proposing?
My understanding is that this just points to where to expect a new param (MaxCommissionRate) which applies to all new validators. Agreed this is confusing and should be made clearer here.
So somebody operating an active validator today with delegations today with a 100% commission set (e.g., for anti-money laundering reasons) would not be affected by this change for the existing validator?
Yes.
But if that operator wants to split his delegations to 2 validators (e.g., to mitigate slashing impact radius), the newly created validator would be restricted to a maximum 25% commission?
Yes, the newly created validator would also be restricted to 25%.
I did a lot of thinking about this and talked to some people. I believe teams should account for this at the start and in contractual agreements. We could run into the issue that due to how contracts are written today it would cause issues. If a new team would like to explore this im happy to share more insights |
|
Please use a filename such as |
| @@ -0,0 +1,157 @@ | |||
|
|
|||
| | cip | XX | | |||
There was a problem hiding this comment.
| | cip | XX | | |
| | cip | 31 | |
|
I'll merge this and rename accordingly 🫡 |
Overview
This CIP proposes modifying lockup accounts to account for staking rewards. The change will modify lockup accounts total amount and how much is unlocked.