Redefining Airdrop Eligibility

Let's start by distinguishing airdrop farmers from Sybil attackers. Airdrop farmers play a vital role in driving blockchain adoption and fostering engaged communities. They consistently bring volume and activity to projects through their dedicated participation. Every ecosystem needs this core user base to thrive. Airdrop farmers diligently complete tasks, navigate complex platforms, and actively engage across project channels day after day. Without their efforts, how many casual users would realistically go through lengthy multi-step processes? The truth is, airdrop farmers are essential for generating that initial traction and momentum. They're the early adopters willing to put in the work - whether that's greeting the community daily or tackling arduous tasks for potential rewards. While their motivations may seem incentive-driven, we can't disregard the immense value they provide as a catalyst for growth.

In contrast, Sybil attackers pose a significant threat that projects must address. These are individuals managing hundreds of wallets solely to claim airdrops across multiple addresses. Their participation is usually minimal, only meeting basic requirements since operating at scale is costly.While projects may overlook them initially, Sybil attackers become a major problem during airdrop distribution for two key reasons:

Fairness Concerns: They siphon off a large portion of tokens intended for genuine users, making the community feel like they're competing against bots.

Security Risks: A coordinated influx of useless transactions from Sybil wallets could potentially overwhelm the product.

So how have projects attempted to tackle this challenge?

On-Chain Data Analysis

• Enforcing minimum balance requirements on snapshot dates

• Monitoring transaction activity patterns

• Cross-referencing with other airdrops

• Detecting address clusters with similar behaviors

• Flagging users conducting low-value transactions across chains

Pointing Systems

• Focusing on users' volume/time ratio to assign points

• Ensuring it doesn't matter if $100 is in one wallet or split across ten

Self-Reporting (New)

• Asking Sybil attackers to self-report for a percentage of eligibility

On-Chain Data

The issue is that sophisticated attackers can fake on-chain data, continually finding ways to bypass detection. Additionally, overly restrictive filters risk excluding legitimate users, disappointing the project's community (as seen in many recent cases).

Pointing Systems

While well-intentioned, these systems can inadvertently disadvantage users with less liquidity, unless tiering is implemented. However, recent airdrops have shown that even tiered pointing systems can still benefit Sybil attackers to some degree.

Self-Reporting

Even if Sybil attackers are required to submit reports, the harsh reality is that they likely still reap benefits from their nefarious behavior - managing hundreds of wallets to siphon off a portion of airdropped tokens for themselves.

Ultimately, a project's goal for an airdrop is twofold:

1. Ensure real, engaged users (airdrop farmers) receive tokens

2. Prevent Sybil attackers from obtaining any tokens

Perhaps a different approach is needed. Instead of stringent eligibility filters upfront, projects could cast a wider net initially, but require users to prove their 'level of uniqueness' to claim tokens. By 'levels of uniqueness,' what is meant is 'the confidence level in the uniqueness.'

Here are the current dominating ways in web3 space: 

1. Onchain Reputation: Analyzing a user's on-chain activity, transactions, and interactions to gauge their level of engagement.

2. Soft-proofs Aggregation: Verifying ownership of social accounts, email addresses, or other off-chain identities to corroborate a user's uniqueness.

3. Identity Economic Value: Evaluating a user's economic footprint and value across various platforms and services.

4. Social Graph and P2P Vouching: Leveraging a user's social connections and peer vouching to establish their uniqueness within a network.

5. Biometrics: Utilizing biometric data, such as fingerprints or facial recognition, to verify a user's physical identity.*

6. Document Identification: Verifying government-issued documents, such as passports or national IDs, to confirm a user's legal identity.*

7. Biometrics + Document Identification + Liveness Check (No 5 & 6): Combining biometric data and Document Identification with a liveness check to ensure the user is physically present and not using pre-recorded or synthetic data. This is considered the most secure approach currently available.

*It's important to note that while methods 5 and 6 can be compromised by black markets for identities, method 7 is considered the most secure approach currently available.

These can be categorized into different levels of assurance , for example we could use Identity Assurance Level from NIST confidence levels. 

• IAL1 (Low Confidence): Methods 1-3 provide a low level of confidence in uniqueness.

• IAL2 (Moderate Confidence): Methods 4-6 offer a moderate level of confidence.

• IAL3 (High Confidence): Method 7, combining biometrics & Document Identification with a liveness check, provides the highest level of confidence in uniqueness.

Once the token allocation is complete, projects can set up a claiming page where users are required to demonstrate their level of uniqueness. The higher their level of confidence, the greater percentage of tokens they can claim. For instance, a project might distribute tokens as follows:

• 20% of tokens to users verified at Identity Assurance Level 1 (IAL1)

• 50% to users at IAL2

• 100% to users at IAL3

This method offers several advantages:

Flexibility in Eligibility: Projects can avoid imposing strict eligibility criteria right from the start, which can frustrate users.

Multiple Verification Avenues: Genuine users have various ways to prove their uniqueness, accommodating diverse user needs and contexts.

Enhanced Security Against Sybil Attacks: It becomes more challenging for Sybil attackers to manipulate the system across numerous wallets.

Allocation Choices for Users: Users with multiple wallets have the flexibility to decide how they want to distribute their token claims, such as opting for 20% across five wallets or 100% in one.

Incorporation of Additional Requirements: The levels can include geographic, compliance, and other specific requirements, making the system adaptable to various regulatory environments.

The primary challenge in this process is maintaining the privacy of the users. Ensuring that personal data is protected while verifying uniqueness is crucial to user trust and regulatory compliance.

This "Levels of Uniqueness" framework aims to strike a balance - embracing a wide initial user base while instituting robust deterrents against Sybil attacks and ensuring engaged users are properly rewarded.There are many tools out there that can help you build this leveling system for your airdrop. 

When it comes to the privacy side of it, many solutions share some information about the user (such as the wallet address, the Decentralised Identifier (DID), etc.) that could be used to track the user’s activity across applications or through on-chain activity. 

To avoid this, Polygon ID allows the user to interact with each application using a different context-based unique identifier (CBUID). There are of course other solutions, such as universal identifiers created based on your biometrics, however they are the perfect recipe for dystopia:

And you might wonder, how does this CBUI work? 

When the user interacts with the application, this application will share a context token (a random number), that used in combination with a unique identifier contained in the user’s verifiable credential (i.e. a passport number) will allow the wallet to generate another unique identifier (derived cryptographically from the original one + the context token) that is the CBUI. 

In that manner, under the same session (for instance proving the uniqueness for a specific Airdrop), the same user will always generate the same CBUI. An example would be a web selling tickets to multiple concerts that wants to sell 1 ticket per person. Each concert would have a different context-token, so each user would have a CBUI per concert. This works well as soon as the application behaves and it is not using the same context for different purposes, which would be equivalent to creating a universal identifier for the specific application.

And most importantly, this CBUI will be different from the one generated by the same user with another application, assuming that applications behave and are not agreeing on the context token shared with the users.

At PolygonID, we're working with different projects to play our part in implementing such leveling systems, enabling applications to detect sybil attacks while preserving their user’s privacy If you have a project planning a token drop, feel free to reach out, and we can discuss this further.

I would like to express my sincere gratitude to Silvia Aran and Sebastian Rodriguez Cabrera for their insightful feedback and valuable contributions.