🌐 DApp Sovereignty Framework

Comprehensive Analysis: User + Developer = Overall DApp Sovereignty

👥 User Sovereignty

How much control do end-users have over their data?

Ring 1: Physical (40%)
Ring 2: Network (50%)
Ring 3: Protocol (70%)
Ring 4: Platform (85%)
Ring 5: Cryptographic (90%)
User Agency: 40%

👨‍💻 Developer Sovereignty

How much control do YOU have over your DApp infrastructure?

Ring 1: Physical (15%)
Ring 2: Network (10%)
Ring 3: Protocol (70%)
Ring 4: Platform (15%)
Ring 5: Cryptographic (20%)
DApp Agency: 10%

🎯 Overall DApp Sovereignty

MIN(User, Developer) = Combined Sovereignty

Ring 1: Physical (15%)
Ring 2: Network (10%)
Ring 3: Protocol (70%)
Ring 4: Platform (15%)
Ring 5: Cryptographic (20%)
Overall: 10%

Select your implementation choices for each sovereignty layer.
The calculator will show your final user sovereignty score and recommendations.

4 Platform Sovereignty: Storage Identity Model

API Key Model (Lighthouse Default)
All users share YOUR API key. Data uploaded to YOUR account. Users have no independent identity or namespace.
Sovereignty: 20%
Platform Accounts
Users create accounts on your platform. Data tied to platform identity. Export possible but limited portability.
Sovereignty: 50%
UCAN Identity (Storacha)
Users authenticate with their wallet/keypair. Data namespace owned by user. Can access from other UCAN-compatible apps.
Sovereignty: 70%
UCAN + On-Chain Registry
UCAN identity PLUS user deploys their own smart contract to record CIDs. Full ownership proof on-chain. Maximum portability.
Sovereignty: 85%
Direct Filecoin Contracts
Users propose storage deals directly via smart contracts (FRC-0068). No platform intermediary. Maximum sovereignty but high complexity.
Sovereignty: 95%

4 Economic Sovereignty: Payment Model

Free for Users (You Pay)
You subsidize all storage costs. Users pay nothing. Complete economic dependency on your business model.
Sovereignty: 10%
Subscription Through You
Users pay you subscription fees. You pay storage provider. Users depend on your continued service.
Sovereignty: 40%
Direct Payment to Provider (Storacha Subscription)
Users create own account and pay Storacha/provider directly. Economic relationship between user and provider.
Sovereignty: 70%
Perpetual Payment (Lighthouse)
User pays once from wallet for lifetime storage. No recurring payments. Managed by smart contracts.
Sovereignty: 85%
Direct Filecoin Deal Payment
User pays storage providers directly via smart contracts. User negotiates terms and manages deals. Maximum autonomy.
Sovereignty: 95%

4 Infrastructure Sovereignty: Storage Infrastructure & Self-Hosting

Single Provider, Single Jurisdiction
All data stored with one storage provider in one country/jurisdiction. High risk of single point of failure and jurisdictional control.
Sovereignty: 15%
Multiple Providers, Same Jurisdiction
Data distributed across multiple storage providers, but all in same legal jurisdiction. Reduces single provider risk but still vulnerable to jurisdiction-level actions.
Sovereignty: 40%
Multiple Providers, Multiple Jurisdictions
Data distributed across providers in different countries/jurisdictions. Better resilience but still dependent on third-party providers.
Sovereignty: 60%
User-Selectable Providers
Users can choose which storage providers to use from a decentralized network. Users have control over provider selection but still rely on third parties.
Sovereignty: 75%
Self-Hosted IPFS Node
Users run their own IPFS node to pin and serve their data. Full control over infrastructure, but requires technical knowledge and maintenance. Data redundancy depends on other nodes pinning.
Sovereignty: 85%
Self-Hosted IPFS Cluster
Users run their own IPFS Cluster (multiple IPFS nodes) for redundancy and high availability. Maximum infrastructure sovereignty: full control, geographic distribution, no third-party dependency. Users own and operate their complete storage infrastructure.
Sovereignty: 95%

Decentralized Storage Trilemma

You cannot maximize all three: pick two, sacrifice one

Understanding the Trilemma

Imagine you're building a system to store data. You want three things: control, reliability, and ease of use. The harsh truth? You can't have all three at maximum levels.

The Three Dimensions

1. Sovereignty (Control) — How much do you actually control your infrastructure? Can someone else shut you down? Are you dependent on a service that could disappear tomorrow? Maximum sovereignty means you run everything yourself—no intermediaries, no trusted third parties, no single points of failure.

Think: Running your own server vs. using Dropbox. One gives you control, the other gives you convenience.

2. Persistence (Reliability) — Will your data still be there in a year? In ten years? Do you have guarantees, proofs, or just hope? Maximum persistence means cryptographic proofs, economic incentives, redundancy across multiple independent parties—systems designed to survive even if individual components fail.

Think: Filecoin's cryptographic storage proofs vs. asking your friend to keep a backup. One has guarantees, the other has trust.

3. Practicality (Ease of Use) — Can a normal person use this? How much technical knowledge is required? How long does setup take? Maximum practicality means one-click solutions, zero maintenance, works out of the box—the kind of experience people expect from modern apps.

Think: Clicking "Upload to Dropbox" vs. configuring an IPFS node, managing keys, and maintaining infrastructure.

Why You Can't Have It All

Here's the fundamental constraint: These three dimensions are in tension with each other.

Want maximum sovereignty? You need to run your own infrastructure. That means technical complexity, maintenance overhead, and accepting responsibility. Practicality suffers.

Want guaranteed persistence? You need cryptographic proofs, economic incentives, redundancy systems. That means complex protocols, payment infrastructure, and coordination mechanisms. Practicality suffers.

Want maximum practicality? You need abstraction layers, managed services, "it just works" experiences. That means trusting third parties, accepting vendor lock-in, and giving up control. Sovereignty suffers.

The trilemma forces you to choose: Which two matter most? What are you willing to sacrifice?

Real-World Examples

Dropbox (Persistence + Practicality, Sacrifice Sovereignty)

Easy to use? Absolutely. Reliable? Yes, with SLAs and guarantees. But you're trusting a company, subject to their terms of service, vulnerable to censorship, and locked into their platform. Sovereignty: 5%.

Lighthouse (API Key Model) - Persistence + Practicality, Sacrifice Sovereignty

All users share YOUR API key. Data uploaded to YOUR account. Users have no independent identity. Very easy to use, decent persistence through Filecoin, but sovereignty is extremely low. If Lighthouse shuts down, users lose everything. Sovereignty: 20%.

Storacha/Web3.Storage (UCAN) - Persistence + Practicality, Sacrifice Sovereignty

Uses UCAN identity—better than API keys! Users own their namespace. But you're still using their API, their service, their infrastructure. If they shut down, you lose access. The "decentralization" is hidden behind a centralized interface. Sovereignty: 30%.

Direct Lotus API - Persistence + Some Sovereignty, Sacrifice Practicality

More control than services, cryptographic guarantees, but still uses centralized Lotus endpoints. Complex setup, medium sovereignty ceiling. Sovereignty: 40%.

Direct Filecoin Deals (FRC-0068) - Persistence + Sovereignty, Sacrifice Practicality

Users propose storage deals directly via smart contracts. No platform intermediary. Maximum autonomy, cryptographic proofs, but extremely high complexity. Users negotiate terms and manage deals themselves. Sovereignty: 50%, Practicality: 25%.

Self-Hosted IPFS Node (Solo) - Sovereignty + Practicality, Sacrifice Persistence

User runs single IPFS node. Full infrastructure control, reasonable setup complexity. But no redundancy—data persists only while node is running. Single point of failure. Sovereignty: 85%, Persistence: 20%.

In-Browser Helia (IPFS) - Sovereignty + Practicality, Sacrifice Persistence

IPFS runs directly in the browser using Helia JavaScript library. No server setup required—just include the library. High sovereignty as user controls their own IPFS node. But data only persists while browser tab is open, or if content is pinned by other nodes. Very ephemeral. Sovereignty: 80%, Persistence: 15%, Practicality: 85%.

In-Browser Helia + Pinata Pinning - Persistence + Practicality, Sacrifice Sovereignty

Helia runs in browser providing IPFS functionality, combined with Pinata pinning service for persistence. While browser-based IPFS provides some sovereignty, heavy dependence on Pinata's centralized pinning service significantly reduces it. Good persistence through Pinata's infrastructure and easy to use, but sovereignty is compromised. Sovereignty: 45%, Persistence: 75%, Practicality: 80%.

