Runtime DAOs

[bedeho]

Background

Using tokens as a way to finance creative projects and also reward early evangelists and community members has been a long standing idea in the crypto space, with attempts such as Smart Media Tokens and TatianaCoin. The idea is to turn a creative project into something where a community of token holds can vote on key governance decisions about how to manage the project, and possibly also receive a share of any value captured by the project.

Goal

Introduce DAOs with their own governance token, in the form of a new runtime module daos, which can act in the Joystream chain, primarily in the content directory & storage system at this point, but in the future they may act in any part of the system where normal memberships can, so stand for council, make proposals and so on.

Requirements

• Must be implemented as a native runtime module.
• There is no supported suitable asset protocol to use which supports minting new tokens over time so we must build it in.
• Has to be purely event based, no timers, no iteration, because we want an unconstrained number of DAOs, each having an unconstrained number of stakeholders and proposals.

Governance Token

Each DAO has an associated governance token, which is a fungible asset controlled by normal substrate accounts, and with normal currency semantics. It has an issuance, and an issuance policy, set when the token is created, which either freezes the issuance upper bound, or which allows new tokens to be minted by the DAO. In either case the issuance does decline when tokens are burned. Tokens can also be locked for the purpose of participating in the governance process of the DAO.

In the v2 of these DAOs we will introduce the capability for DAOs to buy back and burn the governance token on the open market in exchange for JOY tokens in the treasury, which itself is described in the next section.

Metadata

All DAOs have the following metadata which aid

• An immutable handle.
• A mutable title.
• A avatar image.
• A description of the purpose of the DAO.

Treasury

Each DAO also controls a pool of native JOY tokens, called a treasury, and can spend from this pool to any Substrate account. In the future this pool will be credited for with revenue shares from content owned by channels owned by the DAO. The treasury can also be credited by any normal

Operator

Each DAO has up to one explicit member set as the operator of the DAO. This operator is responsible for conducting various ongoing tasks in the DAO, such as possibly managing any channels under the control of the DAO.

The operator receives rewards in the governance token over time into a reward account. Importantly, the rewards are not automatically paid out, as this would not scale as the number of DAOs increases. Hence a pull based method is required, e.g. similar to this:

#1305

but be aware that this issue is about a more complex situation, the key point is just that its pull based periodic payments, so use it as inspiration.

Actions

All DAOs have the same set of things they can do in the Joystream system, called actions. It is a static list, and it deals both with the controls of the DAO itself, but also interacting with the rest of the runtime and system. Here are some example actions

• Change the operator.
• Update reward terms of the operator.
• Update the DAO metadata.
• Spend from the treasury to some account.
• Mint new tokens to some account.
• Upload something to the storage system.
• Delete something owned the storage system.
• Creating a channel in the content system.
• All actions an owner of a channel can do in the content system.
• Update action settings.

The proposal system, described later, allows the governance process of the DAO to trigger any such action. Some subset of actions may also allow the operator to trigger an action, and there are so called action settings in each DAO which describe this.

Creation

DAOs are created by any member, and creating a DAO reserves you the right to set the initial operator. The token is created at the same time as the DAO, and this requires both the issuance and and the issuance policy. All initial tokens are set to be owned by the operator. Lastly, the initial action settings are also set during creation.

Proposal System

The proposal system in the DAO is the means by which the token holders exercise governance over the operation of the DAO. The system process proposals, which are propositions about executing specific actions in the DAO, so there is one proposal type for each action available. Each type as its own values for the required quorum and threshold for passing.

Proposals

Each proposal is made up of the following set of properties when first created

• Type: What type of action is being triggered.
• Parameter Values: Values for the parameters of the given action.
• Proposer: The member proposing the proposal.
• Stake: Some quantity of the governance token is locked up for the duration of the proposal life-cycle. The stake does not count towards the outcome, and must be an exact amount which is identical across all proposals. The only purpose of this stake is to induce proposals to clean up their proposal from the blockchain state when it is over.
• Metadata: Raw metadata field which can provide rich human friendly explainer payload, with such things as titles, descriptions, etc.

Stages

A proposal has the following stages

