Democracy DAO - A collective decision making platform for democratic organizations

[Eyal]

Democracy DAO

A collective decision making platform for democratic organizations

The goal of this document is to outline Democracy DAO, a blockchain DAO for political organizations, namely NGOs, labor unions, activist groups and political parties. The starting point is DAOStack’s set of tools as deployed for Genesis Alpha, and modifications are suggested based on interviews I conducted with labor union and NGO leaders in Israel in September and October 2019.

The document was prepared with funding from Genesis DAO, vie a successful proposal.

These are the organizations I interviewed:

1. Koach LaOvdim—Democratic Workers’ Organization. A labor union with some 20,000 members, and 100 member unions.
2. Israel’s Social workers union with 13,000 members.
3. Green Course, an environmental activist organization with several hundred members.
4. Ofek Credit Union. A credit union with close to 6000 shareholders. This is not a political organization per se but it was created in part by activists and have an NGO type constitution.
5. Beit Ha’am. An activist group, forming a physical space for social and political activities.

The largest organization, the labor union, has a budget of several million NIS coming from member fees. The smaller, environmental organization has funding coming from outside donations. The labor union has important votes every week. The smaller organizations have only a handful of meaningful decisions per month. Decisions are reached either by management, typically a small forum, or large events held several times a year. Online voting technology is used when members cannot attend an event and make a special request to have their votes count.

All these organizations have ID verification for all members, and most collect member fees. Collective decision making, censorship resistant input from members, and full transparency – all built-in strengths of blockchains and DAO technology – are valued as part of their ethos.

Must have features

This list of minimal requirements for adoption within our target audience includes features that already exist in Arc and Alchemy, and features that need to be developed from scratch. Additional information is available in dedicated sections.

Currently available

1. Members input. All members can offer input and have a voice in the organization.

2. Reputation based voting gives more power to members who contribute to the organization.

3. Fund management.

Needs to be developed

1. Membership integration. Integration with any existing system the adopting organization uses for registering members, to create DAO members.

2. Documents. A document repository to hold all the organization’s documents, with a framework to allow viewing and editing permissions.

3. Supermajority: the organization should be able to automatically set a special majority threshold for important decisions.

4. Departments. All the organizations I interviewed have several departments (regional, topical, and more). We need to implement a protocol for Parent / Children DAOs. For example the main organization’s DAO can be the All Members DAO, while a regional DAO would have a subset of the members in the main DAO.

5. Actions the DAO performs in response to a proposal. The current DAOStack set of tools allow several actions to be done automatically by passing a proposal (i.e. transferring funds). The Democracy DAO software would need to implement more such actions.

6. Transparency. Fully transparent proposal, voting and boosting history, unless the DAO configures otherwise. DAO stats with information on voting and boosting blocks would have great value, assisting members in their decision making process and measuring true decentralization.

7. Payment integration. The organizations I interviewed do not use crypto. Therefore we need to integrate with existing platforms for fiat payments, and allow staff and members to use a familiar environment. Crypto and blockchain will be used under the hood.

8. Notifications. Since membership is not pseudonymous the system should offer notifications for users, such as getting started, or when a proposal is voted on, etc.

9. Localization. To allow people to use their writing skills using their own language, in a familiar language environment.

10. Privacy technology integration (i.e. Enigma secret contracts) for organizations that need to keep certain decisions private.

11. Representatives are bound to the organization.

12. Good to have

13. Gamification. Gamify reputation to make it more exciting and desired.

14. Private voting.

Product Outline

Throughout the following sections I made several choices between decentralization, and trusted setups. All of them need further thought, specifically regarding the question what can be done only by the DAO, and which permissions does an admin have.

DAO creation and initialization

There are several steps an admin needs to do when starting a DAO, including creating departments, setting DAO defaults, and adding members. The admin can start the process, save it, and come back to it later.

Before the DAO is initialized and becomes operational, and assuming fiat integration the payment method has to be set, and a first payment needs to be confirmed to cover for the blockchain fees.

DAO Creation

