Amazing new systems in the works! Excellent to see everyone putting in so much time & effort.
Just to clarify a concern, are there any conflicts between the new UBIVOTE system and how it interacts with the proposed Delegated Streaming system?
I.E: Does delegating your $UBI to another user reduce the hourly increase in democratic power your votes have over time? It would be a shame for people to be conflicted between their own democratic voting power & the choice to delegate to another user for a meaningful period of time.
Also, good idea with the square root system for UBIVOTE! It helps mitigate people delegating their UBI to one person in order to increase a single person’s voting power (as it’s more lucrative to just keep their own tokens and vote)
Well, the UBIVOTE proxy token will simply look at your UBI balance and calculate the square root…
if you are streaming say 20% of your UBI to someone else, then your balance will have 20% less UBI in it, thus impacting your voting power on the UBI DAO
but think about this: a good use case for streaming might be delegation of power itself! the community could organize around a leader and stream power to that person… making that person influential in the decision making process of UBI and able to challenge UBI whales (like myself )
I thought about it as a good use-case, but as we use a square-root system, wouldn’t it be a little inefficient to delegate UBI to increase another’s voting rights?
I.E:
2 people have 10,000 UBI and their vote is worth more separately as two 10k votes, than one 20k vote.
√10,000 = 100
x2 = 200 UBIVOTE
√20,000 = 141 UBIVOTE
Positive: Mitigates a group (or person with multiple successfully registered accounts) being malicious by creating an individual with a lot of voting power
Negative: Makes delegating UBI to a genuine, influential individual for increased voting power inefficient
Perhaps there is a tweak somewhere to increase the efficiency of, as you said, streaming voting power?
But otherwise I LOVE the work so far: Delegate income & potentially democratically delegate voting power! Shaking up the world one code line at a time !
Indeed it’s more wise to keep the UBI for yourself in the governance of UBI DAO… this makes the route of buying UBI still the best route to increase voice power (which at current prices, might be a good move imho… fwiw i did buy to vote on the first UIP).
Let’s keep in mind that the bottom line here is to find more and more ways that make UBI valuable. I’d like to unpack a bit more @clesaege’s ideas on how UBI credit could work with streaming.
An infinite approval to an streaming contract would have the same effect (note that you’d still save some gas as it would not be necessary to call the contract often, but for saving gas in really edge cases, you lose gas in the common ones).
From my understanding, the UBI DAO would take the same parameters/options as the POH one unless specified otherwise. Also delegations are not really a voting method but an UX one (it’s possible to set up a bot to copy vote on another user, the snapshot module just makes that easier). So from my understanding delegations should be counted.
Taking the square root is done before counting for delegations so there is not such an issue.
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.
)
!