You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #97 we implement a basic rewards distribution mechanism, all in the name of simplicity.
Probably this design is good for now as 1) this serves as a PoC/baseline on the user stories that we can improve upon, and 2) we haven't received a concrete tokenomics design from the product team.
However, likely problems 1/2/3 in the issue need to be resolved if we really decides on the pro rata distribution over FPs. This is because the protocol needs to ensure the reward distribution is fair, i.e., the reward of an FP has to be proportional to its contribution. Using the last voting power table to do the distribution might cause non-negligible bias. For example, if a FP is slashed and then suddenly the chain has 100 new finalised blocks, then this FP won't get any reward for its previous contribution. This looks like an edge case in terms of engineering, but this bias might not be negligible from the product's PoV.
The idea would be to implement the exact same mechanism Babylon is now using for distribution, or one with similar behaviour / functionalities.
Creating this issue for tracking.
The text was updated successfully, but these errors were encountered:
In #97 we implement a basic rewards distribution mechanism, all in the name of simplicity.
Probably this design is good for now as 1) this serves as a PoC/baseline on the user stories that we can improve upon, and 2) we haven't received a concrete tokenomics design from the product team.
However, likely problems 1/2/3 in the issue need to be resolved if we really decides on the pro rata distribution over FPs. This is because the protocol needs to ensure the reward distribution is fair, i.e., the reward of an FP has to be proportional to its contribution. Using the last voting power table to do the distribution might cause non-negligible bias. For example, if a FP is slashed and then suddenly the chain has 100 new finalised blocks, then this FP won't get any reward for its previous contribution. This looks like an edge case in terms of engineering, but this bias might not be negligible from the product's PoV.
The idea would be to implement the exact same mechanism Babylon is now using for distribution, or one with similar behaviour / functionalities.
Creating this issue for tracking.
The text was updated successfully, but these errors were encountered: