Time unbounded validation and delegation

[erwindassen]

UPDATED ON: 2023-12-12

• Rewording for clearer reading.
• Addressed a few open questions.

Abstract

The Avalanche network uses an uptime based metric for deciding on staking and delegation rewards. Nodes that complete the bonding period with more than 80% uptime as perceived and decided by network consensus earn said rewards. Note that this entails a pre-agreed upon lock period.

But reasons detailed below users of the network might be interested in staking or delegating for an unbounded period earning rewards until they decide to "unstake" or "undelegate". This ACP details how such a mechanism can be implemented without forgoing the current mechanism and making unbounded staking/delegation completely optional.

Motivation

The motivation for proposing a change to the Avalanche network's staking and delegation mechanism stems from a desire to offer greater flexibility and control to its users. Under the existing system, participants are bound by a specific lock period, during which they must maintain high uptime to earn rewards. This system, while having many advantages (simple predictable calculations being a big one), potentially limits participants who may prefer a more hands-off arrangement where their capital is not tied up for a set duration. This is particularly true in the context of professional validator services which often depend on maintaining delegations as means of profit. Having to re-attract existing delegators after each period presents unnecessary complication for the customers of the providers. One can also not disregard the attractiveness for personal validators as well.

By introducing an unbounded staking and delegation option, users can enjoy the liberty to earn rewards continuously without a definitive end date. This option would cater to users seeking a more open-ended investment strategy. Instead of being constrained by a pre-set bonding period, they can choose when to "unstake" or "undelegate," giving them the opportunity to adapt their strategies in a more granular fashion.

The fact that this is done as logic "on-top" of the existing staking logic in the P-chain allows this feature to be entirely opt-in without changing any of the existing rewards logic reducing implementation complexity. It also preserves the integrity and appeal of the initial system for those who prefer the structure and security of the lock-in period.

In summary, by making this new mechanism completely optional, the ACP aims to enhance the network's inclusivity and attractiveness to a broader range of investors while maintaining the network consensus's ability to reward consistent, long-term participation.

In the rest of this ACP we call a (time-)unbounded validator a validator that decides to opt in the mechanism for staking for an unbounded period.

Overview

Put it simply, the unbounded validator feature works by using the underlying, existing staking/delegation logic in a loop dictated by a stakingCycleLength parameter. It adds two new data structures and four new transaction types.

• timeUnboundedValidators
• timeUnboundedDelegators
• AddTimeUnboundedValidatorTx
• RemoveTimeUnboundedValidatorTx
• AddTimeUnboundedDelegatorTx
• RemoveTimeUnboundedDelegatorTx

When a user "emits" an AddTimeUnboundedValidatorTx and assuming the happy path for a moment, the execution path adds the validator to the timeUnboundedValidators list and performs a staking operation with the given NodeId, SubnetId, staking amount x and stakingCycleLength as staking period. Note that SubnetId can be the mainnet's. More details when the subnet is not mainnet will be addressed below.

At the end of a validator's staking period of a validator (not only unbounded ones) a check is performed to see if said validator is in the timeUnboundedValidators list. If so it "re-stakes" the accumulated amount received in the current P-chain address (see open questions below) for the same cycle length and updates the P-chain address used. It then goes over the timeUnboundedDelegators list for this NodeId and performs delegation logic to this validator for these delegators. If the validator is not in this list, logic proceeds as usual for the end of a staking period. Note that we are not issuing new delegation transactions so no new signatures required but it does involve the calculation of new P-chain addresses. Again, see open questions below. Optionally, we could have a parameter that allows to "re-stake" or "re-delegate" a portion of the rewards and send the rest to the owner.

When the user eventually emits a RemoveTimUnboundedValidatorTx, the execution logic removes the given NodeId from the timeUnboundedValidators list.