1. Select a title, description, token name and symbol.
2. Add members and their initial reputation. (see dedicated section)
3. Set up departments and add members to departments (see dedicated section)
4. Set up the founding documents. (see dedicated section)
5. Set up dispute resolution mechanism. The suggested default is a department of members trusted by the organization. (see dedicated section)
6. Set up the DAO defaults.
7. Add DAO tags.
8. Negative actions department. Negative type actions, such as suspending, removing a member, or slashing member’s reputation can only be created by a select group of members. The DAO creator sets up this department. The goal is to prevent infighting, i.e. members creating negative type proposals against each other.

While the admin sets up all of the above his/her data is saved to a traditional database. There’s no need to send it to the blockchain until all steps are finalized.

DAO deployment

1. Payment method is selected, and the first payment to the software company is confirmed. (see payments section).
2. Under the hood the needed blockchain account(s) are created.
3. The admin finalizes all the steps done in DAO creation. The UI needs to inform the admin that everything could still be changed in the future but from now on the interaction would be with the blockchain.
4. The last step deploys the DAO and all its components to the blockchain, and notifies and admin that everything is set up and ready to go.

Initial cost of creating a DAO

1. Cost of deploying the DAO to the blockchain.
2. Cost of adding X number of members, their initial quota of votes and proposals.
3. Cost of creating X number of proposals.
4. Democracy DAO licencing fee.

DAO actions

The current arc & alchemy can perform several actions on behalf of the DAO as a response to a successful proposal. The Democracy DAO would require several others.

1. As in the current alchemy

2. Transfer crypto funds from the DAO holdings to individuals.

3. Assign, increase, slash, or remove reputation from members.

4. Suspend or Remove members. Suspension would stop a member from proposing and voting, and removal would also zero out their reputation. Consider allowing this action to be done either via a proposal, or as an admin function.

5. Open a department (sub DAO). This means that the proposal would specify the department title, description, founding document and founding members.

6. Suspend, or close a department.

7. Supermajority actions. Certain proposals, and other actions would require a larger than 50% majority in order to pass.

8. Documents

9. Editing permissions. This means that a document owned by the DAO, such as the DAO constitution can only change via a proposal with a special majority threshold.

10. Viewing permissions. This means that some documents should only be viewable to members of the organization, or members of a department within the organization, while others can be public.

11. Electing organization officials

12. Select officials through a vote. One possible implementation would move a member from one department to another vie a proposal. One example is the director being the only member of a Director Department. Or the administrative staff becoming members of the Admin Department with certain permissions in the main DAO.

13. Suspend or remove organization officials such as the director, or others.

14. Sign agreements with organizations or individuals outside of the DAO. See Binding Officials to the DAO.

Admin Functions

Not everything in the DAO can, or have to be decentralized. For the sake of day to day efficiency an admin, selected by the DAO, should be able to perform certain administrative tasks.

1. Open a department. Certainly at the DAO Creation stage.

2. Add members.

3. Note: this gives the admin control over the list of voters. Maybe it should be available only by vote in a larger department, such as management. In this case adding members in bulk should be available.

4. Suspend members.

5. Note: same as in 2.1.

6. Some proposals may be created only by an admin. TBD.

Members, ID Verification, and assigning initial reputation

KYC & ID Verification

1. All the organizations we interviewed formally register members and verify their identity before allowing them to vote. Anonymous, or pseudonymous membership is not allowed.
2. The organization will decide on their own which type of ID verification they need. It would be done outside of our system.

Registration & Integration

1. Once membership fee is paid a member can be added to the DAO by the organization’s staff via a standard registration form, or in bulk by using an agreed on format.
2. Our software would be able to load members from an existing database and create an identifier to connect the organization’s technology to the DAO technology.
3. Members can also be added by a proposal via a DAO Action.

Initial reputation & proposing quota

1. A new member gets an initial amount of reputation needed for voting, as configured by the DAO. See DAO Settings.
2. New members also get a quota of proposals and votes per month, as configured by the DAO.

Suspending a member

An admin, or a successful vote can suspend members power to create proposals and vote.

Removing a member

Same as above, but now the member is marked as deleted.

Member quitting

Leaving a labor union, or an activist group can be as simple as stopping membership fees. Leaving a credit union is a highly involved process. Each organization would perform their own process internally, then perform remove the member from the DAO.

Member Screen

Members can view and edit their personal profile, and perform payment related actions.

