Introduction
This document proposes the DAO architecture that the TECommons DAO will have if it undergoes with the migration from their Gardens DAO on Gnosis Chain to a Tao Voting DAO on Optimism. The specifics of the migration proposal are detailed at this thread. This work corresponds to the second deliverable of the technical feasibility study described in this thread.
The DAO will feature two distinct Tao Voting instances. The primary instance, similar to how the TEC Gardens is working presently, will have broad powers, including the ability to install apps, modify permissions, and adjust parameters of existing apps, such as the tributes of the bonding curve. The second instance will focus solely on managing the Common Pool, facilitating fund requests. Both instances follow a three-step mechanism:
-
Tollgate: A proposal creation fee is required to prevent spam, yet it must be low enough to encourage participation. This fee is directed to the Common Pool.
- Note: We replace the Deposit Manager in Gardens by the Tollgate, since the Deposit Manager was introduced in Aragon v5. We are using Aragon v4.4, not Aragon v5, which was never formally audited.
- Tao Voting: Here, the main governance occurs, involving voting and vote delegation.
- Delay: After a Tao Vote, there’s a 24-hour delay for execution, during which TEC Guardians can pause or veto the actions.
The TEC Guardians DAO, functioning as an independent Membership DAO, acts as a safeguard against proposals that may contravene the Community Covenant or pose risks to the TEC DAO. Guardians are elected as per the procedure outlined in this forum post. Their role is to maintain a stable count of seven members and to intervene in the Delay phase of decision execution, specifically to block such malevolent actions. Importantly, Guardians neither have special voting rights within the DAO nor access to its funds; their exclusive authority is to prevent the execution of malicious proposals that would cause economic, social or legal harm to the TEC.
In the new Tao Voting DAO, a dual-token governance model, which combines TEC with a new reputation token named rTEC, can be activated. Unlike TEC, rTEC can not be sold and is a lifetime token assigned to specific contributors within the DAO. The rTEC will not be activated now as part of the migration; however, if the TEC DAO decides to distribute it to TEC contributors in the future, it will grant rTEC holders partial governance power alongside TEC holders: at the time of the rTEC minting, governance of the DAO will be shared 95-5% between TEC holders and rTEC holders respectively. Furthermore, the DAO retains the ability to modify this split in subsequent Tao Votes.
In order to oversee the minting and burning of the rTEC tokens, the creation of a new TEC Reputation Board (TECRB), a subDAO, with that specific mandate would be needed. This subDAO will primarily operate under the governance of the main TEC Tao Voting app. While the TECRB token holders are granted authority to manage the rTEC token supply through minting and burning processes, as well as the ability to burn TECRB tokens, it is the main TEC DAO that ultimately holds decisive power over the composition of the board, with the exception of the TECRB’s inherent power to vote for the removal of its own members but without the ability to add new ones.
However, it’s important to remark that TECRB and rTEC will NOT be active immediately after the migration. The initial mint of these two tokens must be done in a separate vote when the community is ready, starting by (1) deciding who is going to be in the Reputation Board and which is the reputation token initial distribution, (2) creating a Tao vote on the TEC DAO to mint tokens to the Reputation Board, and (3) using the Reputation Board subDAO to mint reputation tokens for everyone who has had a positive impact in the TEC DAO. This approach ensures that the introduction of TECRB and rTEC is aligned with the collective will of the DAO’s participants, reinforcing a governance model that is responsive and adaptive to the community’s evolving needs and priorities.
Future changes and decisions within the DAO, including modifications to governance structures or token dynamics, will be made using the Tao Voting mechanism, ensuring a democratic and participatory process for all members.
You can find the specification of the three described DAOs as it follows.
Token Engineering Commons DAO
Application Configurations
Token and Token Manager #1
Token Manager #1 controls the transferable TEC token.
- Token symbol: TEC
- Token name: Token Engineering Commons
- Decimals: 18
- Transferable: Yes
Token and Token Manager #2
Token Manager #2 controls the non-transferable reputation token.
- Token symbol: rTEC
- Token name: TEC Reputation
- Decimals: 18
- Transferable: No
Voting Aggregator
Voting Aggregator combines the transferable TEC token with the non-transferable reputation token.
- Name: TEC power
- Symbol: TECPOW
- Decimals: 18
- Power sources:
- TEC token: 95%
- TECREP token: 5%
Tollgate #1
Tollgate #1 puts a fee on the creation of votes on Tao Voting #1 (governance).
- Fee token: TEC
- Fee amount: 40
- Fee destination: Agent #2 (Common Pool)
Tao Voting #1
Tao Voting #1 is the Governance Voting app, which controls the parameters of the DAO.
- Token: TEC Power (TECPOW)
- Vote time: 5 days
- Support required: 85%
- Minimum acceptance quorum: 10%
- Delegated voting period: 3 days
- Quiet ending period: 3 days
- Quiet ending extension: 2 days
- Execution delay: 0 days
- Representative manager: none
AN Delay #1
AN Delay #1 delays the execution of governance votes, allowing the DAO guardians to veto the proposal.
- Execution delay: 1 day
- Fee amount: 0
- Fee token: zero address
- Fee destination: Agent #2 (Common Pool)
Agent #1
Used as the Reserve.
Tollgate #2
Tollgate #2 puts a fee on the creation of votes on Tao Voting #2 (budget).
- Fee token: TEC
- Fee amount: 40
- Fee destination: Agent #2 (Common Pool)
Tao Voting #2
Tao Voting #2 is the Budget Voting app, which can create payments in the Finance app.
- Token: TEC Power (TECPOW)
- Vote time: 5 days
- Support required: 85%
- Minimum acceptance quorum: 10%
- Delegated voting period: 3 days
- Quiet ending period: 3 days
- Quiet ending extension: 2 days
- Execution delay: 0 days
- Representative manager: Tao Voting #1 (governance)
AN Delay #2
AN Delay #2 delays the execution of budget votes, allowing the DAO guardians to veto the proposal.
- Execution delay: 1 day
- Fee amount: 0
- Fee token: zero address
- Fee destination: Agent #2 (Common Pool)
Agent #2
Used as the Common Pool.
Finance
- Vault: Agent #2 (Common Pool)
- Period duration: 30 days
Augmented Bonding Curve (ABC)
- Token Manager: Token Manager #1
- Formula: Bancor Formula
- Reserve: Agent #1 (Reserve)
- Beneficiary: Agent #2 (Common Pool)
- Entry tribute (buy fee): 2%
- Exit tribute (sell fee): 12%
- Collateral token: RETH
- Virtual supply: 1
- Virtual balance: 1
- Reserve ratio: 20% (currently at 19.82%, but we can increase it a little bit after converting the reserve tokens to RETH)
Permissons
The permissions that will be set are:
| App | Permission | Grantee | Manager |
|---|---|---|---|
| Kernel | APP_MANAGER | Delay #1 | Delay #1 |
| ACL | CREATE_PERMISSIONS | Delay #1 | Delay #1 |
| Token Manager #1 | MINT | ABC | Delay #1 |
| Token Manager #1 | BURN | ABC | Delay #1 |
| Token Manager #2 | MINT | Voting (TECRB) | Delay #1 |
| Token Manager #2 | BURN | Voting (TECRB) | Delay #1 |
| Voting Aggregator | MANAGE_WEIGHTS | Delay #1 | Delay #1 |
| Tollgate #1 | CHANGE_AMOUNT | Delay #1 | Delay #1 |
| Tao Voting #1 | CREATE_VOTES | Tollgate #1 | Delay #1 |
| Delay #1 | DELAY_EXECUTION | Tao Voting #1 | Delay #1 |
| Delay #1 | PAUSE_EXECUTION | Token Manager (GUARD) | Delay #1 |
| Delay #1 | RESUME_EXECUTION | Token Manager (GUARD) | Delay #1 |
| Delay #1 | CANCEL_EXECUTION | Token Manager (GUARD) | Delay #1 |
| Agent #1 | EXECUTE | Delay #1 | Delay #1 |
| Agent #1 | RUN_SCRIPT | Delay #1 | Delay #1 |
| Agent #1 | TRANSFER | ABC | Delay #1 |
| Tollgate #2 | CHANGE_AMOUNT | Delay #1 | Delay #1 |
| Tao Voting #2 | CREATE_VOTES | Tollgate #2 | Delay #1 |
| Delay #2 | DELAY_EXECUTION | Tao Voting #2 | Delay #1 |
| Delay #2 | PAUSE_EXECUTION | Token Manager (GUARD) | Delay #1 |
| Delay #2 | RESUME_EXECUTION | Token Manager (GUARD) | Delay #1 |
| Delay #2 | CANCEL_EXECUTION | Token Manager (GUARD) | Delay #1 |
| Agent #2 | TRANSFER | Finance | Delay #1 |
| Agent #2 | EXECUTE | Delay #2 | Delay #1 |
| Agent #2 | RUN_SCRIPT | Delay #2 | Delay #1 |
| Finance | CREATE_PAYMENTS | Delay #2 | Delay #1 |
| ABC | MAKE_BUY_ORDER | Any account | Delay #1 |
| ABC | MAKE_SELL_ORDER | Any account | Delay #1 |
| ABC | MANAGE_COLLATERAL_TOKEN | Delay #1 | Delay #1 |
TEC Guardians DAO
Application Configurations
Token and Token Manager
Token Manager controls the TEC Guardian token.
- Token symbol: GUARD
- Token name: TEC Guardian
- Decimals: 0
- Transferable: No
Voting
- Token: TEC Guardian (GUARD)
- Vote time: 31 days
- Support required: 51%
- Minimum acceptance quorum: 40%
Permissons
The permissions that will be set are:
| App | Permission | Grantee | Manager |
|---|---|---|---|
| Kernel | APP_MANAGER | Voting | Voting |
| ACL | CREATE_PERMISSIONS | Voting | Voting |
| Token Manager | MINT | Voting | Voting |
| Token Manager | BURN | Voting | Voting |
| Voting | CREATE_VOTES | Token Manager | Voting |
| Finance | EXECUTE_PAYMENTS | Voting | Voting |
| Finance | MANAGE_PAYMENTS | Voting | Voting |
| Finance | CREATE_PAYMENTS | Voting | Voting |
| Agent | TRANSFER | Finance | Voting |
| Agent | EXECUTE | Voting | Voting |
| Agent | RUN_SCRIPT | Voting | Voting |
TEC Reputation Board
We used the current TEC Rewards DAO voting parameters to model the new DAO.
Application Configurations
Token and Token Manager
Token Manager controls the TEC Reputation Board token.
- Token symbol: TECRB
- Token name: TEC Reputation Board
- Decimals: 0
- Transferable: No
Voting (TECRB)
- Token: TEC Reputation Board (TECRB)
- Vote time: 1 days
- Support required: 81%
- Minimum acceptance quorum: 41%
Permissons
The permissions that will be set are:
| App | Permission | Grantee | Manager |
|---|---|---|---|
| Kernel | APP_MANAGER | Delay #1 (TEC) | Delay #1 (TEC) |
| ACL | CREATE_PERMISSIONS | Delay #1 (TEC) | Delay #1 (TEC) |
| Token Manager (TECRB) | MINT | Delay #1 (TEC) | Delay #1 (TEC) |
| Token Manager (TECRB) | BURN | Delay #1 (TEC) | Delay #1 (TEC) |
| Token Manager (TECRB) | BURN | Voting (TECRB) | Delay #1 (TEC) |
| Voting (TECRB) | CREATE_VOTES | Token Manager (TECRB) | Delay #1 (TEC) |
| Finance | CREATE_PAYMENTS | Voting (TECRB) | Delay #1 (TEC) |
| Agent | TRANSFER | Finance | Delay #1 (TEC) |
I would like to thank @griff and @Tamara for their comments during the review process of this document, their feedback significantly enhanced its quality. Praise to both of you 
.
EDIT 3rd December 2023: After the TEC Advisory Group call last Friday, we decided to use RETH as the reserve token, and a 40 TEC tollgate fee.
EDIT 14th December 2023: We provided the Guardians DAO with an Agent on the moment of creation, and we reflected it in the spec, although it doesn’t change the overall architecture.