The exact same logic is used for the delegation "versions" of these transactions with only the following extra point: the delegation's stakingCycleLength can be smaller than that of the underlying validator. If this is the case, upon the end of a delegator's cycle we check if another delegation cycle can fit in the validator's. If so we "re-delegate" the accumulated amount as expected. If not we delegate to the maximum left over period in the validator's cycle or do nothing in case this is not a valid period (for example less than two weeks in the current validator's cycle).

The logic also allow us to integrate seamlessly with subnets assuming ACP-13 is implemented. As of now, this is not yet the case so any subnet validator must validate the mainnet. The logic for an unbounded subnet validator thus requires similar logic as that for delegations. Namely, that the validator must be an unbounded mainnet validator and that the stakingCycleLength of the subnet's staking transaction be smaller or equal to that of the of the mainnet staking transaction. In addition, we execute staking logic for this subnet when the mainnet cycle is over.

For permissioned subnets the situation is a little simpler as these are not under control of the user but of the subnet owner. In essence, there is no dedicated logic for the permissioned case as there is no actual stake. Just an inclusion list.

Security Considerations

None so far.

Open Questions

Does P-chain addresses change impact this approach?

As it is well-known, the P-chain addresses (used as reward owners) change on each staking. How are these addresses derived? Can we reuse the same reward owner during the whole time the validator remains an unbounded validator? This has also repercussion in the usage of P-chain addresses by the user outside of the staking process.

What about the 3M validator max stake?

Every validator in the Avalanche network has a maximum stake weight. As of now 3M AVAX. A validator with this weight would not be able to receive any more stake or delegations. At the end of the cycle how do we handle rewards in such a case? The simples solutions would be to send rewards to the reward owner address for any reward amount that would push this validator above the cap.

[abi87]

Hey @erwindassen,
interesting idea! There was some work on this earlier this year (see ava-labs/avalanchego#1494) that was not finalized.The PR is way out-of-date, I should refresh it.
I have a few questions about the proposal:

1. Reward restaking: users may be interested in restaking a part of the reward accrued during the last staking cycle (even 100% of it) and to have part of it paid out as soon as staking cycle terminates (even 100% as it happens currently). Should we allow Unbounded stakers (delegators and validators) to specify a restake percentage at the start?
2. Subnet validators: you propose that if a delegator cannot restake due to hitting its validator's end time, we restake the delegator shortening its period to whatever is left (assuming it's more than the minimal staking period). How would you handle subnet validators? Simiarly to delegators, their staking period is currently bounded by primary network validation time. Should we shorten the subnet validator period? Should we avoid restaking it? Should we extend primary network validation time to allow one last restaking of the subnet validator? Note that elastic subnets have subnet delegators as well, whose restaking must be handled.

Looking forward hearing from you about this

[erwindassen]

Thanks for the input. I looked at your PR. Looks indeed similar in spirit to the idea laid out here. With regards to the questions:

1. Yes that seems reasonable. Some sensible default should be in place: send it to the rewards address?
2. I had a session on this point but removed for initial simplicity for the discussion phase. But yes, I thought approaching similarly as for delegations. Try to fit in the relevant period and if not possible (less than 2wks window) do nothing and stake in the next cycle. This is indeed only for permissionless subnets since for permissioned ones there is no PoS token. Rewards/payments are off-channel. Also, this will be simplified much with ACP-13.

[erwindassen]

A user in telegram pointed to another open question: what to do in case of reaching the token limit? I.E. 3MAVAX? Putting here for reference and thinking about it...

[abi87]

The way we calculate rewards here guarantees that cap is not reached really.
However there is a subtler point around how much validator stake can grow vs how much delegators stake can. There are limits on how big a validator stake can be, so we could think of a way to let validators choose how much delegators stake can grow vs their own stake

[erwindassen]

Yeah, that's what I meant. Not the coin max cap but the validator max "space", 3MAVAX, as of now. I think the simplest solution is to send any reward (validator or delegator) to the reward owner address is it would push the validator stake weight above the cap.