In-Browser Helia + Storacha - Persistence + Practicality, Moderate Sovereignty

Helia in browser with Storacha pinning + automatic Filecoin deals. Better sovereignty than Pinata (uses decentralized Filecoin network for storage), higher persistence through Filecoin's cryptographic storage proofs. Centralized API access point but decentralized storage backend. More honest about using decentralized tech. Sovereignty: 50%, Persistence: 85%, Practicality: 80%.

Self-Hosted IPFS Cluster - Maximum Sovereignty + Some Persistence, Moderate Practicality

User runs multiple IPFS nodes (cluster) for redundancy and high availability. Maximum infrastructure sovereignty with geographic distribution. No third-party dependency. Users own and operate complete storage infrastructure. Still user-responsible but with redundancy. Sovereignty: 95%, Persistence: 60%, Practicality: 45%. This is the maximum practical infrastructure sovereignty.

Self-Hosted IPFS + Filecoin Node - Sovereignty + Persistence, Sacrifice Practicality

You control the infrastructure. You get cryptographic storage proofs. But you need 1TB+ storage, days of syncing, technical expertise, and ongoing maintenance. Most users can't do this. Practicality: 15%.

Mutual IPFS Pinning Network - Sovereignty + Practicality, Sacrifice Persistence

Users run lightweight IPFS nodes, voluntarily pin each other's content. No centralized service. Censorship-resistant. Reasonable setup complexity. But there are no guarantees—data persists only as long as someone pins it. No cryptographic proofs. No economic incentives. Persistence: 40%. This is the honest tradeoff: sovereignty requires responsibility.

The Honesty Principle

Many "decentralized" services lie by omission. They market themselves as decentralized while using centralized APIs. They promise "guaranteed storage" through services you depend on. They create the illusion of sovereignty without the substance.

The trilemma framework forces honesty: If you want true sovereignty, you must accept responsibility. If you want guarantees, you must accept complexity or dependency. If you want convenience, you must accept that someone else has control.

The mutual IPFS pinning network doesn't compromise—it makes the philosophically honest choice: maximize sovereignty and maintain reasonable practicality by explicitly placing persistence responsibility on users themselves.

This is not a bug—it's the honest architecture. Users who want control must accept that they are responsible for keeping their nodes running, that data persists only as long as someone pins it, and that there are no service provider guarantees. In exchange, they get actual sovereignty—not the illusion of it.

Mutual IPFS Pinning Network

High sovereignty, social persistence, moderate setup

Position: Sovereignty + Practicality

Dimension Scores

Sovereignty 90%
User control, censorship resistance
Persistence 40%
Durability guarantees, redundancy
Practicality 60%
Ease of use, setup complexity

Trilemma Constraint Analysis

Total Score: 190 / 300 theoretical max
⚠️ The trilemma constraint: you cannot maximize all three dimensions simultaneously. Optimizing for two means the third must be lower.

Compare Architectures

Build Custom Architecture

Sovereignty 50%
Persistence 50%
Practicality 50%
Total: 150 / 300

📚 Case Study: Browser-Based DApp with Helia

The Setup

A client-side only DApp running entirely in the browser. Using Helia (JavaScript IPFS implementation) means:

  • No installation required: Helia comes bundled in the DApp JavaScript
  • Immediate participation: Users join the IPFS network as soon as they open the webpage
  • High sovereignty: Each user runs their own IPFS node in the browser
  • High practicality: Zero setup complexity for end users

But what about persistence? Data only exists while the browser is open...

Persistence Options for Helia

1. Browser Storage Only

Data in IndexedDB/browser cache. Persists between sessions but lost if cache cleared. Persistence: ~15%

2. User Keeps Browser Open

Helia node runs continuously while tab open. Content pinned and served while active. Persistence: ~25%

3. Mutual Peer Pinning

Other users' browsers pin your content. Survives as long as someone is online pinning it. Persistence: ~40%

4. Service Worker

Background process keeps Helia running even when tab closed. Persistence: ~35% (solo), ~50% (with peer pinning)

5. Dedicated Always-On Node

