Soulbound Tokens & ENS

Soulbound Tokens (SBTs)

The Concept: Non-Transferable Reputation

Proposed by Vitalik Buterin, E. Glen Weyl, and Puja Ohlhaver (May 2022)

Core idea:

NFTs today:
- Transferable (can sell/trade)
- Financial value (price in ETH)
- Represent ownership of assets

Soulbound Tokens:
- Non-transferable (cannot sell/trade)
- No financial value (priceless, not worthless)
- Represent achievements, credentials, reputation
- Bound to your "Soul" (identity)

Definition:

Soul = Ethereum address representing person/entity
SBT = Token bound to Soul, cannot be transferred

Properties:
✓ Non-transferable (immutable binding)
✓ Publicly visible (verifiable)
✓ Revocable (by issuer if needed)
✓ Composable (multiple SBTs = richer identity)
✗ Cannot be sold
✗ Cannot be given away

SBT Examples

1. Education credentials:

contract DegreeSBT {
    struct Degree {
        string university;
        string degree;
        string major;
        uint256 graduationYear;
        bool revoked;
    }

    // Soul → Degree
    mapping(address => Degree) public degrees;
    address public immutable university;

    constructor() {
        university = msg.sender;
    }

    // Issue degree (non-transferable)
    function issueDegree(
        address soul,
        string memory degree,
        string memory major,
        uint256 year
    ) external {
        require(msg.sender == university, "Only university");
        require(degrees[soul].graduationYear == 0, "Already has degree");

        degrees[soul] = Degree({
            university: "Example University",
            degree: degree,
            major: major,
            graduationYear: year,
            revoked: false
        });

        emit DegreeIssued(soul, degree, major, year);
    }

    // Revoke degree (in case of fraud)
    function revokeDegree(address soul) external {
        require(msg.sender == university, "Only university");
        degrees[soul].revoked = true;
        emit DegreeRevoked(soul);
    }

    // No transfer function! Token is soulbound
}

// Usage:
MIT issues SBT: Computer Science PhD, 2023
Bound to: 0xAlice...
Anyone can verify: Alice has MIT CS PhD
Alice cannot sell it (no transfer)
Alice cannot give it away (bound to her address)

2. Attendance POAPs (Proof of Attendance Protocol):

Event: ETHDenver 2024
Attendees: 15,000 people

Traditional POAP:
- Transferable NFT
- Problem: Can buy on secondary market
- Doesn't prove YOU attended
- Just proves someone attended and sold to you

Soulbound POAP:
- Non-transferable
- Bound to address that claimed at event
- Proves YOU attended
- Cannot be bought/sold
- Real attendance proof

Applications:
- Reputation in communities
- Access to alumni events
- Proof of participation
- Voting weight (attended X conferences)

3. Credit scores:

contract CreditScoreSBT {
    struct CreditHistory {
        uint256 score;  // 300-850
        uint256 lastUpdated;
        uint256 loansRepaid;
        uint256 loansDefaulted;
        uint256 totalBorrowed;
    }

    mapping(address => CreditHistory) public creditScores;

    // Update score based on loan performance
    function updateScore(
        address soul,
        bool repaid,
        uint256 amount
    ) external onlyLender {
        CreditHistory storage credit = creditScores[soul];

        if (repaid) {
            credit.loansRepaid++;
            credit.score = min(850, credit.score + 10);
        } else {
            credit.loansDefaulted++;
            credit.score = max(300, credit.score - 50);
        }

        credit.totalBorrowed += amount;
        credit.lastUpdated = block.timestamp;
    }

    // Cannot transfer credit score
    // Follows you forever
}

// Benefits:
// - Borrowers build reputation
// - Lenders assess risk
// - Good behavior rewarded
// - Bad behavior penalized
// - Cannot buy fake credit history

4. Work credentials:

Employer: Google
Issues SBT to employee: "Software Engineer, 2020-2024"

Properties:
- Bound to employee's address
- Verifiable by anyone
- Cannot be faked
- Cannot be transferred
- Public or private (encrypted)

Use cases:
- Job applications (prove experience)
- Professional networks (LinkedIn on-chain)
- Access to alumni networks
- Reputation in hiring

SBT Implementation Challenges

1. Account recovery problem:

Traditional NFT:
- Lost private key? → NFT inaccessible
- But: NFT still has value
- Can recover via: Social recovery, multisig, etc.

Soulbound token:
- Lost private key? → Lose entire identity
- All credentials, reputation, history gone
- Recovery is critical!

Proposed solutions:

A. Community recovery:
   Guardian set: Family, friends, trusted people
   Threshold: 3 of 5 guardians can recover
   Process: Submit new address, guardians vote

B. Time-locked recovery:
   Backup address: Set during account creation
   Timelock: 30-day delay before recovery
   Protection: Current owner can cancel if compromised

