Eric Zhang
It’s time to review BSC Quadratic Funding Grant Round-1. Two weeks ago I reviewed a quadratic funding grant at DoraHacks hackathon, details here.
On Jan 20 2021 Binance Smart Chain launched its first quadratic funding grant on HackerLink, DoraHacks’ blockchain developer platform. It was the first quadratic funding grant deployed to BSC main net, it is also — I guess — one of the first attempts for an on-chain quadratic funding grant.
Before we start, here is a diagram that explains how an on-chain quadratic funding grant works:
The quadratic funding grant lasted from Jan 20th 2021 to Mar 15th 2021. During the time, DoraHacks promoted the event and invited cool developers and dev teams to present at DoraHacks’ Bilibili live streaming channel (https://space.bilibili.com/445312136/). Team from many countries participated and demonstrated their development, product and progresses at DoraHacks, the event was well-received.
There were 108 projects submitted BUIDLs to HackerLink for the BSC grant, 92 registered on-chain (since the grant is running on a smart contract, projects have to be in a registry in order to receive votes and funding).
The projects covered a wide scope of the current development of the blockchain space — Defi, decentralized insurance, NFT games, BSC infrastructures, DAO, zk rollup, decentralized social networks, decentralized content platforms, etc.
We made a lot of friends and had a lot of fun during the event. Binance Smart Chain foundation helped a lot (and we decided to host more grants and hackathons this year together).
Now I want to share some of our experiences. In my previous post, I have discussed topics like Sybil attack, collusion, voter motivation, and voting behaviors. And here I would like to further discuss these topics.
1. Mechanisms to Further Prevent Sybil Attack
We talked about how large-scale community participation and fees can depress Sybil attack in the previous article. However, fees cannot stop Sybil attack. People can make their calculations on how many tokens they can use to attack and obtain the maximum return.
So is there a way to prevent Sybil attack for on-chain quadratic voting? I don’t think so (just as it’s also impossible in a centralized setting). However, we can implement some mechanisms in our future rounds to further improve the situation.
Let’s discuss four methods.
1) Increase Sybil attack cost with staking requirements
In a nutshell, the real on-chain ID is your asset. We can create a smart contract and ask voters to stake a certain amount of BNBs into the smart contract by a certain time and be eligible to vote. After the round ends, the smart contract releases BNBs and users can claim them back.
For example, if we require each account to stake 10 BNBs to be eligible to vote if someone wants to create 10 voting addresses, 100 BNBs need to be staked. This naturally prevents Sybil attack of some extent.
However, staking requirements increase the entry barrier. If someone does not have 10 BNBs, the mechanism stops the person from voting at all.
Another problem, obviously, is that people can still borrow tokens to stake in order to have more addresses to vote.
2) Use centralized IDs
The easiest way to solve this problem is probably to introduce some centralized control. For example, the GitCoin grants require users to login with GitHub, and GitHub provides an identity for voters.
One of the differences between HackerLink and GitCoin is that HackerLink Grant is running on a smart contract, instead of a multi-sig wallet. Therefore even if we require user login from frontend, savvy players can still Sybil attack by directly interacting with the smart contract.
3) Use a whitelist to register voters
Whitelisting is probably the most reliable method for on-chain voting. If voters get whitelisted before the voting period, Sybil attack is automatically blocked.
The downside of this solution is that voters have to register themselves even before they see the projects. From the operation’s perspective, it will largely reduce the number of people who participate in donations and voting.
4) Progressive Tax
Another idea of depressing Sybil attack is to use progressive tax (fee) system. More community donations will cause higher taxes (fee). For example, if community donation is greater than 200 BNBs for a single project, a 40% fee will apply, then the cost of Sybil attack will increase dramatically. The problem of this method is again — depressing votes when a donation is above a certain level. If we can estimate the max community donation of any project, we can design a reasonable progressive tax system.
Given that quadratic funding is normally put into an open environment, it’s pretty hard to estimate max donations from the community in the first place.
2. Grace Period
Because of the intensive competitions between projects during the final days, we added a more restrictive grace period to future rounds. During the grace period, we will do two things:
A. Verify project identity
B. Conduct analysis of voting records within the round and detect Sybil attack
The grace period allows us to identify scammers and projects conducting Sybil attacks. Once we find them, we can remove them from the registry, and cancel their rights to receive the matching funds. In the case of scammers, we have to return community donations back to users.
In practice, we added identity verification to only display verified projects on HackerLink’s frontend.
3. Will Airdrop enhance the system or undermine the system?
Projects that promise airdrop to their donors are more successful in quadratic funding grants. We have seen this phenomenon at DoraHacks’ quadratic funding grant at ETH Hackathon Beijing, BSC Grant Round-1 on HackerLink, and GitCoin grants.
Promising airdrops will definitely help projects raise more community donations as long as they keep their promises. However, it actually conflicts with the rule of quadratic funding. If an airdrop is legitimized, then a quadratic funding grant will become a competition of airdrop campaigns, therefore totally violating the merit of community selecting projects they want to support from heart.
There were some interesting discussions at the GitCoin GR9 Finale event, people were actually talking about whether airdrop could bring a token model for platforms hosting quadratic funding grants.
The problem is — if airdropping is freely permitted, then quadratic funding becomes something else, maybe it’s just more direct to build an airdrop donation platform.
Another proposal is to have projects choose between airdrop without taking matching funds and no airdrop with access to the matching fund. This might be a reasonable proposal, even though in practice it might be hard to prevent projects to secretly promise airdrop because eventually, it’s hard to trace.
On the other hand, we can completely block airdrop by implementing MACI in quadratic funding, because all voting messages will be encrypted with an operator’s public key and no further information will be revealed by the operator except a ZKP after the round. But people might think about it — is this what we want?
Acknowledgments
We are inspired by Vitalik’s paper “Quadratic Payments”, and we appreciate all practices of quadratic voting and funding like GitCoin Grants, clr.fund, and so on.