User also runs Kubo daemon. Browser DApp coordinates with always-on node. Persistence: ~70% (solo), ~85% (with peer pinning)

6. Add Filecoin Layer

Helia for immediate access, Filecoin deals for long-term archival. Persistence: ~90% (but sovereignty drops to ~30%)

The Hybrid Approach: Helia + Pinning Service

For maximum persistence with minimal complexity, adding a pinning service creates a tiered persistence strategy:

Layer 1: Helia (Immediate + Sovereignty)
  • User uploads → Helia adds to IPFS
  • Available instantly via their browser node
  • Other Helia users can fetch peer-to-peer
  • Sovereignty: 80%, Persistence: 15%, Practicality: 85%
Layer 2: Pinning Service (Reliability Backup)
  • Same content automatically backed up to pinning service
  • Guarantees long-term availability
  • Fallback if peer network fails
  • Retrieval strategy: Your Helia → Peer Helia → Pinning Service → Public gateways

Comparison: Helia + Pinata vs Helia + Storacha

Helia + Pinata
  • IPFS Pinning: Pinata servers (centralized)
  • Long-term Storage: Pinata servers (centralized)
  • Centralization: Fully centralized
  • Exit Strategy: Migrate to new pinner
  • Sovereignty: 45%
  • Persistence: 75%
  • Practicality: 80%
  • Cost: ~$20/month for 1TB
Helia + Storacha
  • IPFS Pinning: Storacha servers (centralized API)
  • Long-term Storage: Filecoin network (decentralized)
  • Centralization: Centralized API → Decentralized storage
  • Exit Strategy: Content exists on Filecoin (provable)
  • Sovereignty: 50%
  • Persistence: 85%
  • Practicality: 80%
  • Cost: ~$50-100/month (includes Filecoin deals)
Key Difference

Pinata: Pure IPFS pinning service (centralized storage)

Storacha: IPFS pinning + automatic Filecoin deals (decentralized storage protocol)

The Honest Tradeoff

Helia + Storacha provides a better philosophical fit for sovereignty-conscious applications:

  • ✅ Uses decentralized storage protocol (Filecoin) under the hood
  • ✅ Content cryptographically proven on distributed network
  • ✅ Less vendor lock-in (content exists on Filecoin, not just Storacha)
  • ✅ More honest about using decentralized tech

But still requires Storacha API (centralized chokepoint) and Filecoin deals take hours/days (though IPFS layer is immediate).

The honest architecture: "We maximize sovereignty where possible (p2p layer), accept centralization where necessary (persistence guarantee), transparent about the tradeoff."

Recommendation

Choose Storacha if:

  • You value underlying decentralization (even if access is centralized)
  • You want cryptographic storage proofs
  • You want to honestly say "backed by Filecoin"
  • Long-term archival matters (Filecoin deals = provable persistence)

Choose Pinata if:

  • Cost matters more
  • You're pragmatic about "decentralization theater"
  • Faster/simpler for MVP

Key Insights

→

No perfect solution exists. Every architecture makes explicit tradeoffs.

→

Mutual IPFS pinning (90% sovereignty, 40% persistence, 60% practicality) represents an honest choice: maximize user control by placing persistence responsibility on users themselves.

→

Traditional services sacrifice sovereignty for convenience—but so does direct Lotus API usage (centralized endpoint).

→

True sovereignty requires user responsibility. If you want control, you must maintain your own infrastructure.

The Blockchain Trilemma

Decentralization • Security • Scalability — Choose Two

The Three Dimensions

1. Decentralization — How many independent nodes validate transactions? Is participation permissionless? Can anyone run a node? Maximum decentralization means thousands of independent validators, no single point of control, and censorship resistance.

Think: Bitcoin's 15,000+ nodes vs. a private blockchain with 5 known validators.

2. Security — How resistant is the network to attacks? What's the cost to attack? Are there cryptographic proofs? Maximum security means strong immutability guarantees, high economic security, and resistance to 51% attacks.

Think: Bitcoin's proof-of-work requiring billions in hardware vs. a network secured by a small validator set.

3. Scalability — How many transactions per second? What are the fees? How fast is finality? Maximum scalability means high throughput, low latency, and low transaction costs.

Think: Solana's 65,000 TPS vs. Bitcoin's 7 TPS with high fees during congestion.

Why You Can't Have It All