C. Social recovery:
   Soul = Smart contract wallet (not EOA)
   Guardians: Other souls you trust
   Recovery: Guardians collectively migrate SBTs

2. Privacy concerns:

Problem: All SBTs are public
Everyone can see:
- Your education
- Your employment history
- Your credit score
- Your criminal record (if tokenized)
- Your medical history (if tokenized)

This is a privacy nightmare!

Solutions:

A. Encrypted SBTs:
   Store encrypted data on-chain
   Only owner + authorized parties have decryption key
   ZK proof: "I have a degree" without revealing which

B. Private issuance:
   Issuer signs credential off-chain
   Holder stores locally
   Presents selectively with ZK proof

C. Separate contexts:
   Work soul: Professional credentials
   Personal soul: Private credentials
   Multiple souls for different contexts

3. Coercion and discrimination:

Problem: Cannot hide SBTs

Scenarios:

Job discrimination:
- Employer sees you have SBT from competitor
- Discriminates against you
- Or: Requires certain SBTs as prerequisite

Social discrimination:
- Can see if you attended certain events
- Can see your associations
- Can discriminate based on history

Authoritarian use:
- Government issues "social credit" SBTs
- Low score → Cannot access services
- Cannot escape history
- Permanent reputation system

Solutions:
- Selective disclosure (ZK proofs)
- Private SBTs (encryption)
- Right to be forgotten (revocable SBTs)
- Multiple souls (pseudonymous separation)

But: Fundamentally tension between transparency and privacy

4. Market for fake credentials:

Problem: High value SBTs will be targeted

Attack vectors:

A. Compromised issuers:
   - Hack university/employer
   - Issue fake SBTs
   - Hard to detect until revoked

B. Collusion:
   - Bribe issuer to issue fake SBT
   - Insider threat
   - Revocation may come too late

C. Identity theft:
   - Steal someone's private key
   - Impersonate them
   - Holder claims key was stolen (hard to verify)

D. "Fake" participation:
   - Attend event briefly to get POAP
   - Don't actually participate
   - SBT doesn't reflect reality

Solutions:
- Multi-signature issuance (requires multiple parties)
- Time-based vesting (SBT only valid after time period)
- Continuous verification (periodic re-attestation)
- Revocation registries (transparent blacklisting)
- Reputation for issuers (bad issuers lose credibility)

DeSoc: Decentralized Society Vision

From the SBT paper, a vision for "Decentralized Society" (DeSoc):

1. Uncollateralized lending:

Current DeFi:
Borrow $1,000 → Need $1,500 collateral
Capital inefficient

With SBTs:
Alice has SBTs showing:
- MIT degree
- 5 years at Google
- Credit score 750
- Previous loans repaid
- Community reputation high

Lender algorithm:
risk_score = f(education, employment, credit_history, reputation)
collateral_required = max(0, loan_amount * (1 - risk_score))

Alice borrows $10,000 with only $2,000 collateral (80% LTV)
Or: $10,000 with $0 collateral if risk score high enough

Default consequences:
- Credit score drops
- SBT records default (permanent)
- Future borrowing capacity reduced
- Reputation damaged across ecosystem

Incentive: Don't default (reputation matters more than one-time gain)

2. Sybil-resistant governance:

Current:
1 token = 1 vote
Whales dominate

With SBTs:
Voting weight = f(multiple SBTs)

Examples:

Quadratic voting with SBT check:
- Must have Proof of Humanity SBT to vote
- Each verified human gets equal initial votes
- Can buy more votes, but quadratically expensive
- Result: More democratic than 1-token-1-vote

Reputation-weighted voting:
- Community members with attendance SBTs get bonus
- Contributors with work SBTs get bonus
- Long-term holders get bonus
- New addresses get minimal weight
- Result: Engaged community members have more say

Specialized voting:
- Technical proposals: Weight by "developer" SBTs
- Financial proposals: Weight by "economist" SBTs
- Result: Subject matter experts have more influence

3. Plural property and shared ownership:

Concept: Assets partially owned by communities

Example: DAO house
- House owned by DAO
- Members have varying ownership based on SBTs:
  * Founding member SBT: 10% ownership
  * Active contributor SBT: 5% ownership
  * Attendee SBT: 1% ownership

Benefits:
- Rewards based on actual contribution
- Cannot buy your way in (SBTs non-transferable)
- Meritocratic ownership
- Community-aligned incentives

Usage rights:
- Booking priority by SBT level
- Revenue share proportional to ownership
- Voting power on house decisions

4. Reputation-based marketplaces:

Uber/Airbnb on blockchain with SBTs:

Driver/host has SBTs:
- 500 completed rides (issued by protocol)
- 4.8 star average rating (issued by riders)
- Background check passed (issued by verifier)
- Licensed driver (issued by DMV)

Rider/guest has SBTs:
- 200 completed rides
- 4.9 star average rating
- Verified identity
- No disputes or bans

