I wanted to share a dApp prototype that @austingriffith & two of the BuidlGuidl builders built (Viraz + 0xDarni).
This is a dApp that allows a user to stake GTC on Gitcoin Grants based on the Grant quality using Conviction Voting. From there, Gitcoin Grants 1.0 (or 2.0) could then adjust the sort algorithm of the grants based on what grants GTC holders think is most valuable.
Problems this dApp solves:
Allow GTC Holders to have governance utility with their GTC.
Provide fairer starting conditions to the Gitcoin Grants rounds, so it does not become a horse race (where ppl get more contributions => higher matching => repeat)
Check out the demo of this conviction voting dapp. It allows people to trustlessly stake GTC on their favorite grants, signaling their conviction about which grants are quality.
Roadmap from here
Audit the smart contracts
Deploy on Optimism L2
Simplify the UX
(If governance decides to) Adopt this data as part of the sorting algorithm on Gitcoin Grants.
What I think is incredible about this prototype is that Austin + crew conceived + built this in 3 days!
They didnt hire any fancy consultants. They aren’t spending $200k-300k/mo on software development. This was just someone who cares about Gitcoin who chose to work backwards from an outcome + ship the software (and will probably be rewarded retroactively from Build Gulid/Gitcoin if/once this ships). It’s really inspiring to me!
IMO its existential to solve our software dev velocity problems. We cannot continue to plow hundreds of thousands of dollars into software development that is neither fast, cheap, nor good. Questions about priorities are only existential when it takes us 2-6 months to ship any new module. If we could quickly ship slim MVPs it would be less of a zero sum “my priority vs yours” between leaders.
How can we get more rapid prototyping juju (build guild culture) into MSC/GPG? Daniele showed here that a steel thread for a small dApp takes 2-3 days if you have the right builder on a project/focused on outcomes.
Do we want to support this conviction voting app as part of grants 2.0 roadmap?
I love CV (I have been helping to push it forward, and the first time the concept was explained was on Giveth’s blog )
but this is not CV.
But I do agree with Darni and Viraz’s approach! In fact, it’s very similar to GIVpower! (please don’t call it CV).
Funny I read this after shilling GIVpower in another forum post:
The hardest part is parameterizing it and communicating the impact of staking for longer to the user…
In summary tho, that’s why we came up with the idea of GIVpower… if you stake 100 GIV for 2 weeks… you get 100 GIVpower, if you stake for 8 weeks = 200 GIVpower, if you stake for 128 weeks = 800 GIVpower, 200 weeks = 1000 GIVpower (scaling quadratically of course)
Also, mStable had a similar approach and then THEY CHANGED IT!!! I interviewed them about why (1 day of research will save 6 months of testing in prod):
Anyway, we have a bunch of designs and thoughts about how to do this… @0xDarni any interest in a sync? I just found you on Twitter and DM’d ;-D
It’s more “inspired by CV” I’d say - but I have no idea how to call it
Very true, and these are the two major things missing right now. I have a couple of ideas to improve the UX and communication, but defining the parameters will be trickier - especially if we want to make it somewhat sybil resistant.
Absolutely! Would love to chat!
PS: 0xDarni was my old profile - from a time when I wanted to be pseudonymous - I deleted it to avoid confusion since I don’t need it anymore. I’m here now: @danielesalatti | Gitcoin
on the cart page it still says “Remember: you will not be able to unstake your tokens until the set time!” but IIRC there is no set time anymore.
i agree that it would make sense to show the user how much voting power their GTC is worth.
is it easy to write a python script to get the voting power per grant? if so id love to get a snippet of code that does this so i can automatically import these weight numbers into the cGrants DB on a regular interval.
id love to know what other gitcoin product leaders (@kyle@email@example.com ) want to see here to be comfortable using this dApp to create a user signal to rank grants.
id love to know if we can cross-pollinate how you build with the GPG. you move so fast, maybe the GPG could learn something from you?
I quickly changed the schema and mappings, and redeployed the subgraph so now we have an additional entity - which makes querying for that easier.
I’m outside and running out of battery, but this repo should be a good starting point to get to the data you want. It gets the first 100 grants and the related votes and releases, it’s missing the logic to actually calculate the voting power. I can get to that sometime this week
I’d guess from @griff comments that exponential (quadratic) must be the best. Awesome to see this project moving forward FAST. I’d also advise changing the name from Conviction Voting to not confuse people.
I had a call with him a couple of days ago - it was really interesting, he gave me material to read and showed me this: Config 4 | Commons Dashboard
His suggestion (@griff correct me if I missed something) is to replace the spending limit percentage in that model with a fixed multiplier, and make it go from 0 to the max in a pretty long amount of time.
E.g. you can get max 50x after 6 months, so:
you stake 5 GTC on a grant - on day one your voting power is worth 0
over time your voting power grows, and after e.g. 15 days it is now worth the full 5 GTC
after 6 months it reaches 250 (50x) - and it stops growing
At that point if you leave your tokens in, your voting power stays at 250 for that grant. If you un-stake there’s a decay function so it doesn’t go to 0 immediately.
The multiplier and the duration we should decide.
I have another call with him next week. I’m on a trip in NY at the moment - back on Monday - but in the meantime I handed over a couple of optimisations in the subgraph model to @Viraz.
Voting power will be calculated off-chain, so we will deploy to Mainnet soon