Scope
Update the structure of the table to work with all of the cases below.
Context
1.Council Incentives Rewards
Channels were initially designed to be paid with Payout Proposal. This involves minting tokens aka "claiming" within the allowance agreed by council and defined in a payload file (binary) added to storage system. Even though the rational field was populated in the human readable file, it was not possible to display the rationale at the time of payment. It was not a problem since in the MVP version we agreed to have an external tool displaying the payouts channels qualified for and executed, with rationale added there. Based on the recent update it became apparent that we are going to rely on the payouts tab entirely to inform channels. Wrt technical feasibility, it is possible to reveal the rationale field at the point of payouts being claimed.
Details on technical implementation are in this ticket:
What that means: we want to add rationale field to the table and accommodate rationale from the proposal payout payload. Rationale will only be revealed and populated after rewards are claimed (transaction of claiming rewards executed).
2. Private Transfers via Member remark used by App Operators (YPP programme)
We decided to allow direct payments from App operators to the channels, circumventing the payout proposal used for the DAO-driven incentives programme. It makes more sense for the YPP programme to go this way to increase reliability of payouts and since the channels are paid out from the Operator's funds reliance on council is unnecessary. It was implemented as member remark, where any member can execute payment to channel account with rationale, attribution to channel/ specific video. Now combined with the fact that Apps will be operating like channels from technical pov (on the runtime), the payouts to channels will be executed from the private accounts, that would be used to host proceedings from revenue splits.
Implementation was done here:
More context on this point is here:
What that means: We can show rationale for specific payments to channels done by operators.
3. Proceedings from NFTs:
English auction - when settled
Open auction - when finished (time elapsed)
Buy now - when purchased
4. CRT payouts
4.1 Revenue splits - Rev splits from the channel will be shown in this table once built as part of CRTs
4.2 Patronage - can be also shown here
4.3 Token direct sales - proceeds will show in this table once implemented.
┆Issue is synchronized with this Asana task by Unito
Scope
Update the structure of the table to work with all of the cases below.
Context
1.Council Incentives Rewards
Channels were initially designed to be paid with Payout Proposal. This involves minting tokens aka "claiming" within the allowance agreed by council and defined in a payload file (binary) added to storage system. Even though the rational field was populated in the human readable file, it was not possible to display the rationale at the time of payment. It was not a problem since in the MVP version we agreed to have an external tool displaying the payouts channels qualified for and executed, with rationale added there. Based on the recent update it became apparent that we are going to rely on the payouts tab entirely to inform channels. Wrt technical feasibility, it is possible to reveal the rationale field at the point of payouts being claimed.
Details on technical implementation are in this ticket:
What that means: we want to add rationale field to the table and accommodate rationale from the proposal payout payload. Rationale will only be revealed and populated after rewards are claimed (transaction of claiming rewards executed).
2. Private Transfers via Member remark used by App Operators (YPP programme)
We decided to allow direct payments from App operators to the channels, circumventing the payout proposal used for the DAO-driven incentives programme. It makes more sense for the YPP programme to go this way to increase reliability of payouts and since the channels are paid out from the Operator's funds reliance on council is unnecessary. It was implemented as member remark, where any member can execute payment to channel account with rationale, attribution to channel/ specific video. Now combined with the fact that Apps will be operating like channels from technical pov (on the runtime), the payouts to channels will be executed from the private accounts, that would be used to host proceedings from revenue splits.
Implementation was done here:
More context on this point is here:
What that means: We can show rationale for specific payments to channels done by operators.
3. Proceedings from NFTs:
English auction - when settled
Open auction - when finished (time elapsed)
Buy now - when purchased
4. CRT payouts
4.1 Revenue splits - Rev splits from the channel will be shown in this table once built as part of CRTs
4.2 Patronage - can be also shown here
4.3 Token direct sales - proceeds will show in this table once implemented.
┆Issue is synchronized with this Asana task by Unito