• Announced: This is the initial stage of a proposal when created. During this stage the only action which can occur is that the proposer may withdraw the proposal, removing it from the system, this is not possible after this stage.
• Voting: This is the next stage, during which any token holder may vote on the proposal. The impact of a vote is weighted by how many tokens are locked, and the quorum and threshold semantics are the same as in the normal proposal system.
• Gracing: This is a quiescent stage where nothing can happen, and the final tally will be publicly available, and therefore the outcome.
• Ready: At any time, anyone can tell the proposal to execute - if it passed, if it did not pass, then nothing is executed. In either case, the initial stake is unlocked. The proposal may succeed or fail, depending on whether business logic involved in executing the action is compatible with the state of the system at the time of execution.

The length of each stage is hard coded, but possibly different for different types.

Voting

When voting, you vote as a member, this means the account holding the tokens must be bound to the membership up front. A single account can vote at most one time on a given proposal, however, it can simultaneously be used to vote on an unlimited number of proposals. Voting entails locking up some quantity of funds until the Ready period begins, at which point a second transaction is needed to remove a given lock. This means you may need to send multiple such transactions over time, for the same account, if you have used it for multiple proposal votes. Funds locked for staking for proposals can also be reused for voting. Lastly, a vote is either for or against the proposal passing.

Fundraising & Buy-back Burns [RnD Missing]

Two kinds of actions are needed, but no design has been conceived.

• Fundraising: This is the act of minting new tokens and auctioning them off for JOY, which ends up in the treasury. This should only be possible a single time in the very beginning of the life time of a new DAO with a fixed issuance policy.
• Buy-back & Burn: This is the act of buying back governance tokens from the open market in exchange for JOY in the treasury, and burning the obtained tokens.

There are different auction types worth looking into, multi unit auction, dutch auction, reverse dutch auction, etc. Doing these within our computational constraints, and also without being badly vulnerable to attacks or fraud, will require some care. The primary concern here is a small faction of stakeholders, or even the operator, setting up one of these quickly and with very bad terms, and thereby exploiting the rest. Long announcement and grace periods can help ameliorate this, and ultimately intervention from working group if there is sufficient time to block.

DAO Working Group

There will be a DAO working group which can intervene in the operation of any DAO by specifically blocking a proposal at any stage of its life-cycle prior to being executed.

┆Issue is synchronized with this Asana task by Unito

[mochet]

This sounds very interesting.

Question: Is there some limit for membership? or can it be assumed these runtime DAOs would be capable of handling hundreds or thousands of members?

[bedeho]

This will be unlimited under this design.

[mochet]

I had some questions about some areas I don't understand fully and some thoughts:

• If someone buys a DAO's tokens on the open market and has membership will they gain voting rights? Or is this locked to only the initial investors, while trading in DAO tokens would be some form of speculative investing?
• If I understand correctly, the treasury is just a normal account, so any user or council spending proposal could contribute funds to the treasury?
• If I understand correctly, there is some minimum number of tokens held to participate in the voting process?
  • Is this system something like 10,000 tokens per vote (this meaning users who do not hold a certain amount of tokens are incapable of voting?)
  • or is it 10,000 tokens = 10,000 votes?
• Are the avatar/description also mutable? Would these be controlled by proposals or the operator?
• Can a DAO create/own/manage a playlist?
  • Could a potential example of proposal use to be to add an already existing piece of content to a playlist?
• The treasury contains JOY tokens, does it also contain the DAO's own token?

[bedeho]

If someone buys a DAO's tokens on the open market and has membership will they gain voting rights? Or is this locked to only the initial investors, while trading in DAO tokens would be some form of speculative investing?

They will.

If I understand correctly, the treasury is just a normal account, so any user or council spending proposal could contribute funds to the treasury?

Correct.

If I understand correctly, there is some minimum number of tokens held to participate in the voting process?

No minimum, this is a pure coin vote, so your vote is weighted by your share of tokens voting. I guess I should have stated this explicitly, will update! Thanks!

Are the avatar/description also mutable? Would these be controlled by proposals or the operator?

They are mutable, proposals control everything, but operator could possibly also update this if the action settings are setup that way for a given DAO.

Can a DAO create/own/manage a playlist?

A DAO an do everything that any member can do in the content directory, so it can create lots of channels, publish videos and playslists under tthose channels etc. One thing it cannot do, in this proposal, is to create a new DAO :D This just seems too meta and possibly confusing, you could get long chains of DAOs owning each other, even ending in a closed loop! DAO A owns part of DAO B which owns part of DAO C which owns part of DAO A.

The treasury contains JOY tokens, does it also contain the DAO's own token?

Only JOY, governance tokens can be minted at will.

[mochet]

Overall this sounds like such a cool idea, can think of a lot of potential uses.