Here's the fundamental constraint: These three dimensions are in tension with each other.

Want maximum decentralization? You need many independent nodes, permissionless participation, and distributed consensus. That means slower finality, higher coordination overhead, and network-wide validation. Scalability suffers.

Want maximum security? You need cryptographic proofs, economic security, and strong immutability guarantees. That means expensive operations, high redundancy, and conservative protocols. Scalability suffers.

Want maximum scalability? You need high throughput, low latency, and efficient resource usage. That means fewer validators, more centralization, or off-chain solutions that reduce on-chain guarantees. Decentralization or security suffers.

The trilemma forces you to choose: Which two matter most? What are you willing to sacrifice?

Real-World Examples

Bitcoin (Decentralization + Security, Sacrifice Scalability)

Highly decentralized with thousands of nodes. Extremely secure through proof-of-work. But limited to ~7 transactions per second, high fees during congestion, and slow confirmation times. Scalability: 10%.

Ethereum L1 (Decentralization + Security, Sacrifice Scalability)

Decentralized validator set, strong security guarantees. But limited throughput (~15 TPS), high gas costs, and network congestion. Scalability: 25%.

Solana (Scalability + Security, Sacrifice Decentralization)

High throughput (thousands of TPS), low fees, fast finality. Strong cryptographic security. But requires powerful hardware, fewer validators, and concerns about centralization of node operators. Decentralization: 40%, Security: 80%, Scalability: 90%.

Polygon/Arbitrum (Scalability + Decentralization, Sacrifice Security)

High throughput through layer 2 solutions, more decentralized than high-performance L1s. But security depends on the underlying L1 or additional trust assumptions. Security: 60-70%.

Private/Permissioned Blockchains (Scalability + Security, Sacrifice Decentralization)

High throughput, low fees, fast finality. Strong security through known validators. But only a few trusted nodes, permissioned participation, and centralized control. Decentralization: 10%.

Hive (Decentralization + Security, Sacrifice Scalability)

Decentralized social blockchain with good node distribution and censorship resistance. Strong security through delegated proof-of-stake. Moderate transaction throughput suitable for social media use cases. Scalability: 50%.

PI Network (Scalability + Decentralization, Sacrifice Security)

Mobile-first design prioritizing accessibility and user adoption. Good decentralization through mobile mining. Still in development phase, security not yet fully battle-tested. Security: 65%.

Algorand (Decentralization + Security, Moderate Scalability)

Pure Proof-of-Stake with fast finality and strong security guarantees. Good decentralization through random selection of validators. Better scalability than Bitcoin/Ethereum but still prioritizes decentralization and security over maximum throughput. Decentralization: 80%, Security: 85%, Scalability: 50%.

XDC Network (Scalability + Security, Sacrifice Decentralization)

Enterprise-focused blockchain with high transaction throughput and strong security. Hybrid public/private model optimized for business use cases. More centralized validator set compared to public blockchains. Decentralization: 50%, Security: 80%, Scalability: 85%.

Tezos (Decentralization + Security, Sacrifice Scalability)

Self-amending blockchain with on-chain governance. Strong decentralization through liquid proof-of-stake. High security through formal verification and upgradeability. Limited throughput similar to Ethereum L1. Decentralization: 85%, Security: 80%, Scalability: 40%.

The Honesty Principle

Many blockchain projects claim to "solve the trilemma" through innovative consensus mechanisms, sharding, or layer 2 solutions. But these claims often hide tradeoffs behind technical complexity.

The trilemma framework forces honesty: If you want true decentralization, you must accept scalability limits. If you want high throughput, you must accept centralization or reduced security guarantees. If you want maximum security, you must accept slower, more expensive transactions.

Bitcoin doesn't compromise—it makes the philosophically honest choice: maximize decentralization and security by explicitly accepting scalability limitations.

This is not a bug—it's the honest architecture. Users who want censorship resistance and immutability must accept that the network prioritizes these properties over transaction speed and cost. In exchange, they get actual decentralization—not the illusion of it.

Bitcoin

Maximum decentralization and security, limited scalability

Position: Decentralization + Security

Dimension Scores

Decentralization 95%
Independent nodes, censorship resistance
Security 95%
Economic security, immutability
Scalability 20%
Throughput, latency, cost

