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