The profile screen includes the following, and is viewable and editable by the member.

1. Name.
2. Title.
3. Contact information.
4. Notification preferences.
5. Reputation.
6. Proposing and voting quota.
7. Departments membership.
8. Proposal history.
9. Voting history.
10. Voting blocks. Whom did the member vote with? Who voted for and against her proposals?
11. Payment method.

Login

Only logged in members can perform actions, create proposals and vote. We would use any of the available login systems.

Notifications

1. Once registration is complete new members get a welcome email with a quickstart guide on how to use our system.

2. All other notifications, in email, on the site, or push would be optional.

3. Track your proposals.

4. Track your votes.

5. Track proposals in your department, or other departments in the organization.

6. Track documents and edit suggestions.

Proposals

Same as in Genesis Alpha, and enhanced to include our Democracy DAO Actions.

Only logged in members can create proposals.

Negative type actions such as suspending, removing a member, or slashing member’s reputation are only permitted to a special department, whose members are selected by the DAO. The goal is to prevent infighting.

Viewing and editing a proposal’s screen is available for the proposal creator in draft mode, and when published to all members (privacy tech needed), or public, as configured by the DAO.

Proposal screen

1. The current alchemy covers most of the required elements.
2. Other elements would be added specifically for each DAO Action. The proposal creator can also add from a list of DAO tags.
3. Proposals requesting funds have to specify the amount of advance to be paid immediately, while the rest of the money is going to an escrow account and is paid upon completion. See Defaults section.
4. Once the user finalizes the proposal she gets a two types of confirmations. The first when data is saved in the caching layer, and second when it is saved to the blockchain. Only at this point the proposal becomes public.
5. Error handling includes notifications to the user, the admin and the technical staff with full description.

Proposals search

A large, active organization creates many proposals. Finding them requires a detailed search page. We suggest the following criteria.

1. Search proposals by member
2. Search proposals by several members
3. Words in title
4. Tags
5. DAO Action
6. Amount of money requested
7. Amount of reputation requested
8. Department, or several departments
9. Proposals regarding documents
10. Proposals by management
11. Passed / failed proposals
12. All the above filtered by date range

Special Majority

Certain proposals would only be allowed to pass if a special majority of the DAO votes for them. The DAO can configure a threshold for each such proposal.

If the special majority is not reached and the DAO wants to change the threshold or remove it entirely it could be done via a proposal. See Defaults section.

If a DAO cannot reach special majority for major actions, and cannot get enough support for changing the defaults it should go through an internal process of dispute resolution, or get forked.

Dispute Resolution

A mechanism for settling all disputes. The recommended default is to set up a dedicated department with randomly selected members, and periodically replace them. Another option could be an Ethics department, mentioned below as part of the environmental activist organization.

Departments

All the organizations we interviewed have several departments, including regional branches. Some organizations have an oversight department, and an ethics department, which in the environmental activist organization is responsible for deciding whom to accept donations from.

There are also ad hoc departments, for example for creating an event in the physical world, or managing a document.

Democracy DAO should be able to reflect the organization’s existing, and developing structure.

Creating and Managing departments

1. An admin can add a new department with the following:

2. Title

3. Description

4. Founding documents

5. Members

6. In addition the DAO can decide to start a department via a DAO Action.

7. Once the department is created it’s up to its members to change any of the above by using a proposal.

8. The DAO can suspend, or close a department via a DAO Action.

9. Upon registration of new members an admin can add them to the departments they belong in.

10. Members can be part of any number of departments. They carry their reputation with them; in other words there is no special reputation per member in a department. (see more below.)

11. A department can be private, in which case only members of the organization can view it.

All Departments Screen

1. The DAO software offers a screen for viewing a list of all the departments in the organization. The screen is available for the entire public unless otherwise configured by the DAO.
2. Departments can be sorted alphabetically, by number of members, number of proposals in a time frame, and organizational power (how much rep the department members have).
3. Each item in the list links to the department’s individual screen.

Department autonomy

1. Each department is its own DAO. It has autonomy to decide on all issues concerning the department. Voting, proposing, creating and editing documents are handled just like they are in the main DAO.

2. A department can accept a member via a proposal.

