Update beneficiary splits

As we discuses previously, certain accounts generate a profit through the primary and secondary sale of carbon credits. The way in which these beneficiaries gain their profit is through a split of the sale price of the tokens.

Current beneficiary split values:

Beneficiary entity and instance	Beneficiary split value
Validators (primary sale)	45.00%
Validators (secondary sale)	35.00%
Project owner (secondary sale)	10.00%

Example:

To best understand this let's say that trader A is trying to sell 120 carbon credits at a price of 5 MUINT (base substrate node asset) per credit to trader B. We know what 5 validators have supported the carbon credit batch to which the credits on sale belong to. In this case the total sale value of the carbon credits would be 600 MUINT. Considering that this is a secondary sale of the carbon credits, the project owner is entitled to a 10% profit gain from this trade (i.e. 60 MUINT) and the validators that have supported the carbon credit batch for the given tokens should receive 35% of the sale gains (i.e. 210 MUINT). Since 5 validators benefit from this sale, the 35% gains will be split 5 way, that is each one of them will get their fair share (i.e. 42 MUINT). In the end the seller will receive 55% of the initial sale price (i.e. 330 MUINT).

Penalty level notice

If any of the beneficiaries has a penalty level associated to them (i.e. their penalty level is greater than 0), then their gains will be divided by the associated penalty level percentage value. The remaining amount of the gains that should have gone to the recipient will subsequently go to the pallet.

Example:

Taking into consideration the previous example, let's say that one of the validators has a penalty level of 1 which is by default set to 167.00%. This means that they will receive only 25 MUINTs (i.e. the formula is as follows: 42 MUINT * 100 / 167). The remaining 17 MUINT will subsequently be transferred over to the pallet.

If a authority account wishes to update the beneficiary split, he/she can achieve this using the update_beneficiary_splits(new_beneficiary_splits), where the provided parameter will contain all of the new beneficiary split values. It is worth mentioning that this functionality will only accept objects that contain 3 values (similar to the previously mentioned table) and that the first provided value can't exceed 50%, as well as the sum of the last two values.