I don’t think delegations should be activated. The purpose of the proposal to create the UBI DAO was to prevent whales from having huge economic power from making decisions, that’s why we implemented QV in the first place. Activated delegations should be explicitly debated because it breaks the whole purpose of why we went on the Quadratic route in the first place.
If you want delegations on the UBI DAO, you can go for a UIP and we can vote on it.
Delegations are always possible (make a vote copy voting your delegate), they just have a very bad UX. I would never have voted for making a UBI DAO purposely making delegations a bad UX (which would actually grant an advantage to tech people and potentially lead to security issues with key management).
They do not break quadratic voting, they are just counted afterward.
The proposal had no mention of a bunch of parameters (like deposits for the governor, juror, etc) and it was assumed that those were similar to the current UBI DAO.
If you disagree, the procedure would be to have a board vote on the interpretation of the HIP.
I’m fine with the board doing an oversight over this. My understanding was that we voted for a new game altogether with Quadratic Voting and the main reason we took that route is to mitigate whale influence in the DAO. After re-reading the HIP 22 there’s no mention at all about delegations in the text.
Either the proposal was not defined enough and therefore not implementable.
The elements not specified by the proposal are to be considered not to be changed.
Actually there isn’t any mention of delegations in the POH DAO (same for the Kleros one). The UI facilitating delegations is just an assumed good UX.
Moreover, without delegations, all users with smart contract wallets would have their right to vote taken away from them (as those can only vote through delegations, potentially to an external account they control).
Delegations is an assumed good UX when you do 1p 1v… and even then it’s still debated by some (we had ongoing conversations about this on the Telegram groups).
I think HIP 22 is pretty clear about the implementation. I quote:
A Snapshot Page for UBI DAO will be created using the UBIVOTE token.
It doesn’t say simething like “UBI DAO will copy the PoH DAO”, it simply states that a new snapshot page should be created with the token and there’s no specific mention about delegations at all.
Those who have delegated their power on the PoH DAO did it so expecting that to influence over the PoH DAO, not under the logic of a new DAO that uses coin-voting and QV. That’s an entirely different game, that actually brings disincentives to buy UBI for governance because with your delegations and mine, someone would need something like 7M UBI to earn similar voting power.
So NO, it’s not the same at all. Taking into consideration the many debates had around what governance was going to be implemented for UBI, I would personally not feel ethically comfortable implementing a rule that it wasn’t agreed by the community in the first place.
The thing is that it is not a rule (it doesn’t allow to do anything which wasn’t allowed previously). It’s a UX.
People can always copy vote other people.
Would feel comfortable removing voting rights of people using smart contract wallets (argent, gnosis safe, etc)?
Making it hard to delegate and removing categories of voters kinda looks like voter suppression while delegation doesn’t allow anything which wasn’t previously available.
I think we here have to agree to disagree and we’ll need a proposal for that.
In the meantime, we should get a clarification of the board about:
Will delegations be discarded in the meantime?
Which entity should vote on whether the UX should facilitate delegations?
We did a significant change of rules by introducing QV and coin voting. Delegations simply do not mean the same as in 1p1v under a change of rules like that.
I find clandestinely introducing delegations when these have not been explicitly voted for in the rules of the new DAO a highly unethical move.
Claiming liquid democracy is just UX is not right. It requires specifically introducing a strategy in the DAO rules and the implementation procedure of HIP 22 was very clear about the setup.
Delegations are already there, they are just reserved to tech people. As soon as we use something controllable by software delegations are there. Now they can either be there only for people spending a lot of time and coordination or they can be there for everyone.
Now if we were to have to burn UBI to vote, then we could prevent delegations.
It is exactly what it is, nothing prevents people running a program in the background voting as your delegate. It is just about the UX (and also not removing voting rights to smart contract wallets).
Delegations are not by default activated on Snapshot. Anyone can build a software to delegate sure, but if you want to introduce them on Snapshot you need to specifically configure it with the corresponding strategy. They are not there by default.
When the PoH DAO began, it had a tabula rasa: everyone began delegating from a 1 person 1 vote initial setup. Inheritance of delegations that where not aware of being used for anything else but PoH DAO suddenly being used on the UBI DAO is neither legitimate nor credibly neutral.
Also there’s absolutely nothing in the HIP 22 text that suggests using delegations on the new DAO. It’s preposterous to pretend that was somehow granted. Even more so, the proposal aims at the purpose of increasing the demand for UBI by expanding its utility for governance. Inherited delegations go completely against this purpose since that would only consolidate power on 2 whales (me and you) and would disincentivize buying UBI for governance for anyone else.
Implementing delegations without legitimacy from the community is simply very irresponsible.
Delegations can either be domain specific or generic. If they are domain specific, they will not be ported. If they are generic, they should be.
What about removing smart contract wallet users their voting right?
Since you need it linked to your POH profile, contrary to other DAOs, you can’t just move your UBI to an external account. Smart contract wallet users would have their voting rights taken away definitively.
Making the delegation UX purposely hard would give a huge advantage to people spending their time to campaign for votes. This would result in tons of time wasted in reminding your supporters to vote on everything. This advantages politicians instead of builders (until someone makes up a copy voting bot where it would then advantage tech people).
Just in the spirit of finding common ground here: I don’t mind having a solid debate about this issue and voting about it, so if in the case the community agrees on this, delegations are implemented legitimately and not clandestinely.
But I disagree HIP 22 supported this in any way. The main reason we went for QV was precisely to cap the influence of whales, not consolidate their power. The steps describing how to implement the DAO itself where instructive and crystal clear in the text.
The thing is that having a bad delegate UI will increase the influence of whales, as only tech/highly involved people will be able to act as delegate (via a copy voting bots).
So can we agree on a way to go to decide whether we allow delegation in the snapshot UX?
In your opinion, should it be:
A vote of the POH DAO clarifying the meaning of HIP-22.
A vote of the UBI DAO (here we run the issue that depending of delegations or not, the result may be different).
The thing is that having a bad delegate UI will increase the influence of whales, as only tech/highly involved people will be able to act as delegate (via a copy voting bots).
Does snapshot.org support commitment-scheme votings? I guess that would be a good way to avoid copying votes.
My interpretation is that details that are not specified in the HIP should default to as little change as possible - not a reset. So if it is not specified then the delegation of UBIDao should be as similar to PohDao as possible, so with the delegations.
As little change as possible is following the text that was voted on the HIP. None of it suggests that one DAO inherits the features of the other. This is simply wrong and irresponsible with the content of what has been voted. More so: it goes against the spirit of increasing UBI’s utility for governance.
And I say all this being quite possibly the person who would benefit the most with delegations on.
And here’s the Pull Request with all the code changes:
I’ll proceed to advance this to a Phase-3 proposal.
Further testing is required now that the token exists on Kovan. We’ll be working on a UI for it and if anyone wants to help out sending / receiving UBI test streams, let me know.