3. A department can suspend or remove a member via a proposal.

4. A member can leave a department at any point without creating a proposal.

5. Members have the same reputation in all departments they are part of. For example, if a new member gets 0.5% reputation when registering, then joins his regional, and topic of interest departments, she carries the 0.5% into both of them. (This may change in the future but it seems like the simple, intuitive solution that would make adoption and the whole concept of reputation based voting easier to understand.)

6. A department member can create a proposal and assign it to the department only. Only members of the department can vote on this proposal.

7. A department can create a proposal on behalf of itself in the large DAO, thus committing all its members to a yes vote. (need to think this over).

Individual department screen

1. Title

2. Description

3. Status (open or closed)

4. Date opened

5. Date closed

6. Dates reopened / reclosed

7. Department members (link to member screen)

8. Department documents

9. Founding documents (editable only with a supermajority vote)

10. Protocols (immutable)

11. Group proposals (link to proposal screen)

12. Proposals history

Voting

Same as in arc, alchemy and Genesis protocol.

Boosting department

Staking money on proposals could be tricky for a Democracy DAO. On the other hand boosting proposals is an essential component, and a solution to the problem of expertise, i.e. finding the best proposals to act and vote on. We suggest using a boosting department.

Boosting department norms

1. Only a subset of the DAO members would participate in the boosting process.

2. Members will be selected randomly from a group of volunteers with higher than average reputation.

3. Going over all the proposals in the system and selecting them for boosting is time consuming and requires attention. It should be incentivized with either money, reputation, or both.

4. If a selected member doesn’t participate in the boosting process he or she would be removed from the department after a period of time, as configured by the DAO.

5. There’s a limit on the amount of reputation members can gain by boosting proposals. Once a member reached his cap he’s removed from the boosting department and replaced.

6. All members are replaced after one year.

Reputation

Earning reputation

1. Initial registration. DAO Default

2. Note that a fixed reputation for all members is akin to one member one vote.

3. When a member pays membership fee. DAO Default

4. If a member does something to help the DAO. DAO Default

5. If the DAO votes to add reputation for the member. DAO Default

Losing reputation

1. If a member stops paying his membership fee his voting power is suspended. DAO Default
2. If a member is inactive for a certain period of time his reputation is suspended. DAO Default
3. If the DAO votes to slash the member’s reputation.DAO Default
4. If a member is leaving the organization his reputation is slashed to zero.

Gamification

A member’s reputation equals power within the organization. It should be demonstrated visually and celebrated. For example there could be several badges, earned when a member reaches a reputation threshold.

Documents

An organization needs to manage several types of documents. Examples include the organization’s constitution, white papers, collective agreements, meeting protocols, and others.

The Democracy DAO software would provide a document repository for the organization. All DAO documents would be controlled and managed by the DAO. Some of this functionality is currently under development by underscore protocol.

Document access and edit permissions

1. Certain documents, such as a DAO constitution can be changed only by the DAO. Supermajority, a DAO Default is required for passing a proposal to make edits to the constitution.
2. A white paper would have a more relaxed flow of changes, while meeting notes would be immutable as they represent a formal account of an event.
3. Not all documents should be public. Document access permissions are set per document: Public | Members Only | Department Only. (privacy tech needed)

Transparency / DAO Stats

All documents, proposal history, boosting and voting history should be public by default, and configurable by the organization to be available only to its members, a department, or a small set of members. (privacy tech needed)

Measure of decentralization

The software would generate in depth view of the organization’s degree of decentralization, and the topics it supports or rejects. Specifically we need a picture of the organization’s voting and boosting blocks. Which members vote frequently with each other? Against each other? Are there voting cartels? Which topics they support, or oppose?

Binding representatives to the DAO

We are used to the cynicism of our political parties. They promise one thing, and when they gain power often discard their commitments to their voters and do something else.

When an organization forms a DAO with stated goals and selects one or more members to run for office, it could face a similar problem. The elected official represents the organization but now has power outside of it - maybe as an MP, a city councilperson, or a union rep in the company board. The representative can now use his or her power without the DAO’s consent. They are no longer bound to the organization. They can be approached by lobbyists and other politicians, and their incentives are no longer guaranteed to be aligned with the DAO’s goals.

