Gitcoin aims to optimize capital allocation within a grants round (GR), primarily by preventing capital capture by Sybils. There are currently two independent systems in place for this that run in parallel. First, a multiplier ("Trust Score") is assigned to an individual's donation depending on their non-Sybil traits - the more likely they are to be a real human the more their donation is multiplied in the matching pool. This Trust Score is derived from evidence of personhood that a user collects in their Gitcoin Passport (GP). The other way is Sybil Account Detection (SAD) where accounts that are identified as potential Sybils by a human-in-the-loop machine-learning pipeline are "squelched" - i.e. ejected from the GR. As we move towards Grant 2.0 there is a need to optimize these processes and pivot towards a more composable Sybil defense system that can be tuned by individual grant owners to their own community's needs. Differentiating SAD from GP The fundamental difference between SAD and GP is that GP is proactive - it provides a continuous metric for a user in advance of them participating in a grant round and uses that information to define their impact. It takes into account the 'stamps' a user has in their passport, each of which provide evidence that the user is a real human, and increments their weighting in the matching pool proportionally to the weight of evidence in their passport. On the other hand, SAD retrospectively examines an individuals behaviours, generates a probability that they are a Sybil then applies a threhold to convert that probability into a binary Sybil/nonSybil outcome. SAD then retroactively removes Sybils from the round. SAD and GP have been developed in parallel but mostly independently. Having two independently-developed Sybil defense systems operating separately but in parallel hints at a future where any number of systems can run in parallel and the overall trust score is a dot-product of each trust vector. However, at the same time, there are also opportunities for synergistic relationships between anti-Sybil systems. A good first step in identifying such synergies is to compare the outcomes from SAD and GP in the latest GR to see how closely aligned they are. If both SAD and GP approaches to Sybil defense were perfect, they would silence the same accounts, and those accounts would all be Sybils. In reality there is a gap separating these two processes because each one is imperfect in its own unique ways.

Running a node Q&As Q: Individual from private fund - is it a good idea to stake ETH by running a node? DappNode, Avado or solo staking? A: Yes, but keep in mind a difference between running a node and running a validator (given topic of "nodes") DAppNode is an easy way to spin up a node. DAppNode hardware/software can be used to set up an Ethereum node DAppNode is one way to stake Avado is a fork of DAppNode - same deal, rough feature parity Best way to stake is to be a solo staker (deposit ETH to official staking contract and run own hardware) Solo staking = max sovereignty over funds, privacy and control Comes down to personal choice - you trade convenience for control

Sybils Quadratic funding - the mechanism that currently determines the value of Gitcoin grant funding -is inherently vulnerable to Sybil attacks. Sybil attacks are individual humans dividing themselves into multiple "virtual humans" in order to gain additional voting weight. In traditional banking and voting systems, Sybil resistance comes from "KYC" (know-your-customer) which links personal identifying information to some action. In Web3, "KYC" is generaly minimized because it undermines the core ethos of censorship resistance and permissionlessness. This means other methods are required to identify which participants in a grant round are real individual humans, and which are not. Sybil Strategies The goal of Sybil defense is to increase the investment of time and money required for an attacker to convice a grant review system that they are > 1 person to the extent that as rational attacker would not do it. Defenders constantly attempt to push this cost up while minimizing their own expenses, while attackers constantly try to pull the attack cost down. The greater the size of the exploitable pool of funds, the higher cost an attacker will be willing to pay. At the same time, extremely low-cost Sybil attacks are often worthwhile for attackers because even a low success rate can still be profitable if the attack cost is sufficiently low. This means that a robust Sybil defense structure requires systems that identify cheap, simple attacks very effectively and efficiently as well as more complex defenses against sophisticated attacks. Simple Sybils The simplest, cheapest form of Sybil attack is simply to generate a large number of addresses and try to vote with all of them. Ordinarily, these will be sifted out of the grant review system by human reviewers because they usually fail even basic proof-of-personhood checks. However, there is a substantial cost associated with these human reviews. To optimize the Sybil defense mechanism for high efficacy and low cost, detection of these cheap Sybil attacks must be automated using computationally inexpensive algorithms. Levenshtein Distance