Trilemma Constraint Analysis

Total Score: 200 / 300 theoretical max
⚠️ The trilemma constraint: you cannot maximize all three dimensions simultaneously. Optimizing for two means the third must be lower.

Compare Blockchain Architectures

Build Custom Blockchain Architecture

Decentralization 50%
Security 50%
Scalability 50%
Total: 150 / 300

Key Insights

→

No perfect solution exists. Every blockchain makes explicit tradeoffs between decentralization, security, and scalability.

→

Bitcoin (95% decentralization, 95% security, 20% scalability) represents an honest choice: maximize censorship resistance and immutability by accepting scalability limitations.

→

High-performance chains sacrifice decentralization for throughput—but so do layer 2 solutions that depend on centralized sequencers.

→

True decentralization requires accepting limits. If you want censorship resistance, you must accept slower, more expensive transactions.

The Personhood Trilemma

Self-Sovereignty • Privacy • Verifiability — Choose Two

The Three Dimensions

1. Self-Sovereignty — Do you control your own identity? Can you create, manage, and revoke your identity without permission? Maximum self-sovereignty means you own your identity credentials, no central authority, portable across platforms.

Think: Self-sovereign identity (SSI) with decentralized identifiers vs. Facebook/Google login where they control your identity.

2. Privacy — Can you interact without revealing your real-world identity? Are your actions linkable? Maximum privacy means pseudonymity, unlinkability, zero-knowledge proofs—you can prove attributes without revealing identity.

Think: Anonymous credentials vs. KYC/AML requirements that tie everything to your legal identity.

3. Verifiability — Can others verify your claims? Are credentials trustworthy? Maximum verifiability means cryptographic proofs, attestations from trusted issuers, on-chain verification—others can verify your identity claims.

Think: Verifiable credentials from government/universities vs. anonymous accounts with no provable attributes.

Why You Can't Have It All

Here's the fundamental constraint: These three dimensions are in tension with each other.

Want maximum self-sovereignty? You need decentralized identity systems, self-custody of credentials, no central authority. That means complex key management, user responsibility, and potential for identity loss. Verifiability suffers without trusted issuers.

Want maximum privacy? You need pseudonymity, unlinkability, zero-knowledge proofs. That means hiding your real identity, making verification difficult, and reducing accountability. Verifiability suffers when identity is hidden.

Want maximum verifiability? You need trusted issuers, on-chain credentials, public verification. That means revealing identity, centralization through issuers, and reduced privacy. Self-sovereignty or privacy suffers.

The trilemma forces you to choose: Which two matter most? What are you willing to sacrifice?

Real-World Examples

Self-Sovereign Identity (SSI) - Self-Sovereignty + Privacy, Sacrifice Verifiability

You control your own DIDs and verifiable credentials. High privacy through selective disclosure. But without trusted issuers or on-chain verification, others may not trust your claims. Verifiability: 40%.

Anonymous Credentials (Zero-Knowledge) - Privacy + Verifiability, Sacrifice Self-Sovereignty

Zero-knowledge proofs allow verification without revealing identity. High privacy and verifiability. But credentials issued by centralized authorities, limited portability. Self-Sovereignty: 50%.

On-Chain Identity (ENS + POAPs) - Self-Sovereignty + Verifiability, Sacrifice Privacy

Decentralized naming and on-chain credentials. High self-sovereignty and verifiability. But all activity is public and linkable. Privacy: 20%.

Traditional KYC/AML - Verifiability + Privacy (Limited), Sacrifice Self-Sovereignty

Government-issued credentials, trusted verification. Some privacy through data protection laws. But identity controlled by institutions, not portable. Self-Sovereignty: 10%.

Pseudonymous Wallets - Self-Sovereignty + Privacy, Sacrifice Verifiability

Crypto wallets with no KYC. Full self-sovereignty and privacy. But no way to prove real-world attributes or build trust. Verifiability: 15%.

The Honesty Principle

Many identity systems claim to solve the trilemma through innovative cryptography or blockchain technology. But these claims often hide tradeoffs behind technical complexity.

The trilemma framework forces honesty: If you want true self-sovereignty, you must accept reduced verifiability or privacy. If you want maximum privacy, you must accept reduced verifiability or self-sovereignty. If you want maximum verifiability, you must accept reduced privacy or self-sovereignty.