We can call this the problem of interfacing with the outside world. Here are some ideas on how to handle it.

Pre-agreement

The DAO would enforce a pre-agreement with the organization it is sending representative to, so that only the DAO can finalize decisions. When a labor union has a founding agreement with an employer, it is agreed that a decision is valid only if the DAO voted on it. Another example is a coalition agreement for a political party.

When a decision is enforced in this way even if the representative signs an agreement with the employer, it would not bind the DAO. Only a proposal that passes with the DAO will be accepted.

Other ideas

1. A legal contract between the candidate for office and the DAO, with legal protections ensuring the candidate’s commitment. This legal document would be public to all DAO members.

2. A resignation letter signed by the candidate running for office. The DAO would be able to submit the letter in the candidate’s name in case its goals are violated, and replace him with another member.

3. The candidate would deposit an agreed sum of money in escrow. The DAO would take over these funds if its goals are violated.

4. Supporters of the candidate would deposit money in escrow, to guarantee the candidate’s honesty. The DAO would take over these funds if its goals are violated.

Payments

Cryptocurrencies and web3 technologies aren’t widely adopted yet. To encourage existing organizations to use our software we need to allow them to use existing fiat infrastructure.

A relatively simple solution is for the organization to cover all the costs involved in deploying and operating a DAO. Integration with stripe, paypal, or another fiat payment service would enable this.

Membership fee

All member fees would be collected by the organization and are not in scope for our software.

Managing funds

If the organization is managing its funds in crypto: just like arc and alchemy.

If the organization is managing its funds in fiat: not in scope for our software.

DAO Settings

The DAO settings section allows the DAO creator, and later the DAO itself to configure its defaults. The following list of recommendations is based on actual organization’s constitutions.

1. Supermajority

2. Changing a founding document: 75%.

3. Changing documents marked as protected, but are not founding documents: 66%.

4. Removing a member for violating the DAO’s rules: 66%.

5. Removing DAO elected officials before their term is over: 66%.

6. Activating the DAO protections against elected officials (see Binding Representatives to the DAO): 66%.

7. Transfering funds

8. Transferring more than a certain threshold of funds: 15% of the total DAO holdings, or a constant number configured by the DAO: 66%.

9. A second threshold for transferring more than 25% of the DAO holdings: 75%.

10. Reputation

11. Initial member reputation in percentage points: 100 / the number of current members * 0.66. In other words a new member has two thirds the voting power of the average voter.

12. Gaining and losing reputation

1. Paying yearly or monthly membership fee: 1/10 of the initial reputation for a yearly payment, and 1/12 of that for a monthly payment.
2. If a member does something to help the DAO. TBD.
3. If the DAO votes to add reputation for the member: no more than the initial member reputation.
4. If the DAO votes to slash the member’s reputation: no more than the initial member reputation per quarter.
5. If a member stops paying his membership fee his voting power is suspended: until he pays.
6. If a member is inactive for a certain period of time his reputation is suspended. The default period of time: 1 year.

4. Member quota and payments

5. Each member gets a monthly quota of actions. We suggest a default of 3 proposals and 10 votes.

1. If members used their quota they can pay to get more. This should be configurable as some DAOs would allow it while others won’t.

2. Quota is monthly, unless the DAO specified it as quarterly or yearly.

3. Boosting

4. Cap on the amount of reputation a member can gain by being part of the boosting department: twice the amount of rep a new member receives.

5. Once the member reached his cap he’s removed from the boosting department and replaced.

6. All members are replaced after: one year.

7. Misc Configuration

8. Viewing member’s screen is available for all members, or public.

9. Viewing department’s screen is available for department members only, all members, or public.

10. Viewing proposal’s screen is available for all members, or public.

[papa_raw]

I’m biting away at some bits and chunks here – I think this spec is wonderful and would love to see it move forward with some dev work.

DAO Actions

@Eyal

• Suspend or Remove members. Suspension would stop a member from proposing and voting, and removal would also zero out their reputation. Consider allowing this action to be done either via a proposal, or as an admin function.

This could be abstracted in the interface (no back-end work needed) – suspending is basically the same as slashing a member’s entire rep, but holding in the state the value that it was prior to being slashed. “Lifting” the suspension would simply call this value and attach it to a Contribution Reward proposal.

