[ACP-236] Continuous Staking #236
Conversation
| to changing market conditions or liquidity needs. Managing a large number of nodes is also challenging, as re-staking at | ||
| the end of each period is labor-intensive, time-consuming, and poses security risks due to | ||
| the required transaction signing. Additionally, tokens can remain idle at the end of a staking period |
There was a problem hiding this comment.
Are many users managing a large number of nodes? The staking limit is up to 3M AVAX
|
|
||
| Instead of committing to a fixed end time upfront, validators specify a cycle duration (period) when they submit an | ||
| AddContinuousValidatorTx. At the end of each cycle, the validator is automatically re-staked for a new cycle of the same | ||
| duration, unless the validator has submitted a StopContinuousValidatorTx. If a validator submits a |
There was a problem hiding this comment.
| duration, unless the validator has submitted a StopContinuousValidatorTx. If a validator submits a | |
| duration, unless the validator has submitted a `StopContinuousValidatorTx`. If a validator submits a |
|
|
||
| ## Abstract | ||
|
|
||
| This proposal introduces continuous staking for validators on the Avalanche P-Chain. Validators can stake their tokens |
There was a problem hiding this comment.
Formatting wise, I think it'd be better to leave sentences/paragraphs on single lines and let it auto-wrap in the display (ACP-77 is a good example of that), rather than manually inserting new lines.
|
|
||
| ## Motivation | ||
|
|
||
| The current staking system on the Avalanche P-Chain restricts flexibility for stakers, limiting their ability to respond |
There was a problem hiding this comment.
Would be great to briefly include how it restricts flexibility (by requiring an explicit pre-defined end time with minimum and maximum durations)
| ## Motivation | ||
|
|
||
| The current staking system on the Avalanche P-Chain restricts flexibility for stakers, limiting their ability to respond | ||
| to changing market conditions or liquidity needs. Managing a large number of nodes is also challenging, as re-staking at |
There was a problem hiding this comment.
respond to changing market conditions or liquidity needs
If the minimum period length is the same as the current minimum staking duration, does this impact/improve the market condition response ability at all?
There was a problem hiding this comment.
I would inverse the perspective: based on the expected duration (because it is not fixed anymore) of staking, and how flexible validator would like to be, he can choose a period granular enough for their preference.
So yes, even if the minimum period length is the same as the current minimum staking duration, it still provides flexibility.
Note: there is an exception: if validator is willing to stake for [2weeks, 4weeks), there isn't much he can do. Or as a rule: [MinStakeDuration, 2 * MinStakeDuration)
|
|
||
| This proposal introduces continuous staking for validators on the Avalanche P-Chain. Validators can stake their tokens | ||
| continuously, allowing their stake to compound over time, accruing rewards once per specified cycle. | ||
|
|
There was a problem hiding this comment.
It's probably worth noting (here or elsewhere) that this only applies to primary network validation.
It does not apply for L1 validators (where the mechanism is controlled by the L1 validator manager contract in use) or for legacy subnet validators.
| TxID ids.ID `serialize:"true" json:"txID"` | ||
|
|
||
| // Authorizes this validator to be stopped. | ||
| // It is a BLS Proof of Possession signature of the TxID using validator key. |
There was a problem hiding this comment.
By TxID here, do you mean the AddContinuousValidatorTx tx ID?
| // It is a BLS Proof of Possession signature of the TxID using validator key. | |
| // It is a BLS Proof of Possession signature of the AddContinuousValidatorTx transaction ID using validator key. |
There was a problem hiding this comment.
I wanted to avoid duplicate information, and only reference TxID field which has its own definition.
But for improved clarity, I can add this.
|
|
||
| // Authorizes this validator to be stopped. | ||
| // It is a BLS Proof of Possession signature of the TxID using validator key. | ||
| StopSignature [bls.SignatureLen]byte `serialize:"true" json:"stopSignature"` |
There was a problem hiding this comment.
Are there any alternatives for avoiding using a BLS signature from the node's key here?
Given the way that many nodes are managed, I think it'd be relatively high friction to get signatures for many potential users of this. For instance, many times I'd imagine that teams managing validator infrastructure are not the ones managing staking transactions to those nodes.
If there are no viable alternatives, we should probably add a section on how this could be easily implemented potentially via private admin RPC endpoints or something.
The only alternative I can think of would be requiring a signature from the ValidatorRewardsOwner, but not sure how feasible that is.
| validators: `RewardContinuousValidatorTx`. Along with the validator’s creation transaction ID, it also includes a | ||
| timestamp. For simplicity and consistency, any stake exceeding the maximum limit is withdrawn from the validator, and | ||
| the resulting UTXOs are tied to the `RewardContinuousValidatorTx` ID. | ||
|
|
There was a problem hiding this comment.
I think we should specify how uptime requirements work for continuous validators here as well.
|
|
||
| - Should the `AddContinuousValidatorTx` transaction allow specifying a reward withdrawal frequency? | ||
|
|
||
| - If auto-restaking causes the total stake to exceed the maximum allowed limit, should all accumulated rewards (from the |
There was a problem hiding this comment.
I'd personally lead to simplicity and correctness here, so I'm in favor of the entire rewards being withdrawn instead of only the excess amount.
Also, to question number 1, given that we'll need to support the logic for potentially distributing/withdrawing rewards as part of the RewardContinuousValidatorTx execution in the case the where the validation hasn't been stopped anyways, I personally be in favor of adding an AutoCompoundRewards option to AddContinuousValidatorTx. In the execution of RewardContinuousValidatorTx, rewards are credited to the reward owner if AutoCompoundRewards is false or if the rewards + the initial stake weight would exceed the maximum stake limit. Otherwise the rewards are auto-compounded into the stake amount for the next validation cycle period.
3 participants
No description provided.