Another question: When we look at the upload action, is the proposal creator rewarded in any way? (besides the value of the token potentially being increased by rewards being paid in JOY to the treasury?) If I understand it correctly, there is currently not, so if a successful upload proposal creator wanted to get paid, they would have to create a separate spending proposal?

[bedeho]

There will in general be creator rewards for channel owners, this will be part of the incentive to publish under a channel, whether the channel is owned by a single member or a DAO. When the owner is a DAO, the JOY reward goes into the treasury, making it a shared asset of the stakeholders of that DAO. This means the value of. successful upload is captured according to governance token ownership in the DAO, not who did the upload. Incentivizing the upload act itself is not directly done, however the operator does get a recurring reward, and would be best equipped to do this.

[mochet]

When it comes to proposals, this issue mentions that all proposals will have an equal stake requirement...
Some quantity of the governance token is locked up for the duration of the proposal life-cycle. The stake does not count towards the outcome, and must be an exact amount which is identical across all proposals.

Questions:

• Who sets or how is the proposal stake requirement set?
• Can it be changed after initial creation of the DAO via a proposal?
• I see no mention of slashing a proposal creator, does this mean there is no slashing function on these DAOs?

A separate question:

• Is it possible to give proposal creation a cost? (meaning users have to burn tokens to create a proposal regardless of if it passes/fails). This has no use case for creating spending proposals, but may have some very interesting use cases for uploading videos or adding videos to a playlist.

As an example: A user creates a proposal to add a video to a coolDAO owned playlist, it costs 20k coolDAO tokens to create this proposal, and whether it passes or fails, the tokens for proposal creation have been burned.

There are several examples I can think of to do with advertising and communities where having to spend to create a proposal would spur far more creativity. I guess that when a user is submitting content they think is good enough to a DAO channel/playlist, there would be some risk of failure rather than just stake to stop spamming--especially if there is no form of slashing, it would mean people who create the proposals have enough interest in submitting their proposal to lose tokens in the short term.

[bedeho]

Who sets or how is the proposal stake requirement set?

I guess this could be a DAO creation parameter, but it was assumed to be constant here.

Can it be changed after initial creation of the DAO via a proposal?

There is an exchange rate volatility issue which could justify that, can be added for sure.

I see no mention of slashing a proposal creator, does this mean there is no slashing function on these DAOs?

Not planned here, we have to try to keep this a bit simpler than the overall proposal system, not least due to engineering time, but also because the coodination for a single purpose DAO like this is not as critical as the whole platform system.

Is it possible to give proposal creation a cost?

Are you referring to governance token cost or JOY cost? You have to pay normal base transaction fees currently only. I did not understand your argument for why having greater costs would spur more usage, seems reversed.

[mochet]

Are you referring to governance token cost or JOY cost? You have to pay normal base transaction fees currently only. I did not understand your argument for why having greater costs would spur more usage, seems reversed.

This is a bit hard to explain in terms of creating more usage, but there are other elements I can easily explain now.

Lets say you have a DAO that manages a few playlists or channels. If a user submits content via proposal that the token holders of that DAO there is no disincentive for users to not try and resubmit the same content over and over again.

As another example, lets say you have a DAO that owns a serious channel about cryptocurrency. A user buys enough tokens to create a proposal and then submits a very low quality video (think something along the lines of Elon Musk Twitter crypto airdrop scam). Even if the proposal is rejected they can still submit the same proposal immediately afterwards.

[mochet]

Also, in terms of advertising, having a proposal type cost a certain amount is an important use case for having proposals have a cost associated with them.
For example, if a company or brand has some advertising space linked to a channel/playlist, they could make a proposal cost some amount of tokens to create.

[mochet]