@Eyal

• Open a department (sub DAO). This means that the proposal would specify the department title, description, founding document and founding members.

I have an issue here around subDAO deployment. In my eyes this is definitively a priority. One interesting thing we could do is make it so the “DAO’s Mind” is prefilled with the founding document information. “Description” could be the DAO Header.

@Eyal

• Suspend, or close a department.

This already fits into the subDAO scheme I’m imagining as the parentDAO would have 51% of the Rep at all times no matter the absolute values.

@Eyal

• Supermajority actions. Certain proposals, and other actions would require a larger than 50% majority in order to pass.

Opened an issue here. This is a really good idea!

@Eyal

[8-9]

Being worked on by @pepo “Mind of the DAO”

@Eyal

• Viewing permissions. This means that some documents should only be viewable to members of the organization, or members of a department within the organization, while others can be public.

This is a trickier one I think that perhaps could be a Stage II implementation of the DAO’s Mind, it would probably need some sort of privacy implementation to pull off. For now to set these sort of complex permissions I think Google Docs is probably the strongest option.

@Eyal

[11-12]

I’ll discuss this in a bit. But this is the most problematic aspect of this spec.

@Eyal

1. Sign agreements with organizations or individuals outside of the DAO. See Binding Officials to the DAO.

To my knowledge dOrg has already done this through proposals in their DAO [Exhibit A][Exhibit B]. What’s definitely needed is a more UX friendly library of legal wrappers for agreement-making and ratification.

Admin Functions

My main issue with this section is that generally DAOstack is about open collaborative networks and installing any sort of admin system is a centralized design pattern that is undermining this direction. But I will treat this section with dignity regardless, and only call out those issues which could be majority security risks to the DAO.

@Eyal

• Open a department. Certainly at the DAO Creation stage.

I’m imagining some sort of voting machine that executes a proposal if either A or B happens. A would be the normal proposal cycle, but B could be simply “this address declares it so.” This would effectively create the “admin” function you’re imagining. But it’s problematic for a few reasons: imagine a malicious admin that decides to deploy a bunch of departments and drain the DAO of its funds through excessive gas fees. Permissions systems generally introduce permissions faults.

@Eyal

• Add members.

Another problematic aspect – an admin could theoretically attack the DAO by mass adding members that support his or her agenda. You address this in [3], however, but I still don’t think it’s a great solution: generally permissions should flow from the larger body downwards (the parentDAO should determine membership in a subDAO, not a subDAO in a parentDAO). However, bulk adding members I think is an elegant tradeoff here, one I’ve added an issue for.

@Eyal

• Suspend members.

Similar issues to [2].

Members, ID Verification, and assigning initial reputation

@Eyal

• All the organizations we interviewed formally register members and verify their identity before allowing them to vote. Anonymous, or pseudonymous membership is not allowed.

Interestingly enough, this is a service the Arc.Hives aims to provide – a Reputation curated registry of IDed persons on DAOstack. So the scheme here would be requiring folks to be validated by the IdentityDAO (Arc.Hives registry). It’s good to see there’s need for it as this is a Genesis DAO business model.

@Eyal

• Once membership fee is paid a member can be added to the DAO by the organization’s staff via a standard registration form, or in bulk by using an agreed on format.

Why not just have an escrow scheme whereupon if the membership application is accepted the fee is automatically paid?

@Eyal

1. New members also get a quota of proposals and votes per month, as configured by the DAO.

Another interesting scheme idea.

Member Screen

@Eyal

• Name.
• Title.
• Contact information.
• Notification preferences.
• Reputation.
• Proposing and voting quota.
• Departments membership.
• Proposal history.
• Voting history.
• Voting blocks. Whom did the member vote with? Who voted for and against her proposals?
• Payment method.

Most of this is being implemented in some form or another, maybe with the exceptions of [6][10] and [11]. I think [10] – voting blocks – is an important feature to consider.

Boosting Department

I think this feature entirely misses the point of having liquid GEN boosting markets. Without them, it doesn’t work as a service, nor does it capture the collective attention of all DAOs on the platform.

[Eyal]

Wow, thanks for the great comments, @papa_raw, I really appreciate you going deep into this.

