ODC: Your defense to Sybil

Everything about Legos

7 min readFeb 1, 2023

ODC is OpenData Community, an open-source community founded by Gitcoin. Their mission is to protect web3.

If you don’t know, Gitcoin funds are powered by the vote of each web3 user and facilitate the community's needs by funding those amazing projects important for decentralization. (They also help to promote decentralized Data Infrastructure & Applications for a better future.)

Now coming to the problem they solve. It’s very hard to spot a real user because everything is decentralized. We need the effort of every user “Who really thinks a project is worth funding?” to fund the right projects making an authentic impact. So here things get a little complicated, the internet has the power to generate lakhs of accounts in a second. Diverting the votes to their favored projects. And causing an unfair advantage for a single person having multiple fake identities.

So, what is the solution? This is a very very complicated and resource-intensive problem that cannot be solved fully (Because everything is decentralized, and everyone can have a lot of anonymity to an extent, it’s their right). Therefore, many clever programmers have come up with various solutions addressing different parts of the problem.

Luckily we have a name for these solutions, they are called “Legos”.

Legos are components of the data mesh with consistent input and outputs that can easily duplicate analysis and other repeated functions used to better empower the community's collective decision-making.

And the problem is called “Sybil”. Sybil was a term coined in relation to “Sybil Dorsett”, a woman diagnosed with sixteen different personalities.

A Sybil attack refers to a type of attack in which an attacker creates multiple fake identities, or “Sybils” to gain an unfair advantage within a decentralized network.

Basically, legos are blocks that combine to provide targeted analysis regarding known fraudulent behavioral indicators.

Legos are defense to Sybils.

For Gitcoin grants, it's very important to maintain and protect the integrity of the funding environment on the platform by giving a true democratic preference of the community to the donors. Sybils try to disintegrate the true decision of the community to favor specific people or groups and misuse power to gain funds from donors.

In S15 (1 August 2022 through 31 October 2022), FDD (Fraud Detection & Defense Working group of Gitcoin DAO) prevented fraud and saved capital approx. 785,000 dollars. And this is a very big number.

Contribution graph for Gitcoin Grants 10, displaying the proportion of grants to real users to sybil users. Green nodes represent grants, blue nodes represent real users, and red nodes represent sybil users. Notice that most users are clustered in the center and grants are on the periphery. Identifying relevant features for sybil detection is a fundamental goal of the Anti-Fraud Workstream technical work. More ref: https://medium.com/block-science/evaluating-the-anti-fraud-results-for-gitcoin-round-10-cec9277ce5b2

Gitcoin Passport

One of the major lego. Gitcoin Passport is a tool that allows users to prove they have some credentials that make them more trustable. These credentials can come from Web2 or Web3. Examples from Web2 include having Facebook, Twitter, Github, or Google accounts that meet some basic criteria (number of followers/posts, etc). From Web3, BrightID, ENS and Proof-of-Humanity profiles can be used as stamps. The stamps are generated by the user exposing their Web2/Web3 accounts once, and then a stamp is minted in the user’s Passport, with no personal identifying data saved along the way. The passport only includes the stamps — the proof that evidence exists — and no actual identifying data (working like a zero-knowledge proof). These stamps are used to generate a “trust score”.

We have Passport SDK which can help you to directly implement it in your dApp and protect it from Sybils. Passport API is in development right now. you can find out more here.

Other Legos

Levenstein distance: Every user has a username — when they sign up to Gitcoin grants the similarity of their name can be compared against all other usernames to generate a likelihood of the username being auto-generated — evidence of a Sybil account. This Lego will be deprecated in the grants protocol because usernames will no longer be available — only Ethereum addresses, wallet IDs, and grant/round nonce.
Shared IP: User IP addresses can also be checked to see if they are shared with many other users. Lots of addresses originating from the same IP could be a marker for Sybil attackers.
SAD model: The user also has a Gitcoin account whose history can be analyzed using the SAD model to give another Sybil-likelihood score.
DonorDNA: When a donor connects their wallet their profile of past donations can be analyzed to see whether it is similar to groups of other users, which may be indicative of Sybil rings.
GrantDNA: Each grant has a set of donors that can be represented as a set of binary data. This can be used to compare grants against flagged grants to see if they have similar donor profiles.
Onchain Intersectionality: How many out of a set of on-chain credentials does a user have?
Farmer Boolean: This uses on-chain data to determine whether a user has >X ERC-20 tokens and an average transaction value <Y ETH.
Onchain History Boolean: It checks if the user has engaged in certain web3 activities in a specific timeframe. Activities and timeframe can be customized by the round owner.
Money-Mixer: It checks if a user has interacted with any known money-mixers e.g. Tornado cash.
On-Trend / Off-Trend: It checks if the donation profile of a user is similar to a grant’s target community.
Flagged Activity on Etherscan: It checks if an address is closely associated with addresses flagged as phishing/spam on etherscan.

You can hop on to this https://github.com/Fraud-Detection-and-Defense/Gitcoin-Sybil-LEGOs/tree/main/scripts_process to know more about each lego’s process.

What does it take to be a true Lego?

Tightly scoped: the tool should fulfill one single function without side effects so that it can be deployed in a variety of contexts with reliable outcomes.
Free and open: open source codes that are publicly available, auditable, able to run on normal consumer hardware.
Permissionless: not requiring special credentials or licenses to view, download or deploy, and users have the ability to fork the code at any time.
Accessible: sufficiently well-documented and with intuitive UX to enable a wide community of users
Minimal dependencies: protect the “supply chain” by minimizing the dependencies. Where dependencies are unavoidable, bundle them or make them very easy to access.
Modular: uses common formats and types so that outputs of one Lego can become inputs to another in pipelines — i.e. the legos are designed to be used as building blocks for larger systems with no specific predetermined structure.
Open governance: Decisions about the development of the Lego should not be gated by individuals or centralized groups — instead governance should be open so that users can trust that the code will be developed and maintained with integrity and community participation.

Why does this Matter?

This unlocks

Quadratic funding
Quadratic voting
Gini coefficient measurements
UBI
one-person-one-vote DAOs
Data Collectives
Sybil Resistant Airdrops
& other use cases we haven’t discovered yet!

Risks of Lego

Empowering Sybil attackers by being Open source: Being open source comes with its own cons. It gives an advantage to the attackers by giving insight into how each lego work and making each attack more effective.
Bribery and blackmail: What happens if, instead of bearing the cost of making Sybils conform to some eligibility requirements, an attacker instead spends their capital on bribing a round owner to adjust the requirements in their favor? And similarly, accounts that have combinations of stamps and other credentials that are likely to be classified as non-Sybil (which can be tested by attackers using the open-source tools and some assumptions about the decisions round owners will make regarding their configuration) could be bought and sold on a black market.
Combinations of Legos: It is very powerful to be able to create anything, but it is also difficult to anticipate all the various attack vectors and weaknesses that could inadvertently be introduced when Legos are arranged in certain configurations.
The risk of releasing tools that others could use for nefarious purposes, or in ways that do not match the ethos of the original developers. For example, even if individual Legos do not collect and store personal identifying information, a fork of the same tools might.

Anyways, there are always some risk factors attached but we have to keep those in mind while developing or using them.