In October 2020, our team presented TezQF, a POC of a grant and crowdfunding platform on Tezos that was built on the foundations of Quadratic Funding and Liberal Radicalism. We received some valuable insights and constructive criticism on our Agora thread, which steered us forward into rethinking the design and come up with a sufficiently secure, decentralized, upgradable, and easy to use platform. We present to all, Kickflow!
What’s the deal with Liberal Radicalism in crowdfunding?
The Capital-constrained Liberal Radical (CLR) mechanism introduced by Vitalik Buterin, Zoë Hitzig & E. Glen Weyl in their paper, allows for a near-optimal distribution of sponsor funds amongst public goods in a match-funding scheme.
This is achieved by factoring in individual preferences for a public good, in addition to the monetary contributions received by the same. The idea is inspired by Quadratic Voting, i.e instead of using the age-old 1p1v mechanism, the match amount (now, known as CLR match) would be calculated as (being proportional to) the square of the sum of the square roots of the contributions received in a pre-decided period of time.
For a clearer understanding of CLR with examples, check out our Agora thread.
How does Kickflow work?
Kickflow is built with the idea of a self-sustaining and self-evolving ecosystem in the mind. Besides being a general crowdfunding platform where owners of public goods could raise money, Kickflow can conduct completely on-chain funding rounds managed by a DAO. All executive decisions are made using a token voting mechanism.
Funding round refers to the period in which — sponsors would fund a match funding pool and contributions received by a public good (typically a Tezos based project, but not limited to it) would be factored in to calculate the CLR matches that owners of the good can retrieve from the pool.
A close cousin of Kickflow is Gitcoin Grants, which has implemented the concept of CLR on Ethereum. Although there are similarities, Kickflow does a few things differently.
Timeline of a standard Kickflow Round
A standard Kickflow round would go about like:
- Sponsors fund a matching pool using a stablecoin. [10 days]
- Projects (public goods in general) could join the rounds by making a returnable security deposit and start accepting community contributions, in tez & FA1.2 compliant tokens. [30 days]
- The system enters a cooldown period and contributions are no longer included in the CLR match. During the cooldown, round entries can be flagged and disputes can be raised in the DAO if a collusion pattern is detected in the contributions. Thereafter, the disputed project can be voted against and disqualified from the round. [7 days]
- The payout period begins, during which entries can retrieve their CLR match payout from the sponsor pool. [30 days]
Governance
Kickflow is managed by a DAO, which ensures maximal transparency and decentralization. The DAO functions based on a token voting mechanism. It allows members to submit proposals and vote on them using the Kickflow Governance Token (KGT).
A proposal has an underlying smart contract that wants to invoke a protected entry point of a certain contract in the Kickflow ecosystem. For the operation to go through, the proposal must be voted upon and reach quorum. Some examples of proposals include-
- Proposal to change DAO parameters like — voting period, quorum threshold, sponsorship stablecoin, etc.
- Proposal to mount a funding round contract. Each round is handled by a different contract, which must be approved by the DAO before it can allow entries.
- Proposal to set the CLR match ratios of the entries in a funding round.
- proposal to disqualify a round entry that has violated the rules of the ecosystem.
Upgradability
Upgradability is one of the most important aspects of Kickflow. As mentioned above, every round is handled by a fresh contract that must be approved. This allows for feature addition and changes in the funding round logic.
As for the DAO, besides the usual parameter updates, the entire DAO could be upgraded to a new version through the proposal system. The Governance Token stays the same across the upgrades.
Collusion prevention
Collusion and fraud are some of the major issues of decentralized quadratic funding. The owner of a public good can possibly make multiple pseudo-anonymous accounts on the chain and self-contribute to increase their overall CLR match.
We have included multiple features in the design of Kickflow that disincentivizes and reduces the chances of gaming with the system.
Whitelisting
Only addresses that have been whitelisted can include their contribution in the CLR match of a public good. Non-whitelisted addresses can still contribute, but their contribution is not factored in the match calculation.
In the initial launch version of Kickflow, only entities having a Github or Twitter account that is at least 2 years old can get their Tezos address whitelisted. Since a majority of the population owns either of the accounts, we will naturally have a large contributor base.
Initially whitelisting would be admin-controlled, but we have plans to make whitelisting more decentralized as DID solutions get popular.
Milestones
Including milestones-based funding to disincentivize large-scale collusion on a single project, was one of the most important suggestions we received on our original POC.
Any public good that ends up with a CLR match of greater than 20% of the sponsor pool, must complete a set of milestones (during the payout period) to retrieve the match.
Each milestone achieved needs to be filed as a proposal and must be approved by the DAO governance system.
Flagging and Disputing
When other methods fall short, the wisdom of community takes over. Kickflow members can flag a project (and optionally raise a dispute in the DAO) that appears to have gamed with the system, or has potentially broken a rule.
Disputed projects would be brought to the notice of the core team and other token holders, who can vote over the dispute and decide if the project must be disqualified.
Other Plans
Besides the above mentioned techniques, we are also considering the following:
- Integrating a Sybil score system that assigns a score to an entry based on how likely it is to have resorted to collusion.
- Keeping a returnable security deposit for entry into a round. This would disincentivize those who might create multiple spam grants.
- Use the Pair-wise Bonding formula during CLR match ratio calculation to dampen coordinated Sybil attacks.
More on our Launch
We are currently in our last cycle of development, and preparing our launch strategies with valuable help from TzAPAC, Tezos India & Tezos Foundation. See you soon on Kickflow!
