ACP-236: Continuous Staking #244
Replies: 10 comments 10 replies
-
|
Moving my thoughts from the PR to this discussion thread for further consideration: Prior to its implementation though, I do think the following need to be considered:
|
Beta Was this translation helpful? Give feedback.
-
|
Good improvement for the validation UX. One question: What duration will be used as One improvement: for clarity, it'd be great to remind people of the current values of |
Beta Was this translation helpful? Give feedback.
-
|
The On mainnet, the current configuration is: I'll make sure to update the ACP! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for writing this I think continuous validation should be linked with minimum uptime requirements. If a validator is persistently offline we should not keep it in the set rolling indefinitely |
Beta Was this translation helpful? Give feedback.
-
|
I find it a bit frustrating that the MaxStakeDuration is capped at just one year 😑 Personally, I wouldn’t mind locking for a much longer period, especially if the rewards were distributed each cycle. It would be even better to have a feature allowing the validator to increase their staked amount, with the added portion starting to earn rewards from the next cycle. This concept sounds great to me. Thanks, @rrazvan1 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the ACP, continuous staking is definitely something I'm looking forward to! Now here are some question, I have about it: Reward accrual and claiming Unbonding behavior Duration-based yield LST and DeFi integration |
Beta Was this translation helpful? Give feedback.
-
Thanks to @michaelkaplan13's suggestion, I’m updating the ACP to include a new specification that gives users full control over reward restaking. A new field will define what percentage of rewards should be automatically added to the stake at the end of each cycle, while the rest will be withdrawn. This value will be mutable, so validators can adjust it at any time.
When you request a stop in the middle of a cycle, the validator keeps running until that cycle finishes.
The current ACP only tweaks how continuous staking works, it doesn’t change the tokenomics or how rewards are calculated. So, the yield stays the same no matter how many cycles a validator has gone through.
Validators' weights are stored in state and can’t be made fungible. Supporting that would require deeper protocol changes, which are out of scope for this ACP. |
Beta Was this translation helpful? Give feedback.
-
|
I think this is a great effort, and I would like to refer to a previous discussion I started here. In fact, I am/was working on attempting to revive the discussion since there are new reasons/use-cases and improvements I would like to see. In that discussion (which is very similar in spirit to the changes suggested here), I address also ways to make continuous delegations (time-unbounded staking/delegations in the terminology there). Note that the existing staking/delegation infrastructure on the P-chain is designed to make rewards calculations easy, predictable, and more importantly, efficient computation-wise for the P-chain. It does not need epochs, and rewards are not accrued continuously. This should remain so IMHO as the P-chain has to maintain all validator sets of all Avalanche L1s. Further to elaborate why this change is important: initial motivations for the staking provider and user experience standpoints are detailed the referred previous discussion, but there is also a new use case that should not be overlooked: ETFs are a thing nowadays and an important vehicle for ecosystem growth. They are highly regulated, and ETFs face difficulties in satisfying their requirements while utilizing the basic yield mechanism of staking. This is not only an issue in Avalanche with Ethereum being another major chain with the same fate. In essence, ETFs are required to satisfy T+2d liquidity requirements for all of their funds. That is, they should be able to return funds to investors on a timely basis (2 days in most cases) since requested, and this requirement should cover 100% of their funds. This makes staking unavailable to AVAX ETF. To solve the issue, continuous staking with a cycle of 1 day would be necessary, and this ACP (and the related discussion) would provide it. I've been in discussions with ETF providers, LSTs, and the Avalanche Foundation, and there is no good solution we could find that would enable this use case (other than the ones that shift the risk from the ETF provider to other entities) without technical changes to the staking mechanism. In regards to improvements:
|
Beta Was this translation helpful? Give feedback.
-
|
Really looking forward to a community call on this one! |
Beta Was this translation helpful? Give feedback.
-
I started a discussion about that a while back! #174 |
Beta Was this translation helpful? Give feedback.
-
|
Since this ACP is focused on improving the staking UX, I’m also thinking about unifying Having just one withdrawal address would simplify the reward distribution logic. |
Beta Was this translation helpful? Give feedback.
-
|
@erwindassen @Nuttymoon any opinions here? |
Beta Was this translation helpful? Give feedback.
-
|
Not really. But I wouldn't change it since it might break existing tooling |
Beta Was this translation helpful? Give feedback.
-
|
Yes we use it. For real. |
Beta Was this translation helpful? Give feedback.
-
|
I assume you mean that the delegation fees go to a beneficiary different than the beneficiary address for the main stake rewards. |
Beta Was this translation helpful? Give feedback.
-
First, I love the work on the latest iteration of continuous staking and fully support ACP-236!I'd like to propose a complementary feature that addresses a different set of use cases: ability to express withdrawal preference between original staking deposit vs. new staking rewards. I think this would work great as a natural Iteration 2 of continuous staking, that works alongside (not replaces) the AutoRenew mechanism. Motivation: Tax Optimisation & Liquidity Use CasesUser flexibility, Accounting Clarity and (jurisdiction dependent) Tax OptimisationMany tax jurisdictions distinguish between returning original capital and receiving earned income and calculate tax obligations based on the timing of when the rewards are actually received, and able to be sold. Giving the Validator the ability to specify withdrawal preference during withdrawal (deposit-first vs. rewards-first) provides:
Killer example
Liquidity Without Full Exit
Technical FeasibilityThis proposal follows the existing P-Chain architecture for deposit/reward separation: Current fixed staking (already in production):
Current ACP-236 design:
Proposed extension - split
This extension preserves the existing Proposed Enhancement: Manual Partial WithdrawalsCore FunctionalityAllow validators to withdraw specific amounts at cycle end, with preference for withdrawal order: type PartialWithdrawContinuousValidatorTx struct {
BaseTx `serialize:"true"`
// User-specified inputs
ValidatorTxID ids.ID `serialize:"true" json:"validatorTxID"`
WithdrawAmount uint64 `serialize:"true" json:"withdrawAmount"`
WithdrawPreference WithdrawPreference `serialize:"true" json:"withdrawPreference"`
WithdrawTo []*avax.TransferableOutput `serialize:"true" json:"withdrawTo"`
Auth verify.Verifiable `serialize:"true" json:"auth"`
}
type WithdrawPreference uint8
const (
WithdrawDepositFirst WithdrawPreference = 0 // Original stake first
WithdrawRewardsFirst WithdrawPreference = 1 // Rewards first
)During execution, the protocol calculates the breakdown based on the validator's Validator State TrackingThe existing type AddContinuousValidatorTx struct {
// ... existing fields from ACP-236 ...
// Replace single Wght with two tracked components:
DepositStake uint64 `serialize:"true" json:"depositStake"` // Initial stake amount
RewardsStake uint64 `serialize:"true" json:"rewardsStake"` // Starts at 0, increases with compounding
// Wght remains as computed property: Wght = DepositStake + RewardsStake
}When On-Chain Audit TrailThe audit trail emerges from three sources:
Design ConsiderationsInteraction with AutoRenewRewardsSharesBoth mechanisms coexist, giving validators maximum flexibility:
Validators can use both, either, or neither depending on their needs. Delegation CapacityWithdrawing from Minimum Stake RequirementIf a partial withdrawal would drop Timing
|
Beta Was this translation helpful? Give feedback.
-
|
Do you have examples of tax regimes that incentivize in both directions? E.g, which jurisdiction does not consider rewards income as they are realized, but only when they are withdrawn? |
Beta Was this translation helpful? Give feedback.
-
|
ICYMI: The developer community call has been announced. Sign up to join the discussion! #252 |
Beta Was this translation helpful? Give feedback.
-
|
Thoughts on allowing continuous validators to change their "period" duration via the Otherwise if I have a period of 6 months and want to reduce it after the end of the current period to 1 month, I have to issues a I don't know what level of complexity that would introduce, but generally have an underlying worry that people here "continuous staking" and have the expectation you can just start validating and come back to exit whenever. We should be diligent about avoiding that misperception either way. |
Beta Was this translation helpful? Give feedback.
-
|
nice idea! It shouldn't add much complexity. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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. Note that this mechanism applies only to primary network validation. It does not apply to L1 validators or to legacy subnet validators.
https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/236-continuous-staking/README.md
Beta Was this translation helpful? Give feedback.
All reactions