Initially, when we were planning to launch in December, the design for the Commons was to use the same Conviction Voting set up that 1hive has been using up until now, with just a change in the issuance model.
The upside here was that, despite never receiving a formal audit, this version of CV has been tested with millions of dollars in it for many months. This is surely more than we expect to have in our Funding Pool a very safe move.
The down side was there were many lessons learned in its use and desired improvements to the code base that were currently in the works, especially around certain points of centralization. The biggest point of centralization that is being addressed is the multisig that holds the role of removing proposals from CV that do not align with the mission of the project.
Our intention was to start with the current version and have Gravity maintain this multisig and upgrade to the new version when it was ready, if the Commons approved.
Current Situation
Things have changed. Our timeline to launch the Hatch is now targeted at March and we can assume we wonāt be upgrading the TEC Hatch DAO into a Commons with Conviction Voting until April.
Celeste, the solution to all of our centralizing Multisig needs (in one way or another) is going to be ready at the end of the month, and will be implemented by 1hive well before our Hatch.
Opportunity
Given these two facts, there is a positive sum opportunity, to combine the Gardens Swarmās development efforts with the 1hive teamās roadmap and focus our efforts on getting the new disputable version of Conviction Voting right.
The proposed approach would have a few results:
Alignment of interests of both 1hive and TEC around a shared codebase as opposed to spending efforts on an old codebase. Specifically, we would help them with the new front end for Disputable CV, and AdriĆ would do a code review of the new code base.
Political alignment with the 1hive community, who has mostly funded the development work so far.
Integrate 1hiveās HNY token into the TE Commons system. HNY would be used to dispute proposals that do not follow the TECās Conviction Voting Terms.
Potentially integrate Celeste in other places as needed.
It doesnāt add any extra work for the Gardens Swarm, and doesnāt slow down the Hatch.
Next steps
We as a community, learn about using Celeste. There are great resources here:
We gather questions from this thread, please write here the questions you have after reading the previous resources.
We prepare an AMA with the Celeste swarm to answer these questions.
We vote on whether to use Disputable Conviction Voting or not. Pros and cons can also be detailed and discussed in this thread (This is a blocker to the Hatch).
If we decide to go the Celeste route, we prepare a TEC Community Covenant with the Soft Gov, Legal & Gravity WGs and propose it as another vote (This is not a blocker to the Hatch).
who picks the ākeepersā? Is it automated by the system who sends notifications to the people with the highest stakes, or an admin is needed to do that?
would be nice to use quadratic staking to avoid a dispute plutocracy
Very good questions and suggestions @liviade! Iāll do my best replying to them, but I think that we can make them again in the AMA with Celeste Swarm, because they will be able to answer better.
who picks the ākeepersā?
The keepers are picked randomly, and the more HNY you have staked in Celeste, higher the probability you are drafted.
would be nice to use quadratic staking to avoid a dispute plutocracy
The major difference between Aragon Court and Celeste is that the last integrates BrightID and sets a maximum amount of HNY that a single user can stake.
Quadratic staking using BrightID would have a similar effect fighting against plutocracy, but it would also incentive keepers to stake as much HNY as they have available. I would love to hear what Celeste team think about it.
the escrow function sounds really exciting!
Indeed! Itās something really needed in the current conviction voting implementation, and thatās the primary reason why I think itās interesting to use Celeste.
Iām wondering how it will affect the autonomy of our DAO when we will be able to resolve some conflicts by invoking Celeste and waiting for its keepers to rule based on the previous agreements we have had reached in TEC.
For me, including Celeste in the dispute resolution is like removing from the center of the DAO the will of the majority of TEC tokenholders and put a set of agreements and rules in their place. Token holders must comply with the set of rules that were put there on its foundation, since they are externally enforced and they have a limited power to change. To my understanding this limits the sovereignty of the DAO, but protects the minorities by setting up a common ground that can not be changed by the big tokenholders of the DAO.
A few more questions are popping up
I thought Disputable Voting was like an upgrade of the Dandelion DAO.
Is Disputable Conviction Voting a different dapp, or an upgrade of CV as well and we would have the disputable features both in DV and CV? @Griff@sem
The initial idea was to use Dandelion Voting in both the Hatch DAO and the Commons DAO (the original Gardens Template was using Dandelion Voting). The plan has changed with the release of Celeste, and we are not going to use Dandelion Voting after the Commons Upgrade. Both Voting and Conviction Voting in the new DAO will be disputable (aka Disputable Voting and Disputable Conviction Voting), which means that votes and conviction voting proposals will be able to be paused and disputed in front of Celeste.
While Disputable Voting for Conviction Voting makes sense, the Disputable Voting for Tao Voting does not.
I was hoping someone could comment on this.
With Conviction Voting, the subject matter of the vote is centered around the funding of a proposal that may or may not be in alignment with the TEC Community Covenant ā where a judgement of this alignment can be obtained through Celeste.
With Tao Voting, the subject matter of the vote is centered around the parameters of the smart-contracts for our core infrastructure and is inherently neutral to the values and orientation of the TEC Community Covenant.
Iām not sure how Celeste would resolve a challenged proposal that passes a change in Support Required to say 5%ā¦or as with our current vote ā a change in the Entry & Exit tributes.
Such an interesting question, letās see if I can explain the rationale behind the decision of making tao voting disputable.
As you are saying, itās easy for celeste to see if a funding proposal aligns with the covenant of a garden. So the first reason why tao voting must be disputable as well is because it can also request funds from the common pool and the proposal will pass if enough people votes positively.
A more extended way to see it, is that tao voting (the rule of the majority) can do anything in the DAO (move funds, mint and burn tokens, change parameters or even install and āuninstallā apps), and the DAO stakeholders can write anything in the covenant to limit what is possible in a voting as well.
You can think of it as a constitution that grants rights to everyone participating in the DAO, a way to protect the minorities from the tyranny of the majority. It doesnāt mean that it has to be used this way, but it is healthy for a DAO to have this checks and balances with the appropriate covenant.
Thanks for the clarification. Do you know of any Covenants right now that set minimum/maxium restrictions on parameters, or discuss any aspect of modifying the smart-contracts?
**Also, does the current Aragon DAO for the TEC utilize the Aragon Agent?
Do you know of any Covenants right now that set minimum/maxium restrictions on parameters, or discuss any aspect of modifying the smart-contracts?
There is none Iām aware of, but it would be easy to add in plain text. You can also add conditions on how to change the covenant itself. If those conditions are not met when there is a covenant change proposal, it can be disputed.
does the current Aragon DAO for the TEC utilize the Aragon Agent?
Yes it does. It uses an agent for the reserve (holds the bonding curve funds), the common pool (holds the conviction voting funds), and it has an extra agent that can be used if you need to hold funds only accessible by tao voting (the initial buy funds, for example).
There is a classic example of why we need disputable voting for yes/no Decisions Votesā¦
Anyone could create a proposal that says, send all the assets in the DAO to the contract that will distribute the assets between everyone who voted yes on this vote.
For a purpose driven DAO with a strong culture, we probably wouldnāt fall pray to this kind of vote, but this sort of vote shouldnāt be possible at all, and the Covenant stops it.
Thanks for the clarification. Do you know of any Covenants right now that set minimum/maxium restrictions on parameters, or discuss any aspect of modifying the smart-contracts?