Identity Applications & Real-World Use Cases

Gitcoin Passport: Identity Scoring

The Sybil Problem in Quadratic Funding

Quadratic funding recap:

Matching formula:
Match = (√d₁ + √d₂ + √d₃ + ...)²

Example:
Project A: 1 donor gives $10,000
Match = (√10,000)² = 10,000

Project B: 100 donors give $100 each
Match = (√100 + √100 + ... 100 times)²
      = (10 × 100)²
      = 1,000,000

Project B gets 100x more matching!

Why? Quadratic funding favors:
- Many small donors (grassroots)
- Over few large donors (whales)
- Democratic signal

Sybil attack:

Attacker: Create 100 fake identities
Each: Donate $100 to their own project
Cost: $10,000 total
Matching: $1,000,000 (from example above)
Profit: $990,000

Problem: Quadratic funding is VERY vulnerable to Sybils
Solution: Need to verify donors are unique humans

Gitcoin Passport Design

Concept: Aggregate identity signals into a trust score

Architecture:

User connects multiple accounts:
├── GitHub (age, activity, repos)
├── Twitter (age, followers, tweets)
├── Google (Gmail account age)
├── Facebook
├── LinkedIn
├── ENS (name ownership)
├── Proof of Humanity
├── BrightID
├── Worldcoin
└── On-chain activity (transactions, contracts)

Each connection = "Stamp"
Each stamp = Points
Total score = Sum of points
Threshold = Minimum to be "human"

Stamp values (example):

Verification Method                Points    Cost to Fake
─────────────────────────────────────────────────────────────
Proof of Humanity                  15        $300 + time
Worldcoin                          15        In-person scan
BrightID                           10        Social graph
ENS (1+ year old)                  5         $5 + time
GitHub (2+ years, 10+ repos)       8         Hard to fake
Twitter (500+ followers, 2+ yrs)   6         Hard to fake
Google (5+ years)                  5         Hard to fake
On-chain: 10+ transactions         3         Low cost
On-chain: Interacted with 5+ apps  5         Medium cost
NFT ownership (non-spam)           3         Can buy
Balance > 0.1 ETH                  2         Can buy

Threshold for "human": 20+ points

Score calculation:

class GitcoinPassport {
    async calculateScore(address) {
        let score = 0;
        const stamps = await this.getStamps(address);

        // GitHub verification
        if (stamps.github) {
            const age = stamps.github.accountAge;
            const repos = stamps.github.publicRepos;
            const stars = stamps.github.totalStars;

            if (age > 2 && repos > 10) score += 8;
            else if (age > 1 && repos > 5) score += 5;
            else if (age > 0) score += 2;

            if (stars > 100) score += 3;
        }

        // Twitter verification
        if (stamps.twitter) {
            const age = stamps.twitter.accountAge;
            const followers = stamps.twitter.followers;

            if (age > 2 && followers > 500) score += 6;
            else if (age > 1 && followers > 100) score += 3;
        }

        // Proof of Humanity
        if (stamps.proofOfHumanity && stamps.proofOfHumanity.verified) {
            score += 15;
        }

        // On-chain activity
        const txCount = await this.getTransactionCount(address);
        if (txCount > 100) score += 5;
        else if (txCount > 10) score += 3;

        const uniqueContracts = await this.getUniqueContractInteractions(address);
        if (uniqueContracts > 10) score += 5;

        return score;
    }

    isHuman(score) {
        return score >= 20;  // Threshold
    }
}

Privacy-preserving:

