Discussion: Using DAI as a unit of conviction instead of percentage

[sembrestels]

@GriffGreen commented on the figma:

75% conviction needed.... doesnt really mean much.

Using the Threshold formula as a part of the equation... you can correlate what we call "Conviction" to a DAI amount.... I think this is critical for people to understand what is going on.

What this does is effectively sets a stable "Conviction Needed" and brings more data into the graph.

Conviction has some weird units that are like time*tokens or something crazy... that really doesn't make any sense to anyone.... Making it a % is better but then that % is going to change based on the threshold formula... we will keep changing the goal on the user and i think that is confusing, and may make the user loose faith that things are working right.

But if we give conviction the units of DAI, then the graph begins to show a lot more interesting data... it brings in the changes to the funding pool and token supply (that currently are changing the % of conviction needed) into the actual graph!

The big dream for me here is that later on, we can use this like CLR matching to incentivize direct donation to a proposal to lower the amount of conviction needed.

Currently, conviction is represented as a percentage where 100% conviction means that all existing tokens have been staked in one proposal for enough time. It is a good unit of measure because:

• Accumulated conviction expands or contracts depending on token supply but doesn't change on anything else.
• Needed conviction (threshold) doesn't change at all when there are changes in the token supply (as the threshold is usually linearly dependent with the supply).
  • So, the goal will be changing depending only on one variable: on how much money there is in the vault (as the requested amount keeps constant), as it is defined by the threshold formula.

I think the current approach is a very good one, as we can see how conviction is growing at the same pace on all proposals, not affected by the threshold formula (not depending on how much money is requested). And as the goal only changes depending on one thing (the available funds), hopefully it will be easy for people to learn how to use it.

I also don't like the idea of using DAIs as a unit of measure because:

• It is not as stable as the one that we are using.
• It is better to separate the units for each one of the main concepts: tokens to stake (TKN), funds (DAI), and conviction (%).

On the other hand, we can still do a something similar to CLR in which we can show the impact of different amount of donations. When donating directly to a proposal, we can show the impact that it has in it, lowering the threshold by a certain %.

[GriffGreen]

First off... I dont think this is sooooo critical that it needs to stop you from pushing out an MVP on mainnet... but I do think it will need to happen for people to be able to use this thing without having to understand how Conviction works.... and that has to be a goal for CV, they shouldn't have to understand anything to feel informed enough to use it.

My main gripe is that if the chart shows just conviction over time... we lose track of the fact that the threshold is moving over time... If you are going to have a graph vs time... it should include that data...

So as a Compromise I would suggest we have something like this:

Or even better... base that future line off the historic data

Either is good enough for mainnet, but i think we can make this 10x simpler by removing Conviction from the interface completely. (I know the NAME! Its ok.. google doesnt show the page rank algo on the page either)

The challenge is that, from a users perspective they don't give a fuck about conviction. When they are looking at the proposal, they want to know what it needs to happen to get 150 DAI sent to the proposal owner... so it makes sense to make 150 dai the goal... if they see 150 dai on an axis, they know what it means.

They shouldn't have to think about what % of the max possible % of conviction is currently needed to pass...

Also.. i dont think that the conviction graph.... while very pretty... matters... It just doesnt... its a fun math equation that happens, but on its own.. without the threshold... its incomplete info... which IMO is worse than no info at all.

So now we need two lines on the graph... to give the user the info they need AHHHH why!

Conviction % is a confusing idea that the devs have to figure out but it can be magically hidden from the user.

Besides that... its best, IMO, to keep all numbers given to the user constant, and move anything that is going to change to the chart... if we start changing the numbers we give to the user around the rules of the game, they will start to distrust the game.

"You said i needed 46% to pass... but now you say i need 57%... wtf I dont even understand how you calculate this %? Why does it change? Is this a scam?"

This is a little bit better if the chart threshold line moves as i put it in the pics above... but it still shows the user a graph with an axis and 2 lines that they would have to do some deep research to make any sense of them.

If we combine the threshold formula with the Conviction formula, people can see the actual progress the proposal is making towards its goal over time with one line, and because its denominated in DAI we can get rid of 2 confusing concepts! the threshold, and conviction!!! They will just see the line as an aggregation of data that is moving towards an understandable goal.

OMG Let's throw a party! User's can now use CV with confidence without having to understand the threshold or the Conviction math.. they can just watch the progress over time and see a prediction of what will happen when they add their support!

.... FUTURE BOX...

And it makes it easy to add this very important feature eventually :-D If the user sees this proposal has 125 dai worth of support... but it needs 150 dai, they can just say "fuck it i'm donating 25 DAI to this proposal right now and passing this thing!" :-D

This is the CLR Bump and would make CV interoperable and would allow it to cooperate with other orgs that are value aligned :-D

So AWESOME! So out of scope...

[GriffGreen]

Here is a mockup that really dives into that idea:
https://commons.invisionapp.com/console/Conviction-Voting-Prototype-ck0khwxhk02hd01d23mgl75rg/ck0khwyqe0myb01c7f6rnsv06/play

[GriffGreen]

I still want this so bad

[GriffGreen]

I still want this so bad...

Do i get more voting power for this since its been like a year? Thats a lot of Conviction

[GriffGreen]

I still want this... conviction abundance

[GriffGreen]

To continue my rant and re-up my conviction

I think this would be huge for UX and also later interoperability!

If you can denominate the Conviction in the currency the proposal is asking for, then multiple gardens could cofund proposals
and maybe with Giveth or Gitcoin, we could donate to that proposal too! lowering the Conviction required.

The conviction concept is so confusing
if you could just see that when your Conviction grows its getting closer to the proposal $ amount, it would be sooooooooo nice and understandable, it would take out 2 completely technical and NOT IMPORTANT FOR THE USER TO UNDERSTAND concepts:

Conviction and threshold

We need to get them out of there

IMO the experience of voting with CV should be like donating on Giveth/Gitcoin, not like voting at all.

With a "voting" cart and more like:
"I like that one, I like that one, ooo... that one is nice... Oh damn, I'm out of tokens... ok i will take from that one and give to this one... ok i can vote now"

Then 1 tx and you have voted for your whole cart!

Let's make voting feel like shopping on amazon!

or even better!