[IMPROVEMENT] Reworked Node Operator fee change mechanism

[u-hubar]

Node Operator Fee Update Mechanism

The system manages operator fees using two storage areas: StakingStorage for the currently active fee, and NodeOperatorFeeChangesStorage for pending fee updates.

High-Level Sequence Diagram

Initial State

At the start, the operator's fee is recorded only in StakingStorage. This fee is used for all calculations until any update occurs.

Updating the Fee

1. Initiating an Update: When a node operator decides to update their fee, they submit the new fee along with an "activation timestamp" to NodeOperatorFeeChangesStorage. This activation timestamp is set to 28 days from the update submission, marking a delay period before the new fee takes effect.

2. Transitioning Fees: If there's already a pending fee update in NodeOperatorFeeChangesStorage, this pending fee is moved to StakingStorage to become the current active fee. The new update then waits in NodeOperatorFeeChangesStorage until its activation timestamp.

Reward Collection Check

• When collecting rewards, the system checks for any pending fee updates in NodeOperatorFeeChangesStorage.
• If an update has become "active": This is determined by checking if the activation timestamp of the fee in NodeOperatorFeeChangesStorage has passed after the close of the Commit Window for the current epoch.
  • If yes (the update became active after the Commit Window closed), the system uses the fee from StakingStorage for calculations, as this represents the fee before the latest update.
  • If the update's activation timestamp was during the Commit Window or in previous epochs, the system adopts the new fee from NodeOperatorFeeChangesStorage for calculations.

This process ensures that fee updates are transparently managed, maintaining fairness in fee application across commits/proofs.

---

Pros:

• No storage changes
• 1 tx for Node Operator fee change instead of 2 txs

Cons:

• Removal of the fee change finalization event (affects dependent indexers)
• More complicated way of checking current operator fee as you potentially need to check in 2 places to find active operator fee

---

[botnumberseven]

Hi,
Let me check I follow you here (from indexer point of view)

Current state - new value for operator fee becomes active after second transaction which emits staking_operator_fee_change_finished.

Proposed new state - new value for operator fee becomes active after datetime=[timestamp] from staking_operator_fee_change_started event emitted by first transaction. No second transaction needs to be issued.

Also i'm not sure i'm clear here

2. Transitioning Fees: If there's already a pending fee update in NodeOperatorFeeChangesStorage, this pending fee is moved to StakingStorage to become the current active fee. The new update then waits in NodeOperatorFeeChangesStorage until its activation timestamp.

Active fee - 1%, no pending fee.
I issue 1st tx (2% fee), active fee is still 1%, pending fee is 2%.
I issue another tx to update fee (3%), according to above my active fee should become 2% and pending 3%.
Which does not make sense as 28 days haven't passed yet.

[u-hubar]

Hi, Let me check I follow you here (from indexer point of view)

Current state - new value for operator fee becomes active after second transaction which emits staking_operator_fee_change_finished.

Proposed new state - new value for operator fee becomes active after datetime=[timestamp] from staking_operator_fee_change_started event emitted by first transaction. No second transaction needs to be issued.

Also i'm not sure i'm clear here

2. Transitioning Fees: If there's already a pending fee update in NodeOperatorFeeChangesStorage, this pending fee is moved to StakingStorage to become the current active fee. The new update then waits in NodeOperatorFeeChangesStorage until its activation timestamp.

Active fee - 1%, no pending fee. I issue 1st tx (2% fee), active fee is still 1%, pending fee is 2%. I issue another tx to update fee (3%), according to above my active fee should become 2% and pending 3%. Which does not make sense as 28 days haven't passed yet.

Hi,
It's a little bit different from what you described. Even if "active timestamp" now is in the past, it doesn't mean that new operator fee will apply for all proofs (rewards). From the Knowledge Asset perspective, for new operator fee to become active, 2 requirements should be satisfied:

1. Fee change timestamp should pass (28 days delay)
2. For given KA, Fee change timestamp should overlap with the Commit Window, otherwise it will become active starting from the next epoch

Regarding scenario you described, it's not possible to update fee when there is a pending change. I think I should add it as a con of the solution

[botnumberseven]

I see, so in this case fee can be updated at most once in 28 days, right?
I see examples of node operators changing their fees more often. Yeah, that would be a downgrade from a current process.

I agree that issuing 2 txs to change operator fee is worse then 1 tx. But I'm not sure this 1 tx difference makes up for all the Cons.

From node operator point of view I pick 2 txs solution (with ability to change my mind every day) over 1 tx solution (i can change my mind only every 28 days). Operator also can make mistakes, like fat-finger 100% fee. So 1 tx solution makes it very hard to fix these mistakes.

From othub indexer 1 tx solution adds complexity, with no obvious benefit.

[u-hubar]

I see, so in this case fee can be updated at most once in 28 days, right? I see examples of node operators changing their fees more often. Yeah, that would be a downgrade from a current process.

I agree that issuing 2 txs to change operator fee is worse then 1 tx. But I'm not sure this 1 tx difference makes up for all the Cons.

From node operator point of view I pick 2 txs solution (with ability to change my mind every day) over 1 tx solution (i can change my mind only every 28 days). Operator also can make mistakes, like fat-finger 100% fee. So 1 tx solution makes it very hard to fix these mistakes.

From othub indexer 1 tx solution adds complexity, with no obvious benefit.

Well, this is not a 1 tx vs 2 txs problem, main purpose of this rework is to remove possibility to change operator fee for commits that are already locked

[u-hubar]

@botnumberseven I think this problem can be resolved with the following mechanism

SS - staking storage
NOFCS - NodeOperatorFeesChangeStorage

1. I set operator fee to 1% initially (stored in SS)
2. I update operator fee to 2% (timestamp=now+28days, request stored in NOFCS)
3. I update operator fee to 3% (newTimestamp=now+28days)
   • If now <= timestamp -- move 2% to SS, store 3% with newTimestamp in NOFCS
   • Else if now > timestamp -- replace 2% in NOFCS with 3% and newTimestamp

[botnumberseven]

I see

From othub point of view that would require be a fair amount of changes in staging/stats tables as operator fee becomes a property of node-asset-epoch-?time?, rather then just node-time (like Ask). So the fee value need to be determined for every proof.

Could you help me with an example of how to calculate it based on tx and events data?

[u-hubar]

@botnumberseven I'll help you with that when final implementation is confirmed

[branarakic]

Communicated feedback in person, looks fine