Chokepoints of the ‘Decentralized’ Web
Exploring identity portability, client plurality, and social recovery
This post was inspired by Varun’s and Vitalik’s blog posts.
The promise of Web3 has always been a more decentralized, user-owned internet - a radical departure from the walled gardens and algorithmic overlords of Web2.
I’m embracing the vision by posting on platforms like Paragraph, Zora, and Farcaster (follow, say hi! I will at times post original content on those platforms).
But the journey toward a truly decentralized stack isn’t a straight path; it’s a complex dance between ideals and realities, where centralization by necessity can creep in at unexpected layers. The question then becomes: where do the choke points for decentralization truly lie, and where does centralization actually make sense? These are key considerations when considering network ownership, risk, adoption, and failsafes.
This isn’t about denouncing either poles of the spectrum, but rather acknowledging network engineering is complex in nature. You might have sufficient decentralization in one area, only to find a critical bottleneck in another. Let’s peel back the layers of our digital infrastructure, from most abstract to most tangible, and scrutinize each for its vulnerabilities and virtues.
The Layers of the Stack:
Choke Points and Compromises
Email Lists: The First Digital ID
Before Web2 platforms dominated, email lists were a primary mode of digital communication. But traditional email is fundamentally centralized, relying on large service providers like Google, Microsoft, or independent servers that can be targeted, censored, or shut down. Your digital presence, your direct line to your audience and contacts, often rests on a single point of failure. It’s unlikely for now, but Google’s track record of sunsetting products in the past can rightfully bring some worries about the integrity of your Gmail inbox.
In the Web3 world, efforts are underway to decentralize this fundamental layer. Projects like Mailchain, EtherMail, and iExec Web3Mail are building protocols for blockchain-based email, promising end-to-end encryption, user privacy, and censorship resistance by leveraging decentralized storage and blockchain identities. EtherMail, for instance, offers "email-as-a-wallet" functionality, allowing crypto transactions directly from the inbox. Other known providers include HashMail and DMail Network.
While these platforms offer a compelling vision, widespread adoption remains a challenge, as users are accustomed to the seamless, albeit centralized experience of traditional email. The user experience hurdle here is significant: convincing billions to migrate from familiar interfaces to a new paradigm of cryptographic keys and wallet ownership. It’s easy enough today to access email recovery options with current options, but losing private keys or exposing them can mean exposing an entire email chain history to a malicious third party, or losing access to your email address altogether (there are solutions to this, see forward secrecy).
Private Keys: Sovereignty or Burden?
At the very core of Web3 ownership lies the private key, the cryptographic secret that grants control over your digital assets and identity. "Not your keys, not your coins" is a pervasive mantra. Self-custody offers unparalleled sovereignty, meaning you and only you control your funds. This is the purest form of decentralization at the individual level.
However, with power comes responsibility. Lose your private key or seed phrase, and your assets are gone forever, with no customer support hotline to call. This "human error" vulnerability is a significant decentralization choke point, as it places the entire burden of security squarely on the end-user. This complexity often pushes users towards custodial solutions offered by centralized exchanges, which manage private keys on your behalf. While convenient and offering recovery options, these solutions reintroduce the very centralization Web3 seeks to avoid, exposing users to the risks of hacks, insolvency, or censorship by a third party. The trade-off between user convenience and absolute self-sovereignty is stark and defines much of the Web3 user experience challenges. However, there are social recovery possibilities emerging:
Smart social recovery. Vitalik’s argument is simple: self-custody should not mean single-point-of-failure. Social recovery uses “guardians” you choose, with a time delay and clear on-chain rules so you can regain access if you lose your signer, while keeping day-to-day control yourself. See his primer on social recovery wallets. Wallets like Argent and Safe ship this today.
Account abstraction (ERC-4337). Vitalik’s “three transitions” put wallet security front and center: move users to smart-contract wallets that can do recovery, session keys, spending limits, and gas abstraction by design. This removes seed-phrase roulette for normal people. Read The Three Transitions and the Ethereum.org overview of account abstraction.
MPC and passkeys as UX relief. Multi-party computation splits a key across devices or services so no single party can move funds. Paired with passkeys and recovery modules, you get “no seed phrase” onboarding with non-custodial guarantees. See Safe’s recovery work and paymasters, plus passkey-aware flows in builder docs like Candide’s recovery module.
Community recovery and reputation. The DeSoc paper by Ohlhaver, Weyl, and Buterin explores non-transferable credentials and community recovery as building blocks for humane self-custody and Sybil-resistant governance. Definitely worth a read if you care about long-run legitimacy and “who vouches for whom”.
Blockchains: Decentralized by Design, Centralized by Necessity
The underlying blockchain is often considered the bedrock of decentralization. Layer 1s (e.g., Ethereum) aim for broad decentralization through distributed consensus. However, as these networks scale, new centralization vectors emerge.
Layer 2 (L2) scaling solutions, such as rollups (Optimism, Arbitrum, Base, zkSync Era, Linea, Polygon zkEVM, Scroll, and more), process transactions off-chain in batches before submitting them to the L1. While this significantly increases throughput and reduces costs, most L2s currently rely on centralized "sequencers". These sequencers collect, order, and batch transactions, introducing a single point of failure and potential for censorship or "maximal extractable value" (MEV) extraction. If a centralized sequencer goes down, the entire L2 network can halt. While projects like Metis and shared sequencers (e.g., Espresso) are working on decentralizing this role, it highlights how even within a core blockchain layer, practical scaling solutions can introduce centralization. The Nakamoto Coefficient is one way to measure decentralization across the blockchain stack, for other public blockchain projects (Bitcoin, Solana, etc).
Platforms: The Social Graph and Beyond
The comparison between Farcaster and X is a prime example of the platform layer's complexities. X is the quintessential centralized platform: user data, content, and the social graph are owned and controlled by a single corporation. Monetization, moderation, and feature development are all dictated from a central authority. Farcaster, on the other hand, embodies a decentralized social protocol. It leverages on-chain identity (FIDs), off-chain "casts" (tweets), and an open protocol that allows anyone to build clients. The social graph itself is more open and less susceptible to the whims of a single company.
However, even in Farcaster's architecture, there are nuances. While the protocol is open, the initial user experience still often relies on centralized client applications like Warpcast. The underlying infrastructure for storing "casts" and user data, even if distributed, still requires reliable hosting and indexing. The challenge is striking a balance between decentralization, scalability, and a user experience that can compete with the polish of centralized giants. Farcaster's strength lies in its protocol-level decentralization, empowering developers to innovate on the client layer without permission, a stark contrast to X's closed ecosystem.
A social network achieves sufficient decentralization if two users can find each other and communicate, even if the rest of the network wants to prevent it.
-Varun Srinivasan
Markets: From Bazaar to OpenBazaar
Traditional marketplaces like Amazon or eBay are deeply centralized, controlling listings, payments, and dispute resolution. Decentralized marketplaces (who can forget the early predecessor, Silk Road) aim to remove these intermediaries, allowing peer-to-peer (P2P) transactions with greater transparency and lower fees. Platforms like OpenBazaar (though it has faced challenges) demonstrated the concept of trading goods without central oversight.
The advantages are clear: smart contracts can automate escrows, ensuring payments are released only upon transaction completion, and cryptographic payments remove traditional payment providers. Yet, these marketplaces face their own set of centralization challenges. Building trust in a permissionless environment without central authority for dispute resolution is difficult. While review systems and reputation tracking are being implemented, replicating the perceived security and efficiency of centralized customer service remains a hurdle. Furthermore, the reliance on tokens for governance or utility can also introduce new forms of economic centralization if token distribution becomes concentrated.
Apps (and App Stores): The Digital Gatekeepers
A recent Google policy change (Aug 2025) came under fire, as a prime example of centralization at the application distribution layer (Google since provided a clarification). Apple's App Store and Google's Play Store act as powerful gatekeepers, dictating terms, taking significant cuts from transactions, and having the power to delist applications. This control extends to content, payment rails, and the very existence of an app on a user's device.
In Web3, the vision is "dApps" (decentralized applications) that can be accessed directly via web browsers or specialized Web3 browsers, bypassing traditional app stores entirely. Projects like StepN (a move-to-earn game) and Gnosis Pay (a decentralized payment network integrated with Visa) show how dApps can offer new models of ownership and rewards, directly challenging Web2 paradigms. However, user onboarding to dApps can be notoriously complex, often requiring specific wallet setups and a deeper understanding of blockchain mechanics. This complexity can push dApp developers to make compromises for easier user access, potentially leveraging centralized services for parts of their stack.
Wallets: The User Interface to Your Digital Assets
Wallets are the interface to the blockchain, holding your private keys and facilitating transactions. The choice between a custodial and non-custodial wallet heavily influences the degree of decentralization, backup optionality, fees, and end-user experiences.
Custodial wallets (like those on centralized exchanges) offer ease of use, account recovery, and often a familiar interface. They abstract away the complexity of private key management, making them popular for beginners. However, they mean you're trusting a third party with your funds, reintroducing a central point of control and vulnerability.
Non-custodial wallets (like Phantom, hardware wallets) give users full control over their private keys. This is the true decentralized option, but it demands technical understanding and meticulous security practices. The user experience for non-custodial wallets can be daunting for newcomers, involving seed phrases, gas fees, and complex transaction approvals. The ongoing challenge for Web3 is to build non-custodial wallets that are as secure as they are user-friendly, bridging the gap between absolute self-sovereignty and mainstream usability.
UX/UI: The Unsung Centralizer
Perhaps one of the most significant, yet often overlooked choke points for decentralization is the user experience (UX) and user interface (UI). Web2 platforms have perfected intuitive, seamless experiences that abstract away technical complexities. Web3, by its very nature, exposes users to concepts like gas fees, transaction confirmations, network congestion, and private key management.
The current state of Web3 UX often creates a high barrier to entry, making it difficult for mass adoption. Complex wallet connection processes, unclear visual language, and a lack of educational materials overwhelm new users. Many Web3 projects prioritize "protocol-first" development, with UX/UI often taking a backseat. This inadvertently pushes users towards more centralized solutions that offer familiar ease of use, even if it means sacrificing decentralization. The pursuit of a truly decentralized internet requires a revolutionary leap in UX design that makes self-custody and on-chain interactions as simple, if not simpler, than their centralized counterparts.
Other Critical Infrastructure Layers
Beyond the obvious layers, several other components of the digital infrastructure stack can introduce centralization between the end-user and a "decentralized" protocol:
DNS (Domain Name System): The internet's phonebook, which translates human-readable domain names into IP addresses, is largely centralized through ICANN and domain registries. While Web3 domains (e.g., Ethereum Name Service (ENS), Unstoppable Domains) aim to decentralize this by registering domains on a blockchain as NFTs, the vast majority of web access still relies on traditional DNS. A fully decentralized web would require a pervasive decentralized DNS.
RPC Nodes (Remote Procedure Call): DApps interact with blockchains via RPC nodes. While anyone can run a node, many dApp developers rely on centralized RPC providers (like Alchemy or Infura) for scalability and reliability. This means that a dApp, even if its smart contracts are on-chain, can have a centralized point of failure or censorship if its primary RPC provider decides to block access or goes offline. Decentralized RPC networks are emerging to address this, but running your own node currently requires significant technical expertise and resources.
CDNs (Content Delivery Networks): Most websites, including many Web3 frontends, rely on CDNs (like Cloudflare) to deliver content quickly. While beneficial for performance, CDNs are centralized entities that can be subject to censorship or denial-of-service attacks.
Oracles: Decentralized applications often need real-world data (e.g., price feeds) to execute smart contracts. Oracles provide this data, and if the oracle network itself is centralized, it creates a single point of truth and potential manipulation, even if the smart contract is decentralized.
DePIN (Decentralized Physical Infrastructure Networks): This emerging category focuses on decentralizing real-world infrastructure like wireless networks, data storage, and computing power. By incentivizing individuals to contribute physical resources via blockchain tokens, DePIN aims to mitigate centralization choke points in fundamental infrastructure, shifting from centralized landlords of compute to a distributed, community-owned model. A "Great API Purge" scenario where AI startups built on rented compute get crushed by centralized platform landlords, highlights the criticality of decentralized infrastructure, and mirroring the importance of how Bitcoin solved money and payment centralization.
Social Layer: Pick a threat model, then install guardrails. If you refuse custodial risk yet want adult-proofing, combine a smart account with social recovery, set spending limits, and keep at least one out-of-band device as a guardian. The question to ask is not “custodial or not,” it is “what are my escape hatches if this wallet, this L2, or this client fails.”
Centralization by Design
Following the Middleware Thesis (2023), the true bottleneck for crypto adoption isn’t raw scalability but the absence of middleware stacks that make blockchain rails usable for everyday applications. The thesis predicted that purpose-built, vertically integrated chains would emerge to serve specific functions like payments, social, and gaming, rather than relying on generic base layers.
As Robinhood, Circle, and Stripe roll out their own chains, we’re watching the thesis crystallize: these firms aren’t chasing decentralization purity, they’re building middleware that leverages blockchain efficiency while maintaining the centralization needed for compliance, stability, and user trust.
Stripe’s stablecoin payments, for example, are less about becoming a “crypto company” and more about embedding programmable money into an existing global payments stack. This doesn’t negate decentralization’s importance, it clarifies the terrain: centralization can coexist with blockchain rails when it delivers real-world usability, so long as the core principles of censorship resistance and user sovereignty remain protected at the edges.
Conclusion: The Spectrum of Decentralization
The journey toward a truly decentralized internet is far from over. As we've explored, "decentralization" is not a binary state but a spectrum, with choke points and centralizing forces existing at nearly every layer of the digital stack:
Email lists still largely rely on centralized providers, though Web3 alternatives are emerging.
Private keys offer ultimate sovereignty but demand significant user responsibility, often pushing users towards convenient, yet centralized, custodial solutions.
Blockchains, particularly Layer 2s, often rely on centralized sequencers for efficiency, creating potential bottlenecks.
Platforms, even those like Farcaster, navigate the tension between open protocols and the need for user-friendly, often centralized, client applications.
Markets grapple with building trust and dispute resolution in a permissionless environment.
Apps and App Stores remain highly centralized gatekeepers, though dApps offer an alternative, albeit with significant UX hurdles.
Wallets present a clear trade-off between user convenience (custodial) and absolute control (non-custodial).
UX/UI itself is a major centralizing force, as the inherent complexity of Web3 drives users to simpler, often centralized, solutions.
Underlying infrastructure like DNS, RPC nodes, and CDNs are often centralized, posing hidden choke points. DePIN offers a promising path to decentralize some of these physical layers.
Social layers where we need tech-savvy communities, companies, and services that allow for better custody, social recovery, and exit strategies in case of technical or cultural failures.
The core thesis remains: true decentralization requires addressing these chokepoints across all layers, which isn’t necessarily a nearsighted goal of crypto and digital infrastructure comprising the internet. However, decentralization requires innovative solutions that balance the ideals of sovereignty and censorship resistance with the practicalities of scalability, usability, and mainstream adoption. While some centralization might be a necessary compromise for user experience or specific enterprise needs (as seen with Stripe), a vigilant eye must be kept on ensuring that these compromises don't undermine the fundamental ethos of a user-owned, permissionless internet.
The future of the internet will likely be a hybrid one, but the ongoing effort to push the boundaries of decentralization, layer by layer, is paramount for building a truly resilient and equitable digital future.
Support the Blog:
You can support the blog by owning Parallel Citizen’s creator coin on Zora
You can also collect this post as a Zora token here
Any tips on Paragraph are also paired with the creator coin
Sponsors:
(purchasing through these links helps support the blog)
Trezor - Open-source hardware wallets for sovereign custody
Article Summary:
🧩 Sufficient Decentralization → A Practical Lens
Borrowing Varun’s test and Vitalik’s wallet ideas, judge systems by three things: can users find each other, keep identity portable, and exit cleanly when parts fail.🕸️ The Stack Has Chokepoints
Email, keys, L2 sequencers, app stores, RPC, DNS, CDNs, and oracles all concentrate power, even when protocols are open; Farcaster keeps identity on-chain with client choice while most L2s still hinge on a single sequencer.
🛡️ Build For Recovery And Exit
Use smart accounts with social recovery and MPC, diversify infra and RPCs, favor auditable bridges and clear withdrawal guarantees, document break-glass paths so users can leave a client, an L2, or a provider without losing their graph.
🧪 Middleware Over Maximalism
Expect hybrid stacks where fintech rails chase compliance and UX, DePIN pushes storage and compute to the edges, and sovereignty survives when control sits with users, governance is transparent, and exits remain cheap.
Great article 👏🏼