Just a quick note for now about the boosting department. I realize this breaks the business model centered around GEN, and suggests another one based on license fees. My sample size (only 5 organizations, all in one country) is very small but asking a left leaning NGO in Israel at this point in time to accept market influence over their decision making is going to be difficult. Other organizations may be more open to it.

[papa_raw]

Sure – it’s a tough pill to swallow. And hard to envision why it’s important when there’s so few decisions on the platform thus far, and a minimum of D2D relations going on. But to implement fractal federal governance effectively it’s needed. I think it’ll turn into a momentum thing: once the first few orgs see that they can effectively collaborate with other orgs, and a common market is sorting all decisions efficiently, it’ll click that what the platform ultimately implements (a vast, interconnected mesh network) has more value than permissioned isolation.

[Eyal]

@papa_raw

I have an issue here around subDAO deployment. In my eyes this is definitively a priority. One interesting thing we could do is make it so the “DAO’s Mind” is prefilled with the founding document information. “Description” could be the DAO Header.

Yes, the “DAO Header” is a very good feature. The name of the proposal is misleading a bit, it should be white label (rebranding). I wish they extended it to the entire site’s color scheme, but it seems like a great start.

[Eyal]

@papa_raw

Admin Functions

My main issue with this section is that generally DAOstack is about open collaborative networks and installing any sort of admin system is a centralized design pattern that is undermining this direction. But I will treat this section with dignity regardless, and only call out those issues which could be majority security risks to the DAO.

I completely agree with the risks. Also wrote it in the doc. But I do think we have an issue that we haven’t solved yet. If we want to mirror a real world organization we’d need to allow for many semi-automatic decisions done by the org’s staff. Asking for a full vote of 20,000 members (or more) on every little thing is not a workable solution.

[Eyal]

@papa_raw

Most of this is being implemented in some form or another, maybe with the exceptions of [6][10] and [11]. I think [10] – voting blocks – is an important feature to consider.

I thought Eylon was working on this? He even sent me an excel with some raw data a few weeks ago. Did he move on to other areas?

[papa_raw]

@Eyal

If we want to mirror a real world organization we’d need to allow for many semi-automatic decisions done by the org’s staff. Asking for a full vote of 20,000 members (or more) on every little thing is not a workable solution.

This is true, but to re-emphasize some points I commonly make:

1/ Holographic consensus does not require all voters for all votes given the relative majority mechanic. It actually (in theory) only captures the bandwidth (attention) of voters for contested proposals, scaling up the more contested they are. I think we’ve seen this with Genesis, for instance, where folks (both predictors and voters) go around and solicit attention when the vote is close.

2/ The big picture is to have nesting and an interconnected mesh network – in order to create solutions where not every decision has to be made by everyone. I’m just not entirely confident that we should default to some sort of “management” organizational design pattern without first evaluating alternatives – the idea isn’t to mirror organizations as they are, but to disrupt them horizontally and network-wide.

@Eyal

I thought Eylon was working on this? He even sent me an excel with some raw data a few weeks ago. Did he move on to other areas?

I don’t know. If I recall @nylon was speaking with Graph Commons around some sort of tool like so. Maybe creating an integration that serves this specific feature purpose could work?

[Eyal]

Ok, I have a few questions here. 100 new members joined a 100,000 people organization (they paid membership fees yesterday) and we need to give them voting power.

1. Does someone from the DAO start one proposal for all 100? (maybe 2 of them are known to be problematic for some reason related to the organization, so it’s not great to put all 10 together.)
2. Does the DAO create 100 different proposals, that need to be boosted, and voted on separately? Who creates all the 100 proposals, and who votes on them? I mean in a real world organization, where most members are busy doing the org’s work, which is not related to the DAO platform.
3. If nobody is tasked with creating all these proposals, what stops people from creating 10 proposals to add one member (duplicate proposals).

I totally bought into the white paper’s vision and over a year later I still very much believe in it. Just trying to tackle the adoption issues.

[papa_raw]

@Eyal

1. Does someone from the DAO start one proposal for all 100?

Yes – and this can be done today in the Scheme Registrar – it’s just extremely hard to do without being a dev. Needs front-end abstraction.