One additional thought I had regarding runtime DAOs is the possibility of a storefront that the DAO can manage, in more broad terms this would be aimed at expanding the number of ways in which users can contribute to a DAOs treasury and perhaps receive some kind of creative reward (and not necessarily just a DAO's tokens). The storefront would be a customizable page that the DAO can manage and list certain items on. Ideally the storefront would take JOY as payment, adding to the treasury of the DAO (where applicable)

Examples:

• Linking to a bounty in the bounty system that would fund the creation of a new podcast episode, so users can contribute funds towards the production of it (this would be an alternative use of the bounty system)
• If NFTs are ever implemented, there could be special badges available for one time or repeat supporters at some level (in some ways similar to https://unicode.org/consortium/adopted-characters.html)
• The DAO could list recent episodes or music videos that the DAO was responsible for funding/producing, and users could tip towards the video, adding toward the DAO's treasury (if they didn't receive an NFT or badge, maybe there would be someway to list the amount of support a user has given towards certain videos)
• If paid playlists are implemented, the DAO could list the playlists available for users to pay for listing content (this has a wide range of use applications)
• Some kind of unique reward item that the DAO can produce (an example would be a customized avatar being made for the paying user)

Also, since I mentioned bounties, would it be possible for the DAO to list bounties on the bounty board? As I understand this will be outside of the proposal system, but I can imagine a number of use cases where a DAO could list specific bounties (ex. "make a new avatar for "coolDAO28" or "make a new theme song for our DAO")

[bedeho]

I think a storefront is interesting, but wouldnt it make more sense to couple to channels, or even have as standalone concepts, why couple it to DAOs specifically? DAOs could obviously own them as well, but does not seem inherently tied to DAOs any more than channels are.

[mochet]

I think a storefront is interesting, but wouldnt it make more sense to couple to channels, or even have as standalone concepts, why couple it to DAOs specifically? DAOs could obviously own them as well, but does not seem inherently tied to DAOs any more than channels are.

Yes it would make more sense, I didn't really think about it for normal channels, but that would be much better. The reason I mentioned it tied to DAOs is I was trying to think of multiple ways a user could contribute to a DAO without necessarily investing, some sort of trade of tokens<>creative products. The same could easily apply to users/channels and open up more diverse ways of supporting content creators on the platform.

[mochet]

Idea: multiple choice proposals
One of the interesting parts about runtime DAOs is that it sounds like each will be capable of building their own decision making consensus. The bandwidth of this is limited by quorum requirements. So 10x individual text proposals would require a significant amount of quorum for all to be considered.

Some decisions may have not need anything more than just accept/reject, but in creative spaces having some mechanism for voting for one option out of several would be very interesting.

I'd say that having a proposal type which has multiple possible outcomes may be worth investigating.

If runtime DAOs are structured correctly, they can have internal rules implemented which use multiple choice proposals well. This would significantly increase the speed of decision making processes when there are multiple outcomes.

Obviously the forum will eventually have polls, but this will never be equal to a proposal.

[bedeho]

Can you provide a list actual proposals where this would be relevant? The Actions section above are the only proposals that are supported in the current plan, and none of them fit this bill. Do you specifically mean a multiple choice text proposal only, because it would probably not be justifiable to try to generalize the whole decision engine and quorum rules just to cover this one case.

[mochet]

Can you provide a list actual proposals where this would be relevant? The Actions section above are the only proposals that are supported in the current plan, and none of them fit this bill. Do you specifically mean a multiple choice text proposal only, because it would probably not be justifiable to try to generalize the whole decision engine and quorum rules just to cover this one case.

Sorry should have stated that I was only really talking about text proposals.

[mochet]

Another use case:
One problem with the council seems to be that making decisions to fund creative work seem to be problematic. The council is already tasked with decision making processes regarding budgets, infrastructure and rules so these creative decisions appear to be difficult and it may be easier to push them onto council-funded runtime DAOs.

One thing interesting from the real world are "art councils" or "art juries" as described here: Joystream/community-repo#104 (comment)

In this way a specific runtime DAO for funding short videos or documentaries could have some specific periodic budget assigned to it from the council, and the council wouldn't be involved in creative decisions stemming from that budget.

[bedeho]

But why can't just the content lead do this? at least at the moment, seems like that lead is not doing that much, and this is something he/she can fund on their own, without having to convince a council?

[mochet]

But why can't just the content lead do this? at least at the moment, seems like that lead is not doing that much, and this is something he/she can fund on their own, without having to convince a council?

I'm more referring to in a mainnet situation where the budget for content may be considerably large, having that kind of decision just fall on one person would be a problem for many reasons. IMHO on mainnet, if we have a pool of dozens-hundreds of curator workers, the curator lead's time would be filled with just managing the hiring/reporting processes.

And also I'm not clear quite yet on how the reporting (I'm talking about users reporting videos that go against the rules, which we currently have no framework for) process would work, and how much workload that may add to the curator workload in general.

But the idea of just putting these creative decisions towards a single person seem very limited in the future, and even right now we have no established way for the curator lead to do discretionary spending that I'm aware of.

[bedeho]

This seems like a better solution #3907