Optimism TEC DAO Specification

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 :pray:.

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.

7 Likes

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.

If there was no verein, anglo-saxon law would have treated the DAO as a constructive trust (current judicial interpretative leaning towards DEXs) and the TEC role of guardians as legal protectors . However, it is up to the caselaw of jurisdiction whether the protector has strong (ie equiv to trustee) or weak (advisory or representing interests of minor) powers. Where they would fit into the DLT mechanism is a la Vlad Zamfir “human in the loop” governance philosophy (bottom right) of below

DLT ontology