DAO de la Fase 0
This commit is contained in:
Team1
parent
89248a0fec
commit
33beee8e42
|
|
@ -0,0 +1,199 @@
|
|||
---
|
||||
title: The Decentralized Climate Foundation WorkFlow (Phase0) DAO Model.
|
||||
author: Decentralized Climate Foundation
|
||||
date: 2023-04-06
|
||||
layout: post
|
||||
---
|
||||
|
||||
## LICENSE
|
||||
|
||||
```
|
||||
Copyright (C) 2023 DECENTRALIZED CLIMATE FOUNDATION A.C.
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3
|
||||
or any later version published by the Free Software Foundation;
|
||||
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
|
||||
A copy of the license is included in the section entitled "GNU
|
||||
Free Documentation License".
|
||||
```
|
||||
|
||||
## The Traditional organizations issues
|
||||
1. There can be a conflict of interest when the Task Assigner or Payers have preferences over workers.
|
||||
2. Purposes are often in conflict (example: finance wants to save – devs need to spend).
|
||||
3. When we use hour rate, people add extra hours to simple work (Example 1 dolar per minute in call).
|
||||
4. When people get paid to be in office, example 4 hours, its rated by hours but not in efficiency (we call it ass hour).
|
||||
5. Free work assignation (when someone aligns to themselves) can be just to fill task on unnecessary or useless work.
|
||||
6. Lack of supervision and communication between areas, which generates assumptions.
|
||||
|
||||
## The DCF Phase 0: WorkFlow, Payments and Communication
|
||||
### 1. Use an Agile approach for meetings and comunication (weekly sprints):
|
||||
|
||||
#### Official dates and time for calls are:
|
||||
|
||||
The 15 min calls on 19:00 Mexico City time are Tuesdays, Thursdays and Saturdays. Topics: Communication, Syncronization and Support between the team on the workflow and tasks
|
||||
|
||||
The 60 min calls are on 19:00 Mexico City time are Mondays. Topics to perform:
|
||||
* Review the last sprint tasks and approve the economic incentive by the DAO.
|
||||
* Asign task for the current sprint (week) between the team members and areas (currenty Administration and Development).
|
||||
* Brainstorm an approach by consensus an estimate economic incentive for the tasks developers.
|
||||
> Note Sprint tasks must be considered either as finished or functional. They should not be considered if they are partially done or something that is not proven to be functional.
|
||||
|
||||
#### Calls time measurement
|
||||
|
||||
The 25% of the whole payment is for attending to this meetings which is the biggest responsibility for our workflow and communication. So anyone involved into the workflow should be at least at 75% of the measured calls time (t).
|
||||
|
||||
$$ t >= 315min $$
|
||||
|
||||
Any skipped minute will be slashed from the total payment as following this equation:
|
||||
|
||||
$$ TP = TTD * \dfrac{MA}{t}$$
|
||||
|
||||
where:
|
||||
|
||||
TP = Total Payment
|
||||
|
||||
TTD = Total Tasks Deliveries
|
||||
|
||||
MA = Minutes Attendance
|
||||
|
||||
t = Total of minutes calls for the month
|
||||
>**Currently monthly total calls time is 420 minutes**
|
||||
|
||||
|
||||
#### Extra considerations:
|
||||
|
||||
1.1. There is also Right to change one 15 min call right monthly (24Hrs before)
|
||||
|
||||
1.2. If the Minutes Attendance /420 = 1; there should be a consideration or badge for attendance with a future reward.
|
||||
|
||||
1.3. If some one attends less or equal to 75% of the meetings unjustified there should be a quorum to talk about the issue.
|
||||
|
||||
1.4. Rewards can be considered by the end of the year, in the way the DAO decides to provide time/organization rewards.
|
||||
|
||||
1.5. Ensure that everyone has enough tasks, and will not lack of them.
|
||||
|
||||
1.6. If there is more than one person in a specific task (each one writes the task and the amount is divided).
|
||||
|
||||
#### The only situation where we can skip Minutes Attendance are:
|
||||
|
||||
* Medical issues which require a justification proof (not always from the same source medic since it can be part of a corruption model).
|
||||
|
||||
### 2. All the tasks must be decided and asigned by the DAO voting mechanism.
|
||||
This ensure transparency and with amounts to be paid, work proposal and what was completed.
|
||||
|
||||
2.1. There is a monthly cap while we are in crisis (bear market) or just to manage better the resources and participation.
|
||||
|
||||
2.2. To assign a task, it has to be voted and approved by more than two persons and at least form two diferent areas.
|
||||
### 3. Tasks Types
|
||||
Currently there are 4 tasks types:
|
||||
|
||||
3.1. Recurrent tasks for a month should be in one card, example all already planned tasks and wellknown.
|
||||
|
||||
3.2. Project and Components: Projects are the general projects which have multiple components, Projects must be specified as DCF Project Proposals in which the Components to develop should be specified, this Components, if a component is too clomplex it can also can be splited into tasks to complete the Component and thus the full project. Tasks and components should be also functional deliveries (Example article sections, software functions or modules).
|
||||
|
||||
3.3. On the Go tasks, these are tasks that are special requirements and not planned, that the DAO previously approves them in between a sprints.
|
||||
|
||||
3.4. Priority/Emergency Tasks, these tasks can be performed out of the DAO descitions and these are only priority tasks that forefill the best interest of the foundation and its projects correct operation (Example Security patches, access control when the team changes, priority legal payments, etc).
|
||||
|
||||
### 4. Payments and Quality of work:
|
||||
|
||||
4.1. Must define and vote a quality grade of the delivery, in some proposed percentages lower or upper from the price proposed on the task.
|
||||
|
||||
4.2.Team work must be also another parameter to incentivize since this helps to have quality, creativity and reduce errors, also it helps to have a better control and comunication between teams.
|
||||
|
||||
### 5. External Collaborators and Community
|
||||
|
||||
They can perform tasks with bounty promise (in the airdrop), NFTs, or anyone has extraordinary performance. (but we cannot ensure the price for this airdrops or NFTs since this can be considered speculation)
|
||||
|
||||
### 6. Fundamental external workers and services
|
||||
|
||||
They should be voted and notified by the DAO to show DCF transparency of expenses: Like Lawyers, acountants, office cleaning and other services.
|
||||
|
||||
### 7. Specialized External Services
|
||||
|
||||
Any work that is not a priority nor approved by the DAO at point 6 (basic external) to forefill DECA and DCF development projects and that the current team is not qualified to perform, should be done either by comunity memebers or by a fiverr-workana/bounty system to hire someone (example: Marketing, external writers and other services).
|
||||
|
||||
|
||||
## How To Vote and scenarios for the company DAO
|
||||
The Company DAO use transferable tokens to represent ownership stake in the organization. Decisions are made based on stake-weighted voting.
|
||||
|
||||
|
||||
|
||||
> Support: Support is the relative percentage of tokens that are required to vote “Yes” for a proposal to be approved. For example, if “Support” is set to 50%, then more than 50% of the tokens used to vote on a proposal must vote “Yes” for it to pass.
|
||||
|
||||
> Minimum Approval is the percentage of the total token supply that is required to vote “Yes” on a proposal before it can be approved. For example, if the “Minimum Approval” is set to 20%, then more than 20% of the outstanding token supply must vote “Yes” on a proposal for it to pass.
|
||||
|
||||
> Vote Duration is the length of time that the vote will be open for participation. For example, if the Vote Duration is set to 24 hours, then token holders have 24 hours to participate in the vote.
|
||||
|
||||
|
||||
### There are multiple scenarios:
|
||||
And this apply also to 5 persons (as required for 2023)
|
||||
Assuming that a quota of 60% is needed to approve a proposal and the distribution of voting weight per person is: [60: 28, 28, 18, 16, 10]; [minimum quota: p1, p2, p3, p4, p5].
|
||||
The total weight is 28+28+18+16+10=100. Half of 60 is 30, so the quota must be 30<q<100. Since the quota is 60, and is more than 30 and less than 100, this system is valid.
|
||||
There are 2 groups of voters, where p1, p2 = 28 votes, which together add up to 56. This group will be called G1. The second group is made up of p3, p4, p5 with 18, 16, 10 respectively and together they have 44 votes. This group will be called G2.
|
||||
It should be noted that no group alone has enough votes to approve a proposal, so the following cases are presented:
|
||||
|
||||
1. Any member presents a new proposal and everything votes **YES**.
|
||||
Result: The proposal gets **approved**
|
||||
2. Any member presents a new proposal and one member of G1 group votes **NO**.
|
||||
Result: The proposal gets **approved**
|
||||
3. Any member presents a new proposal and one member of G2 group votes **NO**.
|
||||
Result: It gets **approved**.
|
||||
4. Any member of G2 presents a proposal, it needs the support of all G2 members and at least one member of G1 to be approved. Or in another way with the simple support of G1 members.
|
||||
5. Special case of swing member : In this case p3 has the definitive vote (Confirmation / Veto). Any member present a proposal and p1 votes **YES** and p2 votes **NO** (or visceversa); p4, p5 votes **YES**. In this case there is no majority to approve the proposal.
|
||||
Result: If p3 votes **YES** it gets **approved**.
|
||||
Result: If p3 votes **NO** it gets **rejected**.
|
||||
|
||||
The following scenario (minimum approval) is when from the total amount of DAO tokens it is determined how many have to vote for the proposal to be approved. Because not all voters are going to vote. This means that if there are people who do not vote on a proposal, 30% of the voters are enough for it to be approved.
|
||||
|
||||
In general, in this case, only the vote of 2 people are needed and the rest abstain to approve a proposal. There is only one exception.
|
||||
|
||||
1. P1 presents a new proposal and just p2 votes **YES** and no one else votes (30<56).
|
||||
Result: The proposal gets **approved**.
|
||||
2. P5 presents a new proposal and only votes (**YES**) p3 & p4 (30%<34%).
|
||||
Result: The proposal gets **approved**.
|
||||
3. P3 presents a new proposal and just p2 votes **YES** (30%<46%).
|
||||
Result: The proposal gets **approved**.
|
||||
4. Special case. P5 presents a new proposal, p1 & p2 abstain and just p3 or p4 votes **YES**.
|
||||
Result: The proposal gets **rejected**.
|
||||
|
||||
In the only extreme case all members of G2 need to vote **YES** on a proposal and G1 abstains for it to be approved.
|
||||
With the endorsement of any G1 member, it only takes 1 vote (**YES**) from any member and the abstention of the other members for any proposal to be approved.
|
||||
|
||||
|
||||
|
||||
## Future DAO Phases Proposals
|
||||
|
||||
* **Phase 0:** Setup a Company DAO and work proposals in a testnet for managin the Decentralized Climate Foundation tasks, workflow and payment models proof of concept, the Phase 0 DAO proposal with all this specifications.
|
||||
|
||||
* **Phase 1:** Setup a DAO for DCF and its projects that works with DECA either by weighted (with some fixes to avoid abuse of whales) or an quadratic/dot vote mechanis. Some specifications might include, votes should be identified first so that they cannot use anon wallets (for whales) and we can start receiving donations to the DAO vault. The Phase 1 might work on a alternative network such as polygon or Aragoin voice, *t**he main goal of the phase 1*** is to start using/syncing with the DECA ERC20 Token.
|
||||
|
||||
* **Phase 2:** Start Operating on a ZK Layer 2 or the main net when whe gas fees get reduced. And if DECA 2 Development is ready, integrate the DECA2 Protocol.
|
||||
|
||||
* **Phase 3:** ToDo.
|
||||
|
||||
## CONTACT AND DEVELOPERS
|
||||
> Work developed in collaboration with the [Decentralized Climate Foundation](https://decentralizedclimate.org) and [Neetsec International Inc](https://neetsec.com).
|
||||
|
||||
- [David E. Perez Negron R.](mailto:david@neetsec.com)
|
||||
- [Octavio Valdez](mailto:ohuerta@decentralizedclimate.org)
|
||||
|
||||
## References
|
||||
\[1\] DCF DAO 2022, "DCF DAO", https://client.aragon.org/#/decentralizedclimate/, 2022.
|
||||
|
||||
\[2\] The Aragon community builders, "Aragon HowTo", https://aragon.org/how-to, 2022.
|
||||
|
||||
\[3\] Faucet Goerli, "Faucet to mine testnet coins(fees)", https://goerli-faucet.pk910.de/, 2022.
|
||||
|
||||
\[4\] Maxie Inigo, Jennifer Jameson, Kathryn Kozak, Maya Lanzetta, & Kim Sonier, "Home Bookshelves Applied Mathematics College Mathematics for Everyday Life (Inigo et al.) 7: Voting Systems 7.2: Weighted Voting", https://math.libretexts.org/Bookshelves/Applied_Mathematics/Book%3A_College_Mathematics_for_Everyday_Life_(Inigo_et_al)/07%3A_Voting_Systems/7.02%3A_Weighted_Voting, 2022.
|
||||
|
||||
\[5\] NeetSec International Inc, "DAOs Research", https://hackmd.io/zT7qJS4HQsWEnyPBsW3LLg?view, 2022.
|
||||
|
||||
|
||||
## ToDo
|
||||
- [ ] Writing and Language Review.
|
||||
- [ ] Sync setup with foundation's Github/Gitlab
|
||||
- [ ] Version control
|
||||
- [ ] Work with issues and forks not only by hackmd.
|
||||
- [ ] Decentralize in any possible ways (maybe a web3 on jekyl + feek + gitcoin)
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
3
index.md
3
index.md
|
|
@ -37,8 +37,7 @@ layout: home
|
|||
|
||||
| Document | Link | Network |
|
||||
| -------- | -------- | -------- |
|
||||
| [Phase0](/dao_development/2023-01-25-Phase0.html) | [DecentralizedClimate](https://client.aragon.org/#/decentralizedclimate) | Goerli
|
||||
| [Phase1(unfinished)](/dao_development/2023-01-25-Phase1.html) | [decentralizedclimate.eth](https://demo.snapshot.org/#/decentralizedclimate.eth) | Ethereum Main / Snapshot
|
||||
| [Phase0]({% post_url 2023-02-15-DAO %} ) | [DecentralizedClimate](https://client.aragon.org/#/decentralizedclimate) | Goerli
|
||||
|
||||
### Decentralized Climate Improvement Proposals
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue