TezQF: A Quadratic Funding and CLR matching based grants platform on Tezos

[AnshuJalan]

Background and Motivations:
There has been a rapid growth in the number of projects which are showing up on the Tezos ecosystem. Until now, most of the grants and support has been provided to the projects by Tezos Foundation, and other equivalent organizations. We believe that with Defi, Gaming, and various other spaces heating up on Tezos, it is about time we have a more robust grants platform which makes it easier for the funds to reach the right projects.

TezQF is a match funding platform, based on the foundation of Liberal Radicalism. Its core idea is inspired by the concept of Quadratic Funding as put forth by Vitalik Buterin, Zoë Hitzig, and Glen Weyl in their paper - Liberal Radicalism: A Flexible Design For Philanthropic Matching Funds.

Match-funding is an extension of crowdfunding. In addition to the contribution received from the community in a matching fund scheme, sponsors provide a ‘matching-gift’, usually in a 1:1 ratio. If Alice receives $1200 of community contribution for her project, she would be gifted an equal sum of $1200 by the sponsors.

Although this provides a better insight to the philanthropists and sponsors to direct their funds to the best of the entities, standard match-funding has a practical flaw that gets even more so exposed in a decentralized setting. To understand this better let’s consider an example-

• 10 contributors donated a total of $1200 to Bob for his project whereas,
• John received the same amount i.e $1200, but from just 2 contributors, where one of the contributors was possibly his rich friend who contributed a hefty sum.

This indicates that Bob’s project has a higher community reach than John’s. Yet, both of them end up receiving the same match from the sponsors. Taking such situations into consideration gets trickier on a decentralized platform, as an entity might end up contributing to itself using a pseudo-anonymous account, thereby increasing the overall match significantly.

How can we design a better platform? Enter Quadratic Funding and the concept of Capital-constrained Liberal Radicalism (CLR) matching.

Mathematical Idea:
Simply put, in quadratic funding the match amount is calculated as the square of the sum of the square-root of the contributions. As an equation, this would be-

Where is the individual contribution of a community member.

Considering our previous example, let’s say Bob received $120 from each of the 10 contributors whereas John received $1000 and $200 from 2 contributors, then-

We can see here, Bob’s match is significantly higher than John’s even though the contribution amount is the same. This is how CLR matching factors in the reach of the project.

On our platform, since we are having a funding pool consisting of limited funds at the start of every round, matching exactly to the result of the quadratic formula won’t be practical. Therefore, we use the result of the formula to calculate the ratio of subsidy weightage and then match accordingly.

For example, in the above situation, if the funding pool has $10,000:

So, Bob would receive 85% of $10,000 whereas John would receive the remaining (Considering these are the only 2 entries).

To get a more in-depth insight into this, check out this article.

Architecture and Implementation:
TezQF can be somewhat related to Gitcoin Grants on Ethereum. Gitcoin Grants has a mixture of on-chain and off-chain components to it to manage security. However, with TezQF we are trying to put a majority of the features on-chain.

To achieve this we have created a Decentralized Autonomous Organization (DAO) governing various aspects of the funding rounds through a token voting mechanism. Under the hood, this mechanism would follow Quadratic Voting which would factor in the number of voters, besides the number of tokens used for a vote.

Our overall architecture consists of 3 smart contracts- A FA1.2 token contract for TQF governance token. A TQF DAO contract for handling all governance-related actions like round proposals, round initializations, and entry disputing (explained in detail in a later section). Finally, a Round Manager contract to handle all aspects of the funding rounds, like collecting contributions, receiving project entries, and matching the sponsor funds.

Initially, governance tokens will be generated for the original team of developers and shall be extended to other members as they join the team.

Basic architectural overview of the contract functionalities:

Activity Diagram of functionalities:

Important Actions:

Setting up a funding round proposal:
Any TQF token holder having a balance above a certain threshold (2000 as of now) can set up a funding round proposal which shall be voted upon by other token holders by temporarily depositing their tokens. The voting decision will be made through quadratic voting.

Entering a funding round:
Any individual/team seeking funding for their project idea can enter an active funding round anytime. They have to provide some necessary details like a link to their codebase, an elaborate description, and the category their project belongs to.

Raising a dispute:
Any token holder can raise a dispute against a project listed in a funding round if he/she believes that the project is violating the integrity of the platform. To do so, the person must stake a certain amount of tokens (200 as of now), which shall be returned to him/her if and only if the dispute stands after a session of voting.

Voting for a round proposal or dispute:
All token holders can vote once, for/against any on-going proposal to conduct funding round, or a dispute being raised against an entry. To vote, the holder needs to deposit a certain number of tokens as he/she wishes (this number stands for the weight of the vote). These tokens shall be returned once the voting period expires.

Contribute:
All community members can contribute XTZ to the projects of their liking. There is no minimum limit on the amount of contribution. Because of the CLR matching, that we have implemented behind the scenes, even a contribution of < 5 XTZ from a few contributors could lead to a significant match.

Sponsor a round:
Anyone can become a sponsor by contributing XTZ to the match-funding pool during the donation period before the start of every round. As of now, we do not have a minimum limit for the sponsorship amount.

Why on-chain governance?
On-chain governance would be a must since we are planning to keep the entire platform as decentralized as possible. Besides deciding on when to conduct the match-funding rounds, another important aspect of the governance model is to ensure that the listed projects maintain the integrity of the platform, and there’s a fair distribution of the CLR match.

Identity is a major issue when dealing with a decentralized setting. For a majority of the projects, the identity would be pseudo-anonymous which would lead to the issue of trust. Gitcoin Grants on Ethereum requires the entries to login using an aged Github account to participate. This ensures the identity, but there are still some potential issues.

Quadratic Funding is prone to Sybil attacks. Wherein, one person can create multiple pseudo-anonymous accounts and contribute a small amount to his project using each of the accounts. This would lead to an unfair distribution of funds. As of now, there’s no full-proof way to tackle Sybil attacks, but such an attack pattern is quite identifiable, and when combined with a voting model, any project appearing to self-contribute through multiple accounts can be voted against and disqualified.

Project Status:
We are currently in the development stage with a demo running live on Delphinet. We are also planning a change- a mandatory security stake for all project entries. A part of this stake will go to the disputer in case the project gets disqualified.

We would soon be going for a public presentation to receive community feedback and consider any suggested changes. The link to the presentation will be posted in this thread soon. Meanwhile, all community members are welcomed to watch our platform walkthrough and give their valuable suggestions for improvements and addon.

Walkthrough video: TezQF demo
Codebase: TezQF Github.
Live on Delphi: https://tezqf.vercel.app/ (Requires Thanos Wallet)

Credits:
We are a team of Tezos India Fellows, building this project with support from Tezos India Foundation. We would like to thank Om Malviya, Jignesh Vasoya, Aditya Gautam, and all other members of the Tezos India team for mentoring us.

Our team in the forum: @GunaShekar02 @AnshuJalan @yashmuchhala

[Blindripper]

@AnshuJalan

They have to provide some necessary details like a link to their codebase, an elaborate description, and the category their project belongs to.

Would Milestones be possible? Like Kickstarter has it?
Or would incentives be bad in that case?

[murbard]

Let’s say I want to give 100 tez to a project but I also want to maximize the matching. What’s preventing me from giving 1 tez each to 100 people and ask each of them give one tez?

Edit: just noticed you talk about it,

Quadratic Funding is prone to Sybil attacks. Wherein, one person can create multiple pseudo-anonymous accounts and contribute a small amount to his project using each of the accounts. This would lead to an unfair distribution of funds. As of now, there’s no full-proof way to tackle Sybil attacks, but such an attack pattern is quite identifiable, and when combined with a voting model, any project appearing to self-contribute through multiple accounts can be voted against and disqualified

Can you elaborate on that? How will you know? It seems to me like the main issue with quadratic voting (self-contribution is also an issue for any matching mechanism but perhaps easier to detect).

By the way, it’s great that you’re doing this and I don’t want to sound overly critical, I think avoiding people gaming the process is key so I’m encouraging you to focus on it.

[Ableson]

Maybe the Decentralized Identity solution offered by Spruce Systems could be intergrated to the process. That way you might be able to deal with Sybil attacks.

[murbard]

It does help, but it doesn’t directly prevent you from onboarding 10,000 real people (with decentralised identities) to whom you pay a small sum of money to split the funds you give.

[AnshuJalan]

Although we do not have a Kickstarter Milestones like feature right now, we do have the flexibility to integrate it. Whether we should make incentives a part of the actual CLR matching system, or keep it separate as something that is dealt with in between the funding rounds, that is one thing to ponder upon.

[AnshuJalan]

I completely agree with you. False identities would be a major issue to tackle here, and we are looking into better techniques for handling this.

As of now, we are also vouching on a combination of an identity solution and crowd wisdom (referring to governance token holders). All the contributions received by a project are listed on the platform, so an alarm could be raised if an unusual pattern of donation appears. For instance, if a project has received an equal or somewhat similar contribution from a huge number of accounts (say, ~1 xtz from 100 individuals) a dispute can be raised against it, and other governance token holders can verify the same and disqualify the entry.

Although this could work initially, it would not be practical as the ecosystem grows and there are plenty of contributors for all the projects. So, we really need to look into this.

[Blindripper]

In my opinion, this is a problem that can not be solved on the chain.

I could transfer cash to someone and ask them to vote. Even if the problem on the chain is solved, something like this will never be prevented.

The question is how likely is such a thing, is it worth it at all and is a project that wins this way sustainable?

Maybe Milestone payments might prevent obvious cheating. By only making partial payments based on certain progress (governance/multi sig).

Example:

10% at start
10% after deployment
30% after the first 1000 transaction (could also be faked, bad example )
50% after 3 quarters running.

Unfortunately we don’t come around, that humans must judge about such things until GPT-5 or GPT-6 is released.

[cryptonoobmaster_69]

I guess the words “such a pattern is quite identifiable” are strong. You can probably mention that while it’s not impossible to prevent such an attack, but a formal set of rules may help avoiding it.

But yeah, I also agree with milestone based approach. If we take example of Gitcoin, it’s heavily used by sponsors for bug bounties or other tooling development, in which case sponsors who are putting big money are likely to make sure that money is going to the right person.

[AnshuJalan]

Milestones-based payments do sound like a nice addon which could minimize the possibility of a project gaming with the system. Although I am not quite sure if the milestones model would fit the actual mechanism of matching rounds. A typical round would last for about a month, so the timeline would be pretty conservative for well-defined milestones.

Kickstarter follows standard crowdfunding, and Gitcoin has a separate contribution scheme operating in between the CLR matching rounds, which gives them the flexibility to include milestones like features.

P.S: This is just one way of looking at it. We too can extend the contribution scheme to operate in between the rounds and/or tweak the math to factor in the milestones during the rounds itself. We need to experiment and decide which would be a better option.

[Blindripper]

Just to clarify, i have used the wording “milestones” in this thread with 2 different meanings.

A) Milestones for contributors: Get something for your contribution (a special card, hand signed Shirts etc.).

B) Milestones based payments for the project itself: Payouts based on set goals.

[trolleps]

Milestones to decide whether to send a new payment or not sound great but how do we decide? can be manipulated as well

[AnshuJalan]

It would require the entries to give a proof of milestones which can be verified by voting. So, genuine proof could be a codebase and/or a deployed version of the software. I guess there would not be much scope for manipulation when an entry is called upon to show the actual work.

[Paisley]

Another possible attack pattern could be if many different contributors received tez originating from one or a small handful of accounts.

[faddat]

@AnshuJalan

Liberal Radicalism: A Flexible Design For Philanthropic Matching Funds

Your writing here is so clear that this is in fact the very first time that I can say that I understand quadratic funding. Thank you so much for that, I have not understood the concept until now even though I have heard about it maybe 100 times.

Seriously, thank you for this writeup and for avoiding needless jargon.