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!
What can we learn from this type of rapid prototyping? Can we sprinkle some of this culture in the Moonshot Collective + Gitcoin Product Group so that we can ship Grants 2.0 well before the overton window closes?
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.
I am a strong advocate of focusing on minimum shippable increments. This GTC Conviction Voting dApp is a great emergent example of that.
Prompts
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: https://gitcoin.co/danielesalatti
Little update for those who are following this thread and want to play with the test version.
The repository has been renamed. It is now here (the link from the OP will redirect anyway). Still temporary, but communicates a bit better what project the repo is about.
The ERC-20 contract you need to mint some test tokens on Rinkeby is here.
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@lthrift@kevin.olsen ) 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.
Itās great to see another dApp being build around conviction voting. Conviction voting brought me to web 3 in 2019 Thanks to 1Hive
From a Grants perspective this will be a very useful signaling tool for our community. Would be curious what can be build on top of it or in continuation
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
Nothing that canāt be solved: we can quickly build a UI to let people bridge GTC to Optimism in a few clicks from the dApp, or we can use a different L2.
We can do anything
I think the decision in the end should be coming from you / the DAO. I am not aware of what the long term plans are for the token and L2 adoption.
In what values do you ground these prescriptions for increasing voting power over time? Indeed, it seems pretty off to me to formally punish deliberation in the staking process as you prescribe.
Deliberation is key to plural forms of social organization!
Does the 250GTC max apply universally? If Iām a whale and I drop 250GTC is my voting power maxed out at 15 days or does it really grow to 12500 GTC in 6 months?
)
I interviewed them about why (1 day of research will save 6 months of testing in prod):
- I deleted it to avoid confusion since I donāt need it anymore. Iām here now: 
