The aim of this post is to explain how passport scoring-as-a-service enables Gitcoin Passport to act as an important Sybil defense Lego in the Gitcoin grants protocol
Gitcoin is migrating from being a centralized grant-giver to being a decentralized grants protocol. To do this, developers are creating building block, or “Lego”, tools that can be used by individual round owners to implement their own Sybil defense strategy. One of the most well-known Lego’s is Gitcoin Passport.
Gitcoin Passport is a tool that allows users to collect stamps that provide evidence that the holder is a real person. These stamps might prove that a user has engaged in certain hard-to-fake web2 or web3 activities in the past such as having a Twitter account with a certain amount of followers, a Google account or a BrightID or Proof-of-personhood persona. Collections of stamps act as evidence of personhood such that a trustable passport is difficult to create quickly or cheaply enough to be used by a Sybil attacker. Specific subcommunities can also define their own set of stamps - perhaps certain POAPs or NFTs that demonstrate that a user was present at some event or contributed to some project. Combinations of stamps can be used to quantify the extent to which a user should be trusted.
Scoring
Some kind of analysis pipeline is required to translate stamp ownership into trustability. Representing a stamp collection in the form of a trust score enhances the privacy preserving qualities of Gitcoin Passport by only exposing to apps the user’s score, not the stamps from which the score was derived (which could in some cases otherwise be used to “fingerprint” an individual). Personal identifying information such as doxxable connections to social media are already omitted from the Gitcoin Passport as the stamp is generated after a one-time exposure of, for example, a Twitter account. Only the stamp is preserved, indicating that the user demonstrated ownership of the account, but no information about which specific account they own.
Apps are therefore required to make decisions about the trustability of a user from analyzing stamps alone. A minimal scoring example might be to simply count the stamps - more stamps = more trust. However, different stamps can offer stromger or weaker evidence of personhood. A simple stamp-count overlooks this and assumes equality among stamps. A Sybil attacker could easily use this oversight to create passports full of “cheap” stamps to game the stamp-count algorithm. Alternatively, perhaps strongly favouring very expensive NFTs or exclusive memberships, or putting high thresholds on metrics such as follower count for social media accounts could effectively deter Sybil attackers. However, this prices out many honest users as well as Sybils and also excludes honest newbies who have not had time to build up much of an online track record.
This tension between eliminating Sybils while being as inclusive as possible to a diverse userbase neccessitates a more sophisticated approach to Sybil scoring.
Trust Bonus
Gitcoin Passport exposes an API for scoring passports that has its roots in the Gitcoin Fraud Detection and Defense (FDD) trust bonus algorithm. The data fed into the algorithm are the stamps in a user’s passport. The scoring algorithm is effectively a weighted sum of the stamps normalized to range between 0 and 1. The grants protocol can then interpret this score as a trust metric and set a threshold value that users must exceed in order to participate in a grant round. Alternatively, the score can be used to amplify or dampen a user’s influence in the round rather than imposing a binary in/out condition.
The challenge for developers is to determine the optimal weigths assigned to each specific stamp. This is an area of synergy between Gitcoin Passport and FDD. Since FDD is concerned with identifying diagnostic signals for Sybils by analyzing Gitcoin data, they are well positioned to examine the complex relationships between stamp combinations, honest users and Sybils. One aspect of this is identifying how strong a signal can be extracted from certain stamps, and another is suggesting alternative stamps that have particularly high signal. Given a set of possible stamps, FDD can determine the relative importance of each as predictors of Sybil accounts, and define the weighting that the stamps are assigned in the trust score calculation.
Gitcoin Passport can then incorporate these weightings into their trust score algorithm and provide the scoring as a service - abstracting the data scraping, processing, analysis and interpretation away from the end-user.
Customization
The above approach is a very convenient way for round manager to determine, algorithmically, how much to trust individual users without exposing their personally identifying data. However, for some use-cases the standard set of stamps might not be sufficient. For example, a specific grant round might focus on participation in certain subcommunities, or feel that a certain bootcamp POAP is very important, or perhaps certain rounds might be better tuned to eliminate more Sybil’s at the cost of excluding more false-positives (e.g. a DeFi round) or tuned to be inclusive at the cost of missing more Sybils (e.g. an environmental or social cause that attracts more new users).
In these cases, the default weighting algorithm provided by Gitcoin’s FDD analysis might not be optimal. Therefore, the scoring service must be customizable. Customization can happen in the scoring service itself, by overriding the FDD-suggested weights. Development of a second layer of app that modifies the weights in the scorintg service is already a roadmap item for Gitcoin Passport. Users that override the weights would still be able to use the service as normal, but with an intermediate stage of weight-adjustment. Later, multiple scoring algorithms could be developed so that the service can satisfy as many use-cases as possible. Each time a user itnegrates the scoring service, a new instance of the scorer is created, meaning that many scorers with different configurations can exist simultaneously, serving different communities.
For users that to define their own scoring algorith, Gitcoin Passport offers a Software Development Kit that includes functions for reading and writing to and from streams in Ceramic (where Gitcoin Passport data lives), verifying and scoring Passport stamps. This gives complete freedom to developers to implement any algorithm they wish calculate their trust scores. However, they also have to deal with the data cleaning and validation steps that are taken care of as part of the scoring service. This includes de-duplication, where the service checks for users submitting the same stamps multiple times.
Scoring as a Service
The usefulness of the scoring process depends upon how intuitive it is to implement for the end users that need to implement it. A straightforward example is a round manager in the new Gitcoin grants protocol that wishes to use the trust score of each user to determine their influence in the round. They have the option to implement something bespoke for themselves by developing using the Gitcoin Passport SDK or to build using the standard scoring model. The latter option is set up as a service in order to be as simple to implement as possible. To use the scoring service, each user is required to sign a message proving ownership of an Ethereum address. For each proven address, the service grabs the passport data associated with the addresses from Ceramic and applies the FDD scoring algorithm, returning a trust score for each address. This is all handled “under-the-hood” so the user never has to interact with Ceramic or handle any stamp verification or validation - this is all handled by the scoring service.
Outlook/summary
The scoring algorithm is a critical part of what makes Gitcoin Passport so useful - it takes the evidence presented in the form of stamps and presents it as a number that conveys the trustability of the passport holder. This means it can be used as a Lego in a project’s Sybil defense strategy. Providing scoring as a service ensures the scoring Lego is easy to use and widely accessible, while also being customizable to different use cases.
- thanks for kicking off this convo & for the rec