ACP-236: Continuous Staking - Iteration 2 #262
Conversation
rrazvan1
force-pushed
the
acp-236/continuous-staking-iteration-2
branch
2 times, most recently
from
a886a51 to
d33f626
Compare
…awn, auto-restaking only if eligible for rewards
rrazvan1
force-pushed
the
acp-236/continuous-staking-iteration-2
branch
from
d33f626 to
3cf6474
Compare
| Continuous staking introduces a mechanism that allows validators to remain staked indefinitely, without having to manually submit new staking transactions at the end of each period. | ||
|
|
||
| Instead of committing to a fixed endtime upfront, validators specify a cycle duration (period) and an `AutoRenewRewardsShares` value when they submit an `AddContinuousValidatorTx`. At the end of each cycle, the validator is automatically restaked for a new cycle of the same duration, unless the validator submits a `SetAutoRenewPolicyTx` with `AutoRenewRewardsShares` set to the sentinel value `MaxUint64`. If a validator submits such a `SetAutoRenewPolicyTx` during a cycle, the validator will continue validating until the end of the current cycle, at which point the validator exits and the funds are unlocked. Both `AddContinuousValidatorTx` and `SetAutoRenewPolicyTx` include the `AutoRenewRewardsShares` field, which controls the automatic restaking or withdrawal behavior of the rewards at the end of each cycle. The minimum and maximum cycle lengths follow the same protocol parameters as before (`MinStakeDuration` and `MaxStakeDuration`). | ||
| Instead of committing to a fixed endtime upfront, validators specify a cycle duration (period) and an `AutoRestakeShares` value when they submit an `AddContinuousValidatorTx`. At the end of each cycle, the validator is automatically restaked for a new cycle. The validator (via `Owner`) may update the the auto-restake config at any time during a cycle; such updates take effect only at the end of the current cycle. To stop validating, the validator signals intent to exit by updating the next cycle’s period to `0`; this causes the validator to exit at the end of the current cycle and unlock the funds. The minimum and maximum cycle lengths follow the same protocol parameters as before (`MinStakeDuration` and `MaxStakeDuration`), and any updated period must also respect these limits (except the special value `0`, which means “stop”). |
There was a problem hiding this comment.
The validator (via
Owner) may update the the auto-restake config at any time during a cycle; such updates take effect only at the end of the current cycle.
A valuable question to answer would be " What if AutoRestakeShares is updated after uptime failure but before cycle end?"
Obviously it wouldn't have any effect since the validator will be forcefully exited at the end of the current cycle, but would this txn fail?
There was a problem hiding this comment.
That transaction will be executed successfully.
Rewards eligibility, as it is implemented right now, based on uptime, it's a subjective observation of a node, making it a non-deterministic check, that can not be included in a in TX validation.
Also, this is just a small UX improvement that would've added extra complexity.
|
Most of my comments are for clarity, including the differentiation of a planned graceful exit and a forced exit from the validator set. Also included a question about what would happen if someone tries to update their renewal rules if they already fail to meet uptime requirements for the current cycle |
| // 1_000_000 = restake 100% of rewards; withdraw 0% | ||
| // Sentinel value MaxUint64 indicates "stop at the end of current cycle". | ||
| AutoRenewRewardsShares uint32 `serialize:"true" json:"autoRenewRewardsShares"` | ||
| AutoRestakeShares uint32 `serialize:"true" json:"autoRestakeShares"` |
There was a problem hiding this comment.
IMO it would make more sense to use basis points (bips) here (1/10,000), which is an established way of representing percentages. It is slightly less precise, but 0.01% granularity should be more than enough.
| AutoRestakeShares uint32 `serialize:"true" json:"autoRestakeShares"` | |
| AutoRestakeRewardsBips uint32 `serialize:"true" json:"autoRestakeRewardsBips"` |
There was a problem hiding this comment.
avalanchego codebase is already using a 1/1,000,000 denominator for delegation fee, because of which there are existing helper functions.
Thus, using the same denominator for the autorestake percentage keeps the codebase cleaner and easier to maintain.
There was a problem hiding this comment.
Makes sense! I didn't know that
3 participants
Changes:
MaxStakeLimitis withdrawn