[AIP-19][Discussion]Enable updating commission_percentage

[michelle-aptos]

AIP-19 - Enable updating commission_percentage

Discussion and feedback thread for AIP 19: https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-19.md

Summary

This AIP proposes an update to staking_contract.move, which would allow the stake pool owner to change commission_percentage.

Motivation

Currently, commission_percentage cannot be changed. The updating commission percentage feature will allow for better adaptability to changing market conditions.

Rationale

Considerations:

1. The staking contract tracks how much commission needs to be paid out to the operator. Updating commission_percentage is a convenience function added to staking_contract.move to allow a stake pool owner to update the commission percentage paid to the operator.
2. Commission_percentage can be updated by the stake pool owner at any time. Commission is earned on a per epoch basis. The change takes into effect immediately for all future commissions earned when the update function is called, but will not be retroactively applied to any previously earned commissions.
3. UpdateCommissionEvent gets emitted when the update_comission function is called

Alternative solutions:

The staking contract would have to be ended and a new one has to be created in order to change the commission_percentage. This is a less ideal solution as it creates more operational overhead and would result in missed staking rewards.

Reference Implementation

https://github.com/aptos-labs/aptos-core/blob/main/aptos-move/framework/aptos-framework/sources/staking_contract.move

https://github.com/aptos-labs/aptos-core/pull/6623/

Risks and Drawbacks

Changing commission_percentage may introduce uncertainty into commission earnings because it is possible that operators are paid at different commission rates during an unlock cycle. However, there is no additional action required for the operator as changes take into effect immediately.

We can mitigate this in a future iteration by implementing a max commission change per period. This is not a concern with the current owner-operator structure.

Future Potential

This feature will give the stake pool owner more flexibility over the commission_percentage to reflect changing market conditions.

Suggested implementation timeline

Targeting end of Q1

Suggested deployment timeline

This feature is currently on devnet and testnet as part of v1.3.

[ericjohncarlson]

Hi Michelle. Coming from other ecosystems, I'd like to present some ideas that may be relevant here as the team takes feedback. I'm talking from the viewpoint of a validator offering a public staking pool with a public interface:

• Implement a minimum commission rate. This can be controversial, but validators take time, cost, effort, expertise to run. This prevents validators running at 0% to earn public delegates (running undersized nodes with unpaid staff), and then later raise rates significantly above the public average.
• Implement a max-change rate. Any lowering of commissions should be immediately available. If a commission percentage is raised, it should only be raised by a certain percentage in a certain timeframe. This is to prevent a validator taking in delegations at 10% commission, then raising to 100% instantly until delegators realize that the commission % has changed. Many delegates don't monitor their validator's commission rate, so this could go on for weeks/months before a delegate realizes they've earned no rewards for staking. Something like 1% per 24 hour period.
• Implement a maximum commission rate. Partly to protect delegates from the above scenario.

[michelle-aptos]

Thanks for the feedback @ericjohncarlson!

These are all considerations that we're making for delegation pools (#20). Commission rate is currently fixed for delegation pools for all the reasons you've mentioned.

This AIP is for staking_pool, so the staker is the stake pool owner only. Commission rate is set by the owner not the operator in this case.

[ericjohncarlson]

Ah, thanks @michelle-aptos. Sorry, I missed that distinction. Looks like many of my points are already covered there, but will chime in.