PIP-31: Unleashing the potential of POKT

[RawthiL (Ramiro | POKTscan)]

Thanks for puttingup this work, v0 needs some attention…

Chain Multipliers

@bulutcambazi

… we can incentivize node operators to host brand new chains / quiet chains with little traffic by setting higher RTTMs for such chains instead of decreasing the value of pos/MaximumChains [3] which is proposed as GANDALF [4].

I think fees per chain and number of chains by node are two completely different subjects. We need per-chain RTTM but implementing it wont solve any of the problems that multiple chains by node creates. I would leave out the subject of chain incentives aside, the fact that archival nodes are more expensive than light nodes is more than enough justification for this change.

@bulutcambazi

We propose a new parameter pos/RelaysToTokensMultiplierMap so that we can set RTTM per chain.

I believed that there was some unused parameter to address this, it is likely that I’m wrong, but I will ask.
Has the parameter auth/FeeMultipliers any relation to per chain fees? It is currently set to 1 but it could be a list containing different fees.

Delegation

@bulutcambazi

It then distributes the delegators’ shares to their respective wallets and sends the remaining tokens to the output address. This means that relay rewards are now distributed across five types of wallets: the DAO, the BlockProposer, the servicer’s operator, the delegators, and the operator address.

You propose to divide rewards to (correct me if wrong):

• DAO : As usual.
• BlockProposer: As usual.
• Servicer Operator: Only claim/proof fees. This exists because the fee is not proportional to the claimed ammount, so the operator must always be refunded at least this amount.
• Delegators: A list of addresses with percentages of the remaining rewards, I suppose that the sum of percentages is <= 100%
• Operator Address ?? I think that this is the Output Address, maybe a typo? : This will receive the rest, its a way of saying “the owner of the node takes all that is not claimed for”.

---

I think I agree with this.
The “editing” of the delegators might come with some debate, but it seems fair and also the changes will be visible in-chain for everyone to audit and/or set alarms if the operator changes these parameters.