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

CIP: lockup account & staking rewards #253

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

tac0turtle
Copy link

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.

@tac0turtle tac0turtle changed the title CIP: lockup account rewards CIP: lockup account & staking rewards Feb 12, 2025
@gavinly
Copy link

gavinly commented Feb 12, 2025

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

@@ -0,0 +1,157 @@

| cip | XX |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re: filename, would suggest leaving un-numbered until this is ready for review.

nit: https://cips.celestia.org/cip-template.html

Note: READ CIP-1 BEFORE USING THIS TEMPLATE! This is the suggested template for new CIPs. After you have filled in the requisite fields, please delete these comments. Note that an CIP number will be assigned by an editor. When opening a pull request to submit your CIP, please use an abbreviated title in the filename, cip-draft_title_abbrev.md. The title should be 44 characters or less. It should not repeat the CIP number in title, irrespective of the category.


# 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.
Copy link
Collaborator

@rootulp rootulp Feb 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[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.

cips/cip-31.md Outdated Show resolved Hide resolved
# 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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 questions:

  1. 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?

  2. 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants