A DAO is an entity unto itself. It has wants and resources.

In order for such a DAO to get what it wants, it needs ways to advocate for its wants and allocate its resources.

The first resource a DAO can manage is how much it appreciates the various entities that helps it with its goals. We'll call this Reputation.

The purpose of this approach:

• No DAO should be without a contribution tracking and reward system, even pre-token

• In order to get things done efficiently and in a decentralized way, DAOs need internal labor markets as a replacement for hierarchies

• DAOs (and their internal mechanisms) should be very easy to spin up, so we can rapidly hypothesize, experiment, and learn

• DAOs should have a death mechanism, so we can decisively move on from failed experiments

1. Summon the DAO

In the summoning contract, Summoners set:

• Parameters about how the DAO will allocate its resources

• A Genesis Task List: the list of things the DAO wants and is willing to allocate its resources to get (and how much, in the form of bounties)

Deciding to participate in summoning the DAO, and therefore supporting the parameters in the summoning contract, is the first (and possibly only) off-chain vote of the DAO. It is a unique and important moment.

Parameters may include:

• Reputational Requirements to join

• Reputation calculation algorithm (including broader web3 contributions) [this is it's own product too]

• Voting Mechanism

• Maximum Negative Reputation per Contributor [alt: starting reputation for Contributors]

• Maximum Allocated Reputation: the DAO should only be able to allocate X reputation before requiring the migration to a token

• Automatic Auction Curve: the rate used by the DAO to increase bounties for things it wants that it doesn't yet have

• Death Parameter: the condition under which the DAO should ragekick everyone and shut itself down

• Reputation Buyout Price: the price that the DAO is willing to repurchase reputation points, prior to launching a token

2. Propose -> Decide -> Commit -> Execute -> Evaluate Loop

The way the DAO accomplishes its goals is in the following loop:

• Propose:

  • Members of the DAO (with sufficient Reputation) are able to make proposals in the format "I think the DAO wants [goal or task] and is willing to pay [bounty price] for that"

• Decide:

  • Other Members (with sufficient Reputation) vote to pass this proposal, adding the goal or task to the list of things the DAO wants

  • During summoning, this list is propogated by the Genesis Task List hardcoded into the parameters of the summoning contract

  • The list of things the DAO wants is surfaced to Members and potential contributors as a Task List [Note: probably its own product / composable lego block]

  • According to the Automatic Auction Curve parameter set in the summoning contract, the bounty for the goal or task increases automatically, the longer that the task remains outstanding (i.e. price discovery for bounties)

• Commit:

  • A contributor (including but not limited to DAO members) can commit to completing a goal or task by a specific date, at the currently stated bounty price

  • They do so by staking Reputation on the task, relative to the amount of Reputation the bounty would reward

  • Bootstrap by allowing contributors to go negative (with some limit), but the DAO will not allow contributors with negative balances to stake

  • If they don't complete the task by the date, they are slashed (by vote of the DAO members)

• Execute:

  • The contributor (can be an individual or a DAO) has agency to complete the task

• Evaluate:

  • Upon completion of the task, the contributor submits their work to the DAO

3. Token Launch & Retroactive Reward

Eventually, the DAO will likely decide that it needs to launch its own token. Doing so will empower the DAO with resources that are more powerfully incentivizing to future contributors.

In essence, Reputation is a pre-token incentive system that punts on the challenges of launching a token, including tokenomics, mechanism design, and implementation. Because the DAO is self-constructing, it should be able to leverage its resources in the Reputation-based system in order to reward contributors for their work building the token system.

However, because Reputation is a pre-token system, the DAO should only be able to award a maximum amount of Reputation across the system before it is forced to launch a token (covered by the Maximum Allocated Reputation parameter).

One of the most important parts of the token launch is the Retroactive Reward to Reputation holders. There needs to be a translation mechanism that is agreed upon by the DAO members. However, because this the pre-token reputation system will not benefit from the work of the contributors who design and implement the tokenomics, the translation should not be 1-to-1, and should not be obvious to contributors, as to not be gameable.

4. Death Mechanism

Many DAOs will start as experiments. Life itself experiments by creating many of the same species in order to find adaptive fit within dynamic environments. And these individuals both reproduce and die, and important part of evolution. So too should DAOs be able to die when they are not adaptive.

There's another reason for this: DAO Members and Contributors should be clear on the conditions under which contributing to the DAO is no longer worth their time.

As such, one of the parameters in the summoning contract is the Death Parameter: the condition under which the DAO should ragekick everyone and shut itself down.

One way to approach this would be to set a minimum threshold of Reputation that needs to be allocated over a given time period.

For example:

• Tasks have bounties worth ~1000-5000 Reputation each

• The Death Parameter is set to 2500 Reputation per week, two weeks in a row

• If the the rewards for bounties completed in two weeks is lower than 2500 Reputation total each week, then the DAO will die

• Dying looks like ragekicking all members (allocating everyone their portion of the funds in the treasury, if any) and preventing anyone from using its contracts in the future

Originally published here.

A DAO is an entity unto itself. It has wants and resources.

In order for such a DAO to get what it wants, it needs ways to advocate for its wants and allocate its resources.

The first resource a DAO can manage is how much it appreciates the various entities that helps it with its goals. We'll call this Reputation.

The purpose of this approach:

• No DAO should be without a contribution tracking and reward system, even pre-token

• In order to get things done efficiently and in a decentralized way, DAOs need internal labor markets as a replacement for hierarchies

• DAOs (and their internal mechanisms) should be very easy to spin up, so we can rapidly hypothesize, experiment, and learn

• DAOs should have a death mechanism, so we can decisively move on from failed experiments

1. Summon the DAO

In the summoning contract, Summoners set:

• Parameters about how the DAO will allocate its resources

• A Genesis Task List: the list of things the DAO wants and is willing to allocate its resources to get (and how much, in the form of bounties)

Deciding to participate in summoning the DAO, and therefore supporting the parameters in the summoning contract, is the first (and possibly only) off-chain vote of the DAO. It is a unique and important moment.

Parameters may include:

• Reputational Requirements to join

• Reputation calculation algorithm (including broader web3 contributions) [this is it's own product too]

• Voting Mechanism

• Maximum Negative Reputation per Contributor [alt: starting reputation for Contributors]

• Maximum Allocated Reputation: the DAO should only be able to allocate X reputation before requiring the migration to a token

• Automatic Auction Curve: the rate used by the DAO to increase bounties for things it wants that it doesn't yet have

• Death Parameter: the condition under which the DAO should ragekick everyone and shut itself down

• Reputation Buyout Price: the price that the DAO is willing to repurchase reputation points, prior to launching a token

2. Propose -> Decide -> Commit -> Execute -> Evaluate Loop

The way the DAO accomplishes its goals is in the following loop:

• Propose:

  • Members of the DAO (with sufficient Reputation) are able to make proposals in the format "I think the DAO wants [goal or task] and is willing to pay [bounty price] for that"

• Decide:

  • Other Members (with sufficient Reputation) vote to pass this proposal, adding the goal or task to the list of things the DAO wants

  • During summoning, this list is propogated by the Genesis Task List hardcoded into the parameters of the summoning contract

  • The list of things the DAO wants is surfaced to Members and potential contributors as a Task List [Note: probably its own product / composable lego block]

  • According to the Automatic Auction Curve parameter set in the summoning contract, the bounty for the goal or task increases automatically, the longer that the task remains outstanding (i.e. price discovery for bounties)

• Commit:

  • A contributor (including but not limited to DAO members) can commit to completing a goal or task by a specific date, at the currently stated bounty price

  • They do so by staking Reputation on the task, relative to the amount of Reputation the bounty would reward

  • Bootstrap by allowing contributors to go negative (with some limit), but the DAO will not allow contributors with negative balances to stake

  • If they don't complete the task by the date, they are slashed (by vote of the DAO members)

• Execute:

  • The contributor (can be an individual or a DAO) has agency to complete the task

• Evaluate:

  • Upon completion of the task, the contributor submits their work to the DAO

3. Token Launch & Retroactive Reward

Eventually, the DAO will likely decide that it needs to launch its own token. Doing so will empower the DAO with resources that are more powerfully incentivizing to future contributors.

In essence, Reputation is a pre-token incentive system that punts on the challenges of launching a token, including tokenomics, mechanism design, and implementation. Because the DAO is self-constructing, it should be able to leverage its resources in the Reputation-based system in order to reward contributors for their work building the token system.

However, because Reputation is a pre-token system, the DAO should only be able to award a maximum amount of Reputation across the system before it is forced to launch a token (covered by the Maximum Allocated Reputation parameter).

One of the most important parts of the token launch is the Retroactive Reward to Reputation holders. There needs to be a translation mechanism that is agreed upon by the DAO members. However, because this the pre-token reputation system will not benefit from the work of the contributors who design and implement the tokenomics, the translation should not be 1-to-1, and should not be obvious to contributors, as to not be gameable.

4. Death Mechanism

Many DAOs will start as experiments. Life itself experiments by creating many of the same species in order to find adaptive fit within dynamic environments. And these individuals both reproduce and die, and important part of evolution. So too should DAOs be able to die when they are not adaptive.

There's another reason for this: DAO Members and Contributors should be clear on the conditions under which contributing to the DAO is no longer worth their time.

As such, one of the parameters in the summoning contract is the Death Parameter: the condition under which the DAO should ragekick everyone and shut itself down.

One way to approach this would be to set a minimum threshold of Reputation that needs to be allocated over a given time period.

For example:

• Tasks have bounties worth ~1000-5000 Reputation each

• The Death Parameter is set to 2500 Reputation per week, two weeks in a row

• If the the rewards for bounties completed in two weeks is lower than 2500 Reputation total each week, then the DAO will die

• Dying looks like ragekicking all members (allocating everyone their portion of the funds in the treasury, if any) and preventing anyone from using its contracts in the future

Originally published here.