Pseudonymous wallets don't compromise—they make the philosophically honest choice: maximize self-sovereignty and privacy by explicitly accepting that verifiability is minimal.

This is not a bug—it's the honest architecture. Users who want control and privacy must accept that they cannot prove real-world attributes or build institutional trust. In exchange, they get actual self-sovereignty—not the illusion of it.

Pseudonymous Wallet

Maximum self-sovereignty and privacy, minimal verifiability

Position: Self-Sovereignty + Privacy

Dimension Scores

Self-Sovereignty 95%
Control over identity, no central authority
Privacy 90%
Pseudonymity, unlinkability
Verifiability 15%
Proof of attributes, trust

Trilemma Constraint Analysis

Total Score: 200 / 300 theoretical max
⚠️ The trilemma constraint: you cannot maximize all three dimensions simultaneously. Optimizing for two means the third must be lower.

Compare Identity Architectures

Build Custom Identity Architecture

Self-Sovereignty 50%
Privacy 50%
Verifiability 50%
Total: 150 / 300

Key Insights

→

No perfect solution exists. Every identity architecture makes explicit tradeoffs between self-sovereignty, privacy, and verifiability.

→

Pseudonymous wallets (95% self-sovereignty, 90% privacy, 15% verifiability) represent an honest choice: maximize control and privacy by accepting minimal verifiability.

→

Verifiable credentials sacrifice privacy or self-sovereignty for trust—but so do traditional KYC systems (centralized control).

→

True self-sovereignty requires accepting limits. If you want control and privacy, you must accept reduced ability to prove real-world attributes.

※ Personhood Verification Trilemma (Discussion from ChatGPT)

▼

Yes. There *is* a trilemma hiding in there—and it's not accidental. It's structural.

You can think of it as the Personhood Verification Trilemma. Any system that tries to onboard "unique real people" runs into three goals that cannot be fully satisfied at the same time.

The Trilemma

A system can maximize at most two of the following three:

1. Strong Uniqueness

One human ↔ one identity, robust against Sybil attacks.

2. Privacy / Anonymity

No central authority can link the identity to a real-world person or track behavior across contexts.

3. Decentralization / Accessibility

No single gatekeeper; globally usable; low barriers to entry.

Push hard on any two, and the third degrades.

The Three Edges, Made Concrete

Uniqueness + Privacy → Weak Decentralization

This is the biometric + ZK direction. You can prove "I'm unique" without revealing who you are—but only if someone controls enrollment hardware, ceremonies, or issuance rules. This is where systems like biometric or ritual-based schemes drift toward hidden centralization, even if the cryptography is elegant.

Uniqueness + Decentralization → Weak Privacy

This is the social graph / web-of-trust direction. No central authority; uniqueness emerges socially. But your relationships, behavior, and graph position become visible and correlatable. Sybil resistance is social, not cryptographic, which leaks metadata by design.

Privacy + Decentralization → Weak Uniqueness

This is the pure self-sovereign identity ideal. Anyone can generate keys. No gatekeepers. No data leakage. But uniqueness collapses: nothing stops one human from spawning many identities. You get pseudonymity, not personhood.

Why This Trilemma is Unavoidable (Not a Tooling Problem)

The tension comes from something deeper than technology:

  • Uniqueness requires comparison — Comparison requires shared reference points. Shared reference points create power or visibility.
  • Privacy resists comparison — The better the privacy, the harder it is to tell identities apart.
  • Decentralization resists authority — But authority is the cheapest way to resolve disputes about sameness.

This is not an engineering failure. It's a coordination law.

A Sharper Formulation (Worth Keeping)

You're not choosing between technologies. You're choosing where power lives:

  • In institutions (states, companies)
  • In bodies (biometrics)
  • In communities (social graphs)
  • In protocols (cryptography + incentives)

Every onboarding system quietly answers that question, whether it admits it or not.

The Meta-Insight

The real mistake is trying to "solve" the trilemma globally.

Mature systems:

  • Accept the trilemma
  • Localize it per use-case
  • Price access proportionally to risk
  • Allow identities to compose rather than dominate

In other words: Identity should be contextual, not absolute.

Once you see the trilemma, you stop asking "Which system is best?" and start asking "Which failure mode do we accept here?"