Background

This has already been implemented in the content directory

#2365

Proposal

First some simple naming stuff. Lets refer to the act of using merkle proof as claiming, the event of having some amount credited to you in the merkle root as earned and the act of transferring funds from your channel account (read below) to some other account as withdrawing.

• Rename PullPaymentElement::cumulative_payout_claimed to cumulative_reward_earned.
• Rename ChannelRecord::cumulative_payout_earned to cumulative_reward_claimed.
• Add new withdraw_from_channel_balance extrinsic which allows the channel owner to actually withdraw funds from the channel account to some other account. It should not affect cumulative_reward_claimed, only balance of account. Collaborator members cannot call this, only owner.
• Add a new extrinsic claim_and_withdraw, which is an atomic invocation of claim_channel_reward & withdraw_from_channel_balance, but remember to only emit one new event. Collaborator members cannot call this, only owner.

Then the more substantive stuff:

• (Done by @ignazio-bovo ) Replace channel accounts from being optional external accounts to being hard-coded internal module accounts, one unique account per channel.
• Add proposal which can block all, and unblock, cashout attempts.
• Add an extrinsic, which lead can invoke, to block/unblock specific individual channels from doing cashouts (or revenue splits).
• Drop MaxRewardAllowed, semantics are not that useful, instead introduce a MaxCashoutAllowed, analogous to MinCashoutAllowed, which only looks at the actual cashout value, not the total. Neither value can be set by lead, only council through proposal below.
• Add council proposal to update merkle root, initiate payload upload to council storage bag, and extend to support simultaneously
  • possible new value for MinCashoutAllowed, not required.
  • possible new value for MaxCashoutAllowed, not required.
  • possible to credit content WG budget some amount, not required.
  • possible to automatically unblock cashouts if they current are blocked, not required, and if they are already blocked, there should be no error executing proposal none the less.
• A new council proposal for only setting MinCashoutAllowed & MaxCashoutAllowed, not updating the payout.
• Add mutation safe barrier.

Deployment

These changes will have sufficiently far reaching consequences w.r.t. query node, Atlas, etc., so that we will have to deploy in a runtime upgrad post Olympia.

┆Issue is synchronized with this Asana task by Unito