Joystream / joystream

Joystream Monorepo
http://www.joystream.org
GNU General Public License v3.0
1.42k stars 115 forks source link

Runtime: CRTs -- forced revenue splits #5141

Open mochet opened 4 months ago

mochet commented 4 months ago

Problem

Some creators/users have expressed a curiosity/desire that revenue splits should be an event that is triggered by the system somehow. The rationale for this seems fairly obvious to basically ensure that a channel does actually activate a revenue split at some point in the future, even though the channel owner cannot claim their own revenue until a revenue split is active there is still some mistrust that a channel owner may be lazy. This seems like a fair argument in favor of allowing this.

Solution

bedeho commented 4 months ago

Simplest sollution is to allow anyone to trigger splits when channel balance goes above a certain amount. I don't know if I think this is a good idea though, best to at least wait until some real number of people feel a creator is not behaving prosocially.

mochet commented 4 months ago

Simplest sollution is to allow anyone to trigger splits when channel balance goes above a certain amount. I don't know if I think this is a good idea though, best to at least wait until some real number of people feel a creator is not behaving prosocially.

That sounds like a very common sense solution, I wish I had thought of that! And agreed it is best to wait a while to see how things materialize with the feature first.

mochet commented 4 months ago

I suppose another potential solution may be for the $CRT holders to be able to stake their tokens to trigger a revenue split--and if n% of the CRT are staked then the revenue split is forced to begin.

mochet commented 3 months ago

This could actually be feasibly triggered by smart contracts

bedeho commented 3 months ago

This could actually be feasibly triggered by smart contracts

Smart contracts do not solve anything here. You need some trigger to cause the split, this can either be a user transaction, in which case whether its a smart contract or native runtime transaction is of no distinction. Alternatively one could do some sort of on-chain hook, like on_finalized for blocks, but this only works in the native runtime, not smart contracts, and it also does not scale as number of tokens increases, so not really an option.