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
Right now, the two types that govern funds going into the Treasury from inflation are EraPayout and RewardRemainder.
EraPayout returns how much of the payout should not go to validators, and RewardRemainder handles that amount. Of course it would be possible to change this implementation in a runtime upgrade to split it into several accounts, but ideally it would be configurable on its own. I would imagine the solution being a small pallet that maintains an AccountId => PerBill table and a dispatchable function to update the table.
This is especially relevant with the introduction of new sub-treasuries, e.g. for the Technical Fellowship. We might introduce a new collective and want to update how remainder funds are distributed. For example, we could have:
Account
Amount
Tech Fellowship
5%
Collective B
5%
Collective C
7%
Main Treasury
83%
If a new collective (D) wants to transition from one-off Treasury proposals to a steady influx of funds, a proposal could call (e.g.) set_distribution_table(new):
Account
Amount
Tech Fellowship
5%
Collective B
5%
Collective C
7%
Collective D
2%
Main Treasury
81%
The text was updated successfully, but these errors were encountered:
Right now, the two types that govern funds going into the Treasury from inflation are
EraPayout
andRewardRemainder
.EraPayout
returns how much of the payout should not go to validators, andRewardRemainder
handles that amount. Of course it would be possible to change this implementation in a runtime upgrade to split it into several accounts, but ideally it would be configurable on its own. I would imagine the solution being a small pallet that maintains anAccountId => PerBill
table and a dispatchable function to update the table.This is especially relevant with the introduction of new sub-treasuries, e.g. for the Technical Fellowship. We might introduce a new collective and want to update how remainder funds are distributed. For example, we could have:
If a new collective (D) wants to transition from one-off Treasury proposals to a steady influx of funds, a proposal could call (e.g.)
set_distribution_table(new)
:The text was updated successfully, but these errors were encountered: