Skip to main content

Governance-on-Teia

"We believe in shared ownership on the platform, no one should have exclusive rights over others"

(from the Teia Core Values Manifesto)

Dao as a Goal​

“Decentralized autonomous organization (DAO) governance is coordinated using tokens or NFTs that grant voting powers. Admission to a DAO is limited to people who have a confirmed ownership of these governance tokens in a cryptocurrency wallet, and membership may be exchanged. Governance is conducted through a series of proposals that members vote on through the blockchain, and the possession of more governance tokens often translates to greater voting power. Contributions from members towards the organizational goals of a DAO can sometimes be tracked and internally compensated.”

(From Wikipedia)

We want to be able to vote on fundamental decisions transparently and on-chain. We believe that, together, we can create tools, applications and processes respecting the community’s needs and wishes and that we are all building the future of the Teia ecosystem together. The Goal is to hand over the governance of Teia to a set of DAO smartcontracts and registering Teia as an legal, non-profit entity that reflects is decentralised nature.

The fundamental principles that shape the community are the same as those for its governance: Inclusivity, Respect, Community/Solidarity, Decentralization, Simplicity, Accessibility, Sustainability and Creativity.

Teia's final DAO setup is currently under construction, a process in which the whole community is invited to participate. We anticipate a long development phase in order to respect the main points of the Manifesto, such as recognizing diversity and facilitating inclusion. We anticipate that once created, the Teia DAO will continue to morph and improve, in order to respect the evolution of the platform and all of the communities to be represented.

The decision-making process of TEIA is horizontal and will take into account the needs and policies decided by all the groups represented. These groups will also have some economic autonomy in decision-making.

Teia is incorporated as a non-profit, limited liability corporation (LLC) on the Republic of Marshall islands (RMI) that formely recognizes DAO governance and digital ledger addresses as members.

This means that Teias "owners" (=members) can be defined by Token ownership or assignemnt to a multisig address without the need of members doing KYC (as long as they stay below 10% of voting power, which will be implemented on a smartcontract level)

The DAO currently operates under the Version 1.2 of the Teia DAO Operating Agreement

Relevant legal texts (Marshall Islands law):

Phase01: Proto DAO governed by a multisig​

(we are here currently)

During this initial phase, Teia will be operating under the Teia Operating Agreement v1.2 this document will be updated for the next Phases of Teias DAO launch.

Take a look at the Multisig here: https://core-team-multisig.onrender.com/

In the first phase, before the Teia DAO Tokens have been distributed, the "Core Team Multisig" will be the official owner of Teia's legal entity.

The Multisig consists of approximately 20, but at least 11 addresses owned by highly active contributors to Teia. It will be used to vote on transactions involving Teia's assets, change the membership status of the core team multisig, and manage the Teia marketplace smart contracts. For instance, it can modify the marketplace fee (requiring a quorum of 55% to complete transactions).

Tezos wallets can be proposed for addition or removal from the multisig through a majority vote of at least 55% among the multisig members. Added wallet addresses must accept the addition and can also leave the multisig without requiring a vote.

Certain members of the Core Team Multisig will be assigned coordinating roles for operations and tech developments. These coordinators are authorized to make smaller, day-to-day decisions regarding managing members and coordinators.

The intermediate ways how community wide consensus is formed are via discussions, with soft consensus, a on-chain vote with the core team voting tool, discord polls for small decisions and for bigger decisions we use on-chain community voting via the Teia Vote Tool, where everybody with a TEIA account (wallet) created before a set date has the right to vote.

Votes cast with the teia vote tool are recorded on the blockchain, and a script tallies and displays the votes on the website after the voting period ends. These results can be independently verified by the voters using the unchangeable blockchain data.

Currently, all major proposals and questions are discussed at the Teia Community Discord Server and the Community Discourse Forum before being put up for a vote. Whoever wants to submit a proposal can access the TEIA Discord Channel where the proposal will be discussed by the entire community and taken to vote. A better solution for a proposal agora is on the roadmap, but we will focus on setting up the general structures and smartcontracts first.

ProtoDAO structure and procedure

Phase02 DAO beta​

After the Teia DAO Tokens have been distributed, we can start to vote with the DAO smart contracts (details see below). During the beta phase, the core team multisig will still be legally responsible and in charge so the DAO contracts can be used and tested without the risk of exploits and smart contract issues. Token votes by the DAO members will still be used to form decisions.

so: legally, the core team from phase01 will still be in place, until at least phase03, at which point the DAO can propose changes to the core team if needed.

Phase03 Full DAO Launch​

After Phase02 we will adjust the operating agreement so that the DAO contracts will define the governance on chain and via DAO votes. DAO proposals can be set up by any DAO member and will be voted on by the DAO. DAO proposals in the current setup can only have a Yes/No option.

The core team multsig will no longer be the owner of the DAO, which will then be the DAO members. The core team will be responsible for day-to-day executive decisions, since DAO proposals and voting will not be feasible for smaller decisions. The core team will also be responsible for the LLCs operations and HR and will be able to represent Teia legally i.e. for paper work and propose community votes as well as the budget for operations.

For now, we plan to start into phase03 with the same core team like in phase 01+02 and let the DAO decide on approving or changing the core team.

DAO proposals are mostly intended to define roadmaps/general directions the LLC should take and also montiroring the core team in their operational work and executive decisionmaking. of Course the DAO is free to change this setup via DAO proposals

(this section about phase03 is not completed yet and still under construction)

DAO_Structure DAOVote

Building towards Phase02 and Phase03​

Teia DAO Token Distribution​

We published an extensive fact sheet with a FAQ section on our blog

Note that no token value above being a voting token is implied. The Teia DAO Token is solely intended as a governance token and should not be treated as a financial/investment asset. Due to its non-profit nature, Teia can't and won't distribute profits and can only use funds generated to maintain operations, fund exhibitions, and support education, art, and cultural exchange in general.

All eligible Tezos wallets will be invited to claim their Teia tokens and participate in the development and workings of the Teia DAO. The Teia team is working hard to make distribution as fair and effective as possible. Whoever claims their tokens becomes a member of Teia DAO LLC by virtue of token ownership. The Tokens won't be airdropped. Instead, there will be a website that lets community members claim the tokens based on the following main criteria:

  • Activity: Interaction with Teia’s and/or Hic et Nunc’s marketplace contracts. this is by far the biggest factor in the Token distribution (see blog for details)
  • Contribution to Teia and Hic et Nunc defined by many different distribution parameters (see blog for details)
  • hDAO conversion - a 1:1 hDAO for teia DAO Token reward. (see blog for details)
  • Additional voting reward for participating in the community vote about the overall token supply.

650k Tokens are allocated as hDAO rewards, 300k Tokens are reserved for the Teia treasury (for fututre distribution(s) along with all unclaimed tokens) and 50k will be distributed between all wallets that participated in the community vote on total supply, adding up to 1 Million.

After the claiming period of a few months, unclaimed tokens will remain in the treasury for future drops.

Example: 6 Million Tokens total supply​

If the community for example decides to go with 6 Million tokens as total supply, 5 Million will be reserved for activity with 8% of those 5 Million allocated to contribution, resulting in the following split:

  • 4.6 million tokens (~ 77%) will be distributed based on activity.
  • 650k (~ 11%) Tokens will be distributed based on hDAO ownership.
  • 400k Tokens (~ 7%) will be distributed based on contribution.
  • 300k Tokens (~ 5%) will be locked in the treasury for future drops.
  • 50k Tokkens (~0.8%) to be distributed among participants in the community vote about token supply.

Equity​

Our mission to reach true decentralization and equity includes a community-decided allotment to guarantee marginalized communities are included in governance. We understand that now is the time to take a novel, genuine approach to equitable governance and acknowledging the needs of our most underrepresented communities in a concrete way.