Matching algorithm:
- High-reputation drivers → High-reputation riders
- Lower-reputation → Must match with lower-reputation
- Incentive: Build reputation for better matches

Cannot game system:
- Cannot buy good reputation (SBTs non-transferable)
- Cannot start fresh (reputation follows you)
- Cannot fake ratings (issued by protocol, verifiable)

ENS: Ethereum Name Service

Human-Readable Addresses

Problem:

Ethereum address: 0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb
- Hard to remember
- Easy to mistype
- Not human-friendly

ENS solution:

ENS name: alice.eth
Resolves to: 0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb

Benefits:
✓ Easy to remember
✓ Easy to type
✓ Human-readable
✓ Can update resolved address
✓ Can add metadata (avatar, bio, social links)

ENS Architecture

Hierarchical naming:

.eth (top-level domain)
  └── alice.eth (domain)
        ├── Address: 0x742d35...
        ├── Avatar: ipfs://Qm...
        ├── Twitter: @alice
        └── Subdomain: pay.alice.eth
              └── Address: 0x123456...

Smart contract structure:

// ENS Registry: Maps names to owners
contract ENSRegistry {
    struct Record {
        address owner;
        address resolver;
        uint64 ttl;
    }

    mapping(bytes32 => Record) records;

    // namehash: Hierarchical hash of name
    function setResolver(bytes32 node, address resolver) external {
        require(msg.sender == records[node].owner);
        records[node].resolver = resolver;
    }
}

// Resolver: Maps names to addresses/metadata
contract PublicResolver {
    mapping(bytes32 => address) addresses;
    mapping(bytes32 => string) texts;

    function setAddr(bytes32 node, address addr) external {
        require(authorised(node));
        addresses[node] = addr;
    }

    function addr(bytes32 node) public view returns (address) {
        return addresses[node];
    }

    function setText(bytes32 node, string key, string value) external {
        require(authorised(node));
        texts[keccak256(abi.encode(node, key))] = value;
    }
}

Name resolution:

// Forward resolution: name → address
async function resolve(name) {
    // 1. Hash name to node
    const node = namehash(name);  // alice.eth → 0xabc123...

    // 2. Query registry for resolver
    const resolver = await registry.resolver(node);

    // 3. Query resolver for address
    const address = await resolver.addr(node);

    return address;  // 0x742d35...
}

// Reverse resolution: address → name
async function reverseResolve(address) {
    // 1. Construct reverse node
    const reverseNode = namehash(address + ".addr.reverse");

    // 2. Query reverse resolver
    const name = await reverseResolver.name(reverseNode);

    return name;  // alice.eth
}

// Usage:
await web3.eth.sendTransaction({
    to: "alice.eth",  // Resolves to 0x742d35...
    value: web3.utils.toWei("1", "ether")
});

ENS as Identity

Rich profiles:

alice.eth resolves to:
{
    "address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb",
    "avatar": "ipfs://QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps",
    "description": "Blockchain developer",
    "email": "[email protected]",
    "url": "https://alice.dev",
    "twitter": "@alice",
    "github": "alice",
    "com.discord": "alice#1234",
    "contenthash": "ipfs://QmPersonalWebsite...",

    // Custom records
    "pubkey": "0x04ab5d8a2f...",  // Encryption public key
    "btc": "bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh",
    "ltc": "ltc1q...",

    // Subdomains
    "subdomains": {
        "pay.alice.eth": "0xPaymentAddress...",
        "blog.alice.eth": "ipfs://QmBlogContent...",
        "dao.alice.eth": "0xDaoAddress..."
    }
}

Use cases:

1. Payments:
   Send ETH to "alice.eth" instead of 0x742d35...
   Recipient-friendly

2. Login/Authentication:
   "Sign in with Ethereum"
   User signs message with alice.eth
   Website verifies signature against alice.eth's address

3. Decentralized websites:
   alice.eth → IPFS contenthash
   Browser resolves ENS name
   Loads website from IPFS
   Censorship-resistant

4. Cross-chain:
   alice.eth can resolve to:
   - Ethereum: 0x742d35...
   - Bitcoin: bc1qxy2kgd...
   - Solana: 7Np41oeYqPefeNQEHSv1UDhY...
   Single name, multi-chain identity

5. Social graph:
   Follow "alice.eth" across platforms
   Portable identity (not platform-locked)
   Own your social graph

ENS Adoption

Statistics (2024):
- Names registered: 2M+
- Active names: 600k+
- Integrations: 500+ services
- Revenue: $100M+ (lifetime)
- Secondary market: $100M+ volume

Pricing:
- 5+ characters: $5/year
- 4 characters: $160/year
- 3 characters: $640/year

Top sales:
- paradigm.eth: $1.5M (2022)
- 000.eth: $300k (2022)
- nike.eth: $110k (2022)