AIP-6: Delegation pool for node operators #21
Conversation
aips/aip-6.md
Outdated
|
|
||
| The staking API initially exposed would incur a higher gas cost (only for delegation pools) as additional resources have to be stored and maintained in order to keep track of individual delegators' stakes and cumulative rewards earned by pool's aggregated stakes. | ||
|
|
||
| Compared to a single-owner stake pool, rewards produced each epoch would not be automatically restaked for delegators as this would introduce a quadratic complexity when updating the validators set at the epoch's end. Nonetheless, delegators can manually restake their earned rewards, while failing to do so over an entire year would result in their compound APR dropping from 16.18% (automatically restaking each epoch of 1h duration) to 15% (current reward rate). |
There was a problem hiding this comment.
"rewards produced each epoch would not be automatically restaked" I'm not sure if I follow this. Rewards produced at the end of each epoch are automatically added to the stake pool so they're restaked by default. Is this referring to this or something else?
There was a problem hiding this comment.
This applied to the previous version of delegation-pool. Currently, the use of shares-based pool ensures rewards are automatically restaked due to share appreciation
aips/aip-6.md
Outdated
|
|
||
| Compared to a single-owner stake pool, rewards produced each epoch would not be automatically restaked for delegators as this would introduce a quadratic complexity when updating the validators set at the epoch's end. Nonetheless, delegators can manually restake their earned rewards, while failing to do so over an entire year would result in their compound APR dropping from 16.18% (automatically restaking each epoch of 1h duration) to 15% (current reward rate). | ||
|
|
||
| The operator fee, previously configurable by the owner, could be set either by a governance process at the level of the delegation pool or immutably at pool's creation by the node operator itself. For the latter, delegators have the option to participate in pools of their choice with regard to fee and node performance. |
There was a problem hiding this comment.
Which governance process is "governance process at the level of the delegation pool" referring to?
There was a problem hiding this comment.
This was before deciding that it is straightforward to have an immutable fee and let delegators choose the delegation pool themselves.
There was a problem hiding this comment.
I think making an immutable fee for a public pool is a kinda controversial idea in the long term. It can potentially limit flexibility for validators to reflect changing market conditions and staking revenues.
For example, changing the fee to 0% can be a good option to compensate for a short-term weak performance/incident that led to a reward loss without the need to send and calculate rebates per user, imposing a legal risk of a custodial transfer.
In case of increasing the fee, responsible validators make announcements in advance, allowing delegators to change the pool if they don't want to continue staking at that fee. There are also other options to prevent that behavior, like building a notification tool, setting the max cap for possible fee % during the pool creation etc.
Curious if the decision to make an immutable fee is based on tech limitations, or are there other reasons for that?
There was a problem hiding this comment.
Given the nascency of delegation on aptos blockchain, I would suggest an immutable fee helps to protect the stakers by ensuring that the operator doesn't suddenly raise fees without notice / public announcements. This is important given that many stakers might leave their tokens in a pool and not pay attention for a long while. However, I agree that potentially allowing operators to have the ability to change fees based on market conditions might be a useful feature in the longer term. But I would class this as a P2
|
Thanks for putting up the initial draft! Let's merge this AIP and keep iterating on this. |
No description provided.