There will be a % (currently suggested 30%) of either quorum votes or overall voting power for the so called "representatives" that are appointed to represent certain subcommunities and regions.

Discussions are currently ongoing if we should allow core team members into a representative role or not. As things stand, it looks like a few reps might indeed be part of the core team but this might be revisited in the future as DAO evolves.

However, in order to make this work, there needs to be a solid structure/procedure for the rep setup in place, this is currently being worked on by the reporesentatives working group

Leaders within these groups are being nominated by the community and will be included in the weaving of the new Teia DAO.

Open Questions and Tasks for the DAO implementation​

The next big challenge will be setting the above mentioned parameters in the main DAO governance contract.

Some open questions need to be answered, such as:

  • due to low response from contacted representatives, it is currently not clear if there will be enough represetentative figures at lauch to make the representative voting possible. However, there is a dedicated place for representatives in the contracts that can be activated as soon as there is a substantial amount of self-organised representatives that are willing and ready to take the responsibility.
  • Deciding on the distribution models (see above) and doing the drop
  • Improving the User Interfaces for all DAO sites (looking for frontend DEVs)

DAO Smart-Contract Development​

Smart contract developer Jagracar currently leads the smart-contract development needed for the tech side of Teia DAO, and the #smart-contract working group in Discord is currently discussing and improving those contract codes.

The DAO token​

code: https://github.com/teia-community/teia-smart-contracts/blob/main/python/contracts/daoToken.py

BCD (testnet): https://better-call.dev/ithacanet/KT1PA5vDBff1Tg7sSe8Xehmz3RbknWA4NJTX/storage

A basic FA2 token contract, similar to hDAO, with some extra improvements:

It takes the idea of balance checkpoints fron the kolibri DAO token implementation. With that we can know exactly the token balance of a given wallet at a given block level. Thanks to that it's not necessary to transfer the tokens to the DAO contract to avoid double voting: The DAO contract simply asks the DAO token contract how many tokens had the wallet that it's voting at the moment when the proposal was created. The DAO token contract returns the exact balance and that is used to calculate the vote weight. This is good, because we will have several proposals running at the same time. It would have created problems if we had to transfer the tokens to the DAO contract to vote. We wouldn't be able to vote with those tokens in other proposals.

It uses on-chain views instead of calback methods. On-chain views are relatively new and are a very good thing to have. For example, hDAO and kolibri DAO don't have on-chain views, and one needs to use callback functions with are a much worst solution. It's not their fault, on-chain views were not available when they implemented those tokens

The DAO Token contract has implemented a rule of a maximum possible balance of DAO Tokens per wallet. We need to decide a % of the total token amount that can be held per wallet (i.e. 2-3% of total Tokens) - This will avoid unfair voting power for "whales" and also make sure No Token holder will have to KYC if we incorporate in the Marshal Islands (-> a wallet that has 10% of all tokens will have to do KYC there)

If we register the DAO in the Marshall islands, members don't need to provide their name and address per se (=KYC). However, Holders of more than 10% of the Tokens need to provide KYC.

Token drop contract​

code: https://github.com/teia-community/teia-smart-contracts/blob/main/python/contracts/daoTokenDrop.py

The idea is that we will create a list of wallets with the number of DAO token editions that they will have: tz1aaa -> 10eds, tz1bbb -> 20eds From that final list we will build a Merkle tree that encapsules the DAO token distribution information. The root of the Merkle tree will be stored in the contract and will be used to verify that every token claim is correct.

We will set up a website where people will go to claim their tokens, similar to the tezDAO website: https://tezdao.org/

There will be a claim button and people will be able claim their tokens. If people do not claim their tokens in a given period of time (6 months?), the tokens will go to the DAO treasury smart contract, and will be used for future distributions.

We still need to develop the webpage to claim the DAO tokens. It's not as simple as just adding a button. It will need to download the Merkle tree from IPFS and calculate the Merkle proof for the given wallet. That will be sent to the DAO token drop contract and if the proof is correct, the editions will be transferred to the wallet.

We can base our webpage in the following template by AnshuJalan https://github.com/AnshuJalan/token-drop-template/tree/master/frontend

Treasury contract​

code: https://github.com/teia-community/teia-smart-contracts/blob/main/python/contracts/daoTreasury.py

BCD (testnet): https://better-call.dev/ithacanet/KT1PV1BjjVZUfbw79YJG3sPuHWQbAPNPan3i/storage

This is the contract that will own the tezos coming from the Teia marketplace and donations and the DAO tokens that have not been claimed and/or are part of the reserve for future use.

The only account that could interact with the DAO treasury is the DAO governance contract (see bellow). Any transfer of tez or tokens need to be approved by the DAO.

Representatives contract​

UI: https://teia-representatives.onrender.com/

code: https://github.com/teia-community/teia-smart-contracts/blob/main/python/contracts/representatives.py

in order to secure equity and representation, we aim to add a % of the total vote to representatives (possibly 20-30%).

It's a modified multisig where each user is assigned to a given "community". A given community can only have one representative. This contract has an on-chain view that can tell the DAO contract if a given wallet can vote as a representative. If the wallet is not part of the Teia representatives contract, it will not be able to vote as representative in the DAO. Representatives votes are associated to the "community" and not the representative wallet. That prevents that if a community changes their representative during the voting period of a given proposal, there cannot be 2 votes from that community.

Current suggestion to prevent individual reps from getting too much voting power in the case of low voting activity within the reps multisig: For a rep setup with 20 communities/regions in the multisig, every representative's vote could be at most 1.5% of the total votes. If 3 representatives vote, their votes will count as 4.5%. If 20 representatives vote, their total vote will be the maximum representatives' vote: 30%.

DAO governance contract:​

UI: https://teia-dao.onrender.com/

code: https://github.com/teia-community/teia-smart-contracts/blob/main/python/contracts/daoGovernance.py

BCD (testnet): https://better-call.dev/ithacanet/KT1SpmiaEkwEg9Q7wsb8G6noEpM5xcRozror/storage

This is the actual DAO. Here is where proposals are submitted, voted and executed. It contains references to the DAO token contract, the DAO treasury contract, the teia representatives contract and the DAO guardians and DAO admin multisigs.

The governance contract currently has the following goveranance parameters:

proposals​

  • Proposal voting period in days
  • Proposal waiting period in days before it can be executed
  • Amount of DAO tokens to escrow to create a proposal
  • Minimum amout of DAO tokens needed to vote proposals

quorum​

  • quorum: the minimum number of votes (in terms of vote weight) that a proposal needs in order to be approved. This parameter adapts with time.
  • Minimum period between quorum updates in days
  • Quorum update percentage
  • Maximum quorum percentage change
  • Minimum and Maximum possible quorum value
  • Percentage of positive votes needed to reach super-majority

voting​

  • Vote weight method (linear or quadratic)
  • Percentage of positive votes needed to return the tokens in escrow
  • Representatives vote share percentage relative to the quorum

All of those parameters, of course, can be adjusted over time. We will probably start with a very simple setup; and improve upon that via voting on proposals.

Administrative Figures within the DAO​

As a safety measure, especially in the beginning when the DAO model is young and not fully tested, we need to implement some adminitrative figues: They can be eliminated later if we want to, by assigning them to a burn address or a dead contract.

UI: https://teia-multisig.onrender.com/

DAO Admin​

BCD (testnet): https://better-call.dev/ithacanet/tz1gnL9CeM5h5kRzWZztFYLypCNnVQZjndBN/operations

The DAO admin figure will also be a teia multisig. The admin cannot create, vote, execute or cancel proposals, but it can modify the main DAO governance parameters. It's a safety measure in case we choose some parameters that are not appropiate. For example, if we see that we start with a quorum that is too high, the admin can lower it to save time. By being able to modify the DAO parameters, the admin can also come into the rescue of the DAO.