Stamp verification happens off-chain (in user's browser)
User receives signed credential: "Score = 25"
User presents credential to Gitcoin (without raw data)
Gitcoin verifies signature, accepts if score >= threshold

Gitcoin sees:
✓ User has score of 25
✗ Which stamps contributed
✗ GitHub username
✗ Twitter handle
✗ Other PII

Privacy preserved while proving humanness

Gitcoin Grants Results

Before Passport (2019-2021):

Total matching pool: $10M
Sybil attacks detected: 30-40% of donors
Funds lost to Sybils: $3-4M
Method: Manual review (slow, expensive)

After Passport (2022-2024):

Threshold: 20+ score required
Sybil attacks detected: 5-10% of donors
Funds lost to Sybils: $0.5-1M
Improvement: 75% reduction in Sybil attacks

Statistics:
- Passports created: 1M+
- Unique humans: 300k+ (20+ score)
- Stamps collected: 5M+
- Grants funded: 10,000+
- Matching distributed: $50M+

Effectiveness:

Cost to create Sybil with 20+ score:
- Need: PoH ($300) OR multiple aged accounts
- If buying aged accounts:
  * GitHub (2yr, 10 repos): $50-100 (hard to buy)
  * Twitter (2yr, 500 followers): $100-200
  * Google (5yr): $50
  * Total: $200-300 per Sybil

To steal $10k from matching pool:
- Need ~50 Sybil identities (empirically)
- Cost: 50 × $250 = $12,500
- Unprofitable!

Result: Sybil attacks economically deterred

Limitations:

1. Centralization:
   - Gitcoin controls stamp definitions
   - Could censor certain stamps
   - Trust in Gitcoin infrastructure

2. Privacy concerns:
   - OAuth connections reveal identity
   - Gitcoin sees connected accounts
   - Trade-off: Privacy vs Sybil resistance

3. False positives:
   - Real humans without aged accounts
   - People in developing countries (no GitHub/Twitter)
   - Excludes legitimate users

4. Credential market:
   - Can buy aged social media accounts
   - Can buy ENS names
   - Arms race: Detection vs evasion

5. Dynamic thresholds:
   - Stamp values must update (attackers adapt)
   - Requires ongoing governance
   - No permanent solution

IPFS and Content Addressing

The Problem with URLs

Location addressing (URLs):

https://example.com/profile.jpg

Problems:
1. Central point of failure (example.com down = content gone)
2. Mutable (content at URL can change)
3. Not portable (tied to specific domain)
4. Censorable (domain can be seized)
5. Not verifiable (can't prove content authentic)

Example failure:

Alice creates DID with profile picture:
{
  "id": "did:ethr:0xAlice",
  "image": "https://myserver.com/alice-profile.jpg"
}

Problems:
- myserver.com goes down → Image lost
- Server compromised → Image replaced
- DNS hijacked → Different image shown
- Domain expires → Image gone forever

Alice's identity broken because centralized hosting

Content Addressing with IPFS

IPFS (InterPlanetary File System): Content-addressed storage

How it works:

Traditional (location-based):
URL: https://example.com/file.jpg
Request: Go to example.com, fetch /file.jpg
Result: Whatever is at that location now

IPFS (content-based):
CID: QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps
Request: Fetch content with this hash from anyone who has it
Result: Always the same content (hash verified)

Content Identifier (CID):

CID: QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps
      ↑
      Hash of content (SHA-256)

Properties:
- Derived from content itself
- Same content = Same CID
- Different content = Different CID
- Cannot change content without changing CID
- Self-verifying (hash proves authenticity)

Example:

// Upload file to IPFS
const { create } = require('ipfs-http-client');
const ipfs = create({ url: 'https://ipfs.infura.io:5001' });

const file = {
    path: 'alice-profile.jpg',
    content: fs.readFileSync('alice-profile.jpg')
};

const result = await ipfs.add(file);
console.log(result.cid.toString());
// Output: QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps

// Now anyone can fetch it:
const url = `https://ipfs.io/ipfs/${result.cid}`;
// Or: ipfs://QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps

Benefits for identity:

DID Document with IPFS:
{
  "id": "did:ethr:0xAlice",
  "image": "ipfs://QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps",
  "description": "ipfs://QmBioHash..."
}

Advantages:
✓ Permanent (as long as someone pins it)
✓ Immutable (CID guarantees content)
✓ Decentralized (fetch from any node)
✓ Verifiable (hash proves authenticity)
✓ Censorship-resistant (no single point of control)

Quadratic Funding with Identity

How Quadratic Funding Works

Formula:

For project i with donations d₁, d₂, ..., dₙ:

Matching amount = (√d₁ + √d₂ + ... + √dₙ)² - Σdᵢ

Example:
Project receives donations: $1, $1, $1, $1, $1 (5 donors)

Matching = (√1 + √1 + √1 + √1 + √1)²- 5
         = (1 + 1 + 1 + 1 + 1)² - 5
         = 25 - 5
         = $20 matching

Compare to:
1 donor gives $5: Matching = (√5)² - 5 = 5 - 5 = $0

Result: Many small donors >> Few large donors

Mathematical properties:

1. Favors breadth over depth:
   100 people × $1 = $10,000 matching
   1 person × $100 = $100 matching

2. Diminishing returns:
   First $1 from new donor: High matching
   Additional $1 from same donor: Low matching

3. Quadratic scaling:
   2x more donors → 4x more matching
   10x more donors → 100x more matching

Identity-Gated Quadratic Funding

With Gitcoin Passport:

contract QuadraticFunding {
    IGitcoinPassport public passport;
    uint256 public constant MIN_SCORE = 20;

    struct Project {
        address payable recipient;
        uint256 totalDonations;
        uint256 matching;
    }

    mapping(uint256 => Project) public projects;
    mapping(uint256 => mapping(address => uint256)) public donations;
    mapping(address => bool) public hasVoted;

    function donate(uint256 projectId, uint256 amount) external payable {
        require(msg.value == amount, "Incorrect value");

        // Check donor is verified human
        uint256 score = passport.getScore(msg.sender);
        require(score >= MIN_SCORE, "Insufficient identity score");

        // Record donation
        donations[projectId][msg.sender] += amount;
        projects[projectId].totalDonations += amount;

        // Transfer funds to project
        projects[projectId].recipient.transfer(amount);
    }

    function calculateMatching(uint256 projectId, uint256 matchingPool)
        external
        view
        returns (uint256)
    {
        // Get all unique donors
        address[] memory donors = _getDonors(projectId);

        // Calculate sum of square roots
        uint256 sumSqrt = 0;
        for (uint i = 0; i < donors.length; i++) {
            uint256 donation = donations[projectId][donors[i]];
            sumSqrt += sqrt(donation);
        }

        // Quadratic formula
        uint256 matching = (sumSqrt ** 2) - projects[projectId].totalDonations;

        return matching;
    }
}

Results with identity gating:

Gitcoin Grants Round 15 (2022) with Passport:

Before Passport:
- Total donors: 10,000
- Suspected Sybils: 3,000 (30%)
- Manual review time: 200 hours
- Matching lost to Sybils: ~$300k

With Passport (20+ score required):
- Total donors: 7,500
- Suspected Sybils: 500 (6.7%)
- Manual review time: 50 hours
- Matching lost to Sybils: ~$50k

Improvement:
- 77% reduction in Sybils
- 75% less manual review
- 83% less matching lost
- Higher quality donors

Real-World Applications

Use Case 1: Undercollateralized Lending with DIDs

Goldfinch: Real-world credit with on-chain identity

Model:
1. Borrower (business) creates DID
2. Submits credentials:
   - Business registration
   - Financial statements
   - Credit history
   - KYC documents (encrypted)
3. Underwriters (also with DIDs) review
4. Underwriters stake capital on assessment
5. Loan issued based on reputation, not just collateral
6. Borrower repays or defaults
7. Reputation updated (SBT-like)

Example:
Borrower: Small business in Kenya
Collateral: $10k physical assets
Loan needed: $100k (for inventory)

Traditional DeFi: Impossible (need $150k collateral)

With identity:
- Business has 3-year operating history
- Previous loans repaid
- Underwriters verify credentials
- Loan approved at 50% collateral ($50k, not $150k)

Result: Real-world economic activity enabled

Maple Finance: Institutional credit with reputation

Model:
1. Pool delegates (with verified identities) create lending pools
2. Institutional borrowers (with KYC/compliance) apply
3. Delegates assess creditworthiness off-chain
4. Approved borrowers get uncollateralized loans
5. If default: Delegate's reputation destroyed, slashed

Scale:
- Total loans: $1.5B+ issued
- Default rate: <5% (as of 2023)
- Avg loan size: $10-50M
- Collateral: 0-20% (much lower than DeFi norm)

Why it works:
- Real identity (legal recourse)
- Reputation matters (future access)
- Professional underwriters (skin in the game)

Use Case 2: Democratic DAO Governance

Proof of Humanity + 1-person-1-vote:

contract DemocraticDAO {
    IProofOfHumanity public proofOfHumanity;

    struct Proposal {
        string description;
        uint256 votesFor;
        uint256 votesAgainst;
        mapping(address => bool) hasVoted;
    }

    mapping(uint256 => Proposal) public proposals;

    function vote(uint256 proposalId, bool support) external {
        // Verify human
        require(
            proofOfHumanity.isRegistered(msg.sender),
            "Not verified human"
        );

        Proposal storage prop = proposals[proposalId];
        require(!prop.hasVoted[msg.sender], "Already voted");

        // 1 human = 1 vote (not 1 token = 1 vote)
        prop.hasVoted[msg.sender] = true;
        if (support) {
            prop.votesFor += 1;
        } else {
            prop.votesAgainst += 1;
        }
    }
}

// Result:
// Whale with 1M tokens: 1 vote
// Person with 1 token: 1 vote
// True democracy, not plutocracy

Real example: HumanDAO

Mission: Universal Basic Income via crypto
Governance: 1-human-1-vote (via Proof of Humanity)

Results:
- 5,000+ verified members
- Monthly UBI: $10-50 per person
- Proposals voted democratically
- Whales cannot dominate votes

Contrast with typical DAO:
- Top 10 token holders: 60% voting power
- Proposals pass if whales agree
- Small holders' votes meaningless
- Effective plutocracy

Use Case 3: Web3 Social Networks

Lens Protocol with identity:

Model:
1. Users create Lens profile (NFT)
2. Link DID for verification
3. Prove humanness (Gitcoin Passport)
4. Build social graph on-chain
5. Content stored on IPFS/Arweave
6. Own your followers (portable)

Identity benefits:
- Verified accounts (blue checkmark via DID)
- Sybil-resistant (bots detected via Passport)
- Reputation portable (take followers anywhere)
- No platform lock-in (own your data)

Example:
Alice on Lens:
- Profile: 0xAlice.lens
- DID: did:ethr:0xAlice
- Proof of Humanity: Verified
- Passport score: 35
- Followers: 10k (owned by Alice, not platform)
- Content: ipfs://QmContent...

Alice can:
- Move to different Lens app (same followers)
- Prove she's verified human
- Monetize content (direct to wallet)
- No deplatforming risk (censorship-resistant)

Farcaster with identity:

Model:
- Username registered on-chain (ENS-like)
- Messages signed with user's key
- Hosted data on user-controlled server
- Identity portable across apps

Benefits:
- Username cannot be taken (you own it)
- Can prove authenticity of messages
- No platform controls your account
- Switch apps freely

Use Case 4: Reputation-Based Access

Developer credentials:

Scenario: Hiring remote developers

Traditional:
- Resume (can lie)
- Interview (limited signal)
- References (can fake)
- Trial period (expensive)

With on-chain credentials:
- GitHub contributions (SBT)
- Hackathon wins (POAPs)
- Open source commits (verifiable)
- Previous jobs (work history SBTs)
- Peer endorsements (signed)

Example:
Bob's on-chain profile:
SBTs:
- ETHGlobal hackathon winner (2023)
- Core contributor: Uniswap (2022-2024)
- 500+ commits to popular repos
- Peer endorsements: 50 verified developers
- Courses completed: MIT, Stanford (verified)

Employer can verify:
- All credentials instantly
- Cannot fake (cryptographically signed)
- Cannot buy (non-transferable)
- Holistic view of skills

Result: Trust without lengthy process