For example, they could make proposals impossible to approve by setting the quorum or the supermajority to a extremelly high value.

Guardian​

BCD (testnet):https://better-call.dev/ithacanet/KT1RCXoax1uuWDLrK5n1AzLJMgQbg4D5mmpi/storage

The DAO guardian figure comes into action only in very special situations: When an attacker submits a proposal and manages to get enough votes to have it approved.

That could happen by sending a sybill attach or taking advantage of a period when the DAO participation is very low and the quorum requirements are also very low.In that attack situation, DAO guardians are able to cancel the attacker proposals before they can be executed.

The DAO guardians contract is the same as the Teia multisig contract that we are already using. In order to cancel a proposal, guardians need to create a proposal in the multisig and execute it.

The quorum​

In the context of a DAO, a quorum refers to the minimum level of participation or voting power required for a proposal or decision to be considered valid. It ensures that decisions are made with sufficient consensus and involvement from the DAO's members or token holders.

The Teia DAO smart contracts utilize a dynamic quorum system for proposal evaluation. Initially, a global quorum is set as a parameter, (for example 1000 votes needed). When a proposal is created, it uses the quorum value at the time of creation of said proposal.

After a proposals voting period is over and votes are counted, a new quorum is calculated based on the previous quorum and the total number of votes received; If a proposal received significantly fewer votes than the quorum, the next quorum is adjusted slightly lower (e.g., from 1000 to 900) for the next proposal. Over time, this process aims to reach an equilibrium. Conversely, if the votes fall short, the new quorum decreases. The new quorum applies to all future proposals, while existing proposals maintain the quorum they were created with.

To prevent manipulation, the quorum updates have restrictions. If a recent update has occurred, further updates are withheld. This precautionary measure prevents someone from intentionally creating numerous proposals with minimal votes to drastically reduce the quorum and gain easy approval for a subsequent proposal.

The DAO administrator role has the authority to modify the quorum parameter, which is especially important in the early stages, to make sure the quorum is set realistically and based on current participation. The DAO administrator can utilize the multisig functionality to modify the required quorum and other parameters related to representative shares, supermajority, voting proposal duration, and more. If we switch from linear to quadratic voting, older proposals continue to use the old quorum and linear weight, while new proposals adopt the updated quorum and quadratic weight.

Supermajority​

In the context of DAO voting, a supermajority refers to a higher threshold of support required for a proposal to pass and bring about significant changes within the organization. Unlike a simple majority where a proposal needs to receive more "yes" votes than "no" votes, a supermajority imposes a stricter requirement. The concept of quorum and supermajority is widely used in various DAOs, including Kolibri DAO and Tezos governance.

For the Teia DAO, the supermajority is calculated in the smart contract by dividing the number of "yes" votes by the sum of "yes" and "no" votes. A common supermajority setting would be something around 60% or 70%, but we can adjust the values and experiment during the DAOS beta phase. Abstain votes do not count towards the supermajority calculation. They only contribute to meeting the quorum requirement, not the supermajority.

Finding the right balance is important to ensure that significant decisions require a broad consensus. One potential risk associated with a supermajority parameter set at, for instance, 70% is that a minority of 31% could block proposals indefinitely. This highlights the need for careful consideration and adjustment of the supermajority threshold to strike a balance between consensus and progress. The DAO administrator, a designated figure within the organization, has the power to change the supermajority parameters if necessary. This provides flexibility to adapt the decision-making process and requirements as the DAO evolves.

ORG-Structure suggestions​

for the structure of the Org there are two proposals that seem to be good corner stones reflecting what structure we want to build towards:

Malicious sheeps structure proposal:​

Organization_Proposal Rotation_and_Responsibilites-2

babycommandos Guild proposal​

We are also planning on implementing Multisig contracts for multiple Guilds (=Working Groups) that will enable a voting mechanism on decisions that are better decided by the people working on certain parts of the project in order to make decisionmaking more flexible and faster. find babycommandos Guild proposal here

further reading:​