The Architecture of Access: A Definitive Analysis of Web3 Gateways and Infrastructure

1. The Gateway Paradox: Infrastructure in a Decentralized Age

1.1 The Fundamental Disconnect

The promise of Web3 is predicated on a vision of a peer-to-peer (P2P), permissionless internet where users interact directly with decentralized protocols, free from the intermediation of centralized gatekeepers. However, the architectural reality of the contemporary blockchain ecosystem reveals a stark contradiction: to access these decentralized networks, the vast majority of users and applications rely on a highly concentrated layer of centralized infrastructure. This phenomenon, often termed the "Gateway Paradox," defines the current state of the industry.1

Blockchains, by design, are closed state machines. They operate on specific gossip protocols and consensus mechanisms that are fundamentally incompatible with the standard HTTP/S protocols used by web browsers and mobile devices. A user wishing to inspect their token balance or submit a transaction cannot simply "browse" the blockchain in the way they browse the web. They require a translation layer—a node—that speaks the language of the blockchain. In the early days of Ethereum, this meant every user had to run their own geth or parity node, a process requiring significant technical expertise, massive storage capacity, and constant maintenance.

1.2 The Taxonomy of Web3 Gateways

The term "gateway" in Web3 is not monolithic; it encompasses a diverse stack of infrastructure components, each addressing a specific friction point in the user journey.

1.2.1 RPC Providers (The Connectivity Layer)

Remote Procedure Call (RPC) providers are the foundational utility of the Web3 stack. They act as the "dial-tone" for the blockchain, facilitating the read and write operations. When a wallet like MetaMask submits a transaction, it sends a JSON payload to an RPC endpoint. This provider then broadcasts the transaction to the blockchain's mempool. Conversely, when a dApp displays a user's balance, it is the RPC provider that queries the blockchain state and returns the value. This layer is dominated by entities like Infura, Alchemy, and QuickNode, which have industrialized node management.5

1.2.2 Indexing Protocols (The Data Layer)

Raw blockchain data is linear and unoptimized for complex retrieval. A standard node can easily tell you the balance of an address, but it cannot efficiently answer a query like "show me all NFTs minted by this contract in the last 24 hours." To solve this, indexing gateways like The Graph have emerged. These protocols scan the blockchain, organize data into queryable schemas (Subgraphs), and serve it via high-performance APIs, typically using GraphQL. This layer bridges the gap between the chaotic raw ledger and the structured data needs of modern UI/UX.7

1.2.3 Storage Gateways (The Content Layer)

While blockchains store transaction data, they are too expensive for storing media files like images or frontend code. Protocols like the InterPlanetary File System (IPFS) handle this content-addressable storage. However, browsers cannot natively resolve ipfs:// URIs. Storage gateways, such as those provided by Cloudflare, Pinata, and Infura, act as HTTP-to-IPFS bridges, allowing users to view decentralized content through standard web browsers. These gateways essentially cache IPFS content on edge servers, providing the speed of Web2 delivery with the addressability of Web3.9

1.2.4 Identity and Interface Gateways (The Interaction Layer)

At the top of the stack sit the wallets and interfaces (e.g., MetaMask, Rainbow). While often thought of as standalone software, they function as the ultimate gateway for the end-user. They manage the private keys and sign the messages that are sent to the RPC layer. The design of these wallets, specifically their default RPC settings, plays a decisive role in determining which infrastructure providers dominate the market. For instance, MetaMask's default use of Infura has historically funneled a massive portion of Ethereum traffic to a single provider.1

1.3 The Evolution from Web2 to Web2.5

The current state of the industry is frequently described as "Web2.5." This nomenclature reflects a hybrid architecture where the backend settlement layer is decentralized (the blockchain), but the access layer remains centralized (Web2 style servers). This transition period is characterized by a tension between convenience and principles. Centralized gateways offer superior performance, lower latency, and developer ease-of-use, mirroring the "Move Fast and Break Things" ethos of Silicon Valley. However, they reintroduce the very risks—censorship, surveillance, and single points of failure—that Web3 was designed to eliminate.2

As detailed in subsequent sections of this report, the industry is currently undergoing a painful but necessary evolution. We are witnessing a bifurcation of the market: on one side, highly optimized "Supernodes" and federated corporate networks (DIN) are pushing the limits of performance for enterprise use cases. On the other, a resurgence of "verification" technologies—light clients like Helios and decentralized relay networks like Pocket—are attempting to restore the trustless guarantees of the original Web3 vision. This dialectic between performance and decentralization defines the architectural landscape of 2026.13

---

2. The RPC Provider Landscape: Engineering the "Dial-Tone" of Web3

The Remote Procedure Call (RPC) market represents the most mature and capital-intensive sector of Web3 infrastructure. It is the battlefield where the "Cloud Wars" of the blockchain era are being fought. Just as AWS, Azure, and Google Cloud fought for dominance in Web2 hosting, providers like Alchemy, Infura, and QuickNode are competing to become the primary interface for blockchain interaction.

2.1 Technical Architecture of Major Providers

To understand the competitive dynamics, one must look beneath the marketing claims and analyze the distinct architectural approaches taken by the market leaders.

2.1.1 Infura: The Microservice Pioneer

Infura, owned by Consensys, established the archetype for the "Node-as-a-Service" model. Its architecture, internally referred to as "Boomerang," was designed to solve the immense difficulty of scaling Ethereum nodes. A standard Ethereum node is monolithic; it handles P2P networking, state storage, and query processing all in one process. Infura deconstructed this.

• Boomerang Architecture: Infura employs a microservice-driven architecture where specialized components handle different tasks. Instead of a simple load balancer pointing to a cluster of nodes, Infura uses an intelligent routing layer. Read-heavy requests (like eth_call) are routed to cached data stores or optimized read-nodes, while write requests (eth_sendRawTransaction) are broadcast via a high-throughput propagation network.16

• The "Read" Optimization: Infura's system creates a specialized "read layer" that sits atop the raw blockchain nodes. By indexing and caching frequent requests, they can serve data orders of magnitude faster than a raw node, which must compute the state for every call. This architecture supports the massive volume required by MetaMask, which defaults to Infura.17

2.1.2 Alchemy: The Supernode Paradigm

Alchemy entered the market with a focus on developer experience and data correctness, identifying a critical flaw in the standard load-balancing model: "Node Drift." In a typical cluster of nodes, different nodes may be synced to different block heights due to network propagation latency. If a user's first request hits Node A (Block 100) and their second request hits Node B (Block 99), the user experiences "time travel"—their balance appears to revert, or a transaction disappears.

• The Supernode: Alchemy's solution is the "Supernode," a proprietary middleware layer that sits between the API and the blockchain nodes. This system acts as a coordinator, maintaining a consistent view of the chain state. It abstracts the fleet of nodes into a single, virtually infinite resource.19

• Consistency Assurance: The Supernode architecture ensures "Block-Perfect Consistency." It tracks the user's session and ensures that subsequent requests are never served by a node with an older state than the previous request. This solves the "stale read" problem that plagues naive load-balancing setups.21

2.1.3 QuickNode: The Performance Engine

QuickNode has positioned itself as the performance leader, optimizing its stack for raw speed and low latency.

• Global Edge Network: QuickNode leverages a heavily distributed network of nodes, using Anycast routing to direct user requests to the geographically closest data center. This minimizes Round Trip Time (RTT), a critical metric for high-frequency trading bots and latency-sensitive dApps.5

• Architectural Flexibility: Unlike Alchemy's highly integrated stack, QuickNode offers a more modular approach via its "Marketplace." This allows third-party developers to build add-ons (e.g., specialized NFT data indexers or MEV protection plugins) that run directly on QuickNode's infrastructure, reducing the latency between the RPC call and the auxiliary service.5

2.2 Benchmarking Performance: Speed vs. Consistency

The "Speed vs. Correctness" trade-off is a central theme in RPC architecture. A provider can cheat on latency metrics by returning data from a cached, potentially stale block, whereas a provider prioritizing correctness might wait milliseconds longer to ensure the data is from the canonical chain tip.

2.2.1 Latency Analysis (2025 Landscape)

Recent benchmarks highlight the competitive landscape:

• Helius (Solana): On the Solana network, generic providers struggle with the immense throughput. Helius has emerged as a specialist, delivering latencies in the 10-80ms range by optimizing specifically for Solana's architecture, effectively bypassing the generic EVM-centric optimizations of competitors.23

• Alchemy vs. QuickNode: Historical data from 2022 placed QuickNode ahead in raw speed (26ms vs Alchemy's 39ms). However, 2025 reports indicate Alchemy has closed this gap, claiming sub-50ms global latency while maintaining its strict consistency guarantees. QuickNode continues to lead in pure response time for simple queries, making it a favorite for arbitrage bots where milliseconds equate to profit.24

• Chainstack: Utilizing a "trader node" architecture, Chainstack consistently ranks in the top tier for latency (60-250ms), offering a middle ground with robust global routing.26

2.2.2 Data Accuracy and Reorgs

Speed is irrelevant if the data is wrong. Blockchain "reorgs" (reorganizations) occur when two blocks are mined simultaneously, and the network eventually discards one chain.

• Reorg Handling: Alchemy's Supernode and Infura's architecture include specific logic to detect reorgs. They may delay returning a "success" status for a transaction until a certain number of confirmations are reached or use predictive algorithms to determine the likely canonical chain. Naive providers simply return the first data they receive, leading to "phantom" transactions that disappear when the chain reorganizes.27

2.3 The Economics of Access: Pricing Models

The business model of Web3 gateways has matured from simple "flat rate" subscriptions to complex, consumption-based pricing. This shift reflects the varying computational cost of different RPC methods.

2.3.1 The Request-Based Model

Used by Infura and Chainstack, this model is the most intuitive: 1 API call equals 1 Request.

• Pros: Easy for developers to forecast costs.

• Cons: It ignores the computational reality. A request to check the current block number (eth_blockNumber) takes microseconds and minimal RAM. A request to scan the entire history of a contract (eth_getLogs) involves massive disk I/O and CPU time. Under this model, providers lose money on complex queries and subsidize them with simple ones.26

2.3.2 The Compute Unit (CU) Model

Pioneered by Alchemy, this model assigns a weight to every method.

• Mechanism: eth_blockNumber might cost 10 CUs, while eth_call costs 26 CUs, and eth_getLogs might cost hundreds depending on the range.

• Implication: This aligns the price with the provider's actual infrastructure cost. It incentivizes developers to optimize their code (e.g., querying narrower block ranges). However, it makes billing unpredictable; a dApp's cost can spike 10x just because users start performing more complex interactions, even if the user count remains flat.23

2.3.3 The "Transparent" Counter-Movement

Newer entrants like Dwellir and Chainnodes are aggressively marketing against the CU model. They offer "Transparent Pricing" or "No CU Confusion," reverting to request-based or hybrid models. They argue that the CU model has become a "black box" used to extract higher fees from successful dApps, positioning themselves as the developer-friendly alternative.28

Table 1: Comparative Analysis of Major RPC Providers (2025)

---

3. The Centralization Dilemma: Vulnerability in the Core

The reliance on these industrial-grade providers has created a paradox: a decentralized network accessed through highly centralized bottlenecks. This section analyzes the "Web2.5" risks, focusing on Single Points of Failure (SPOF), censorship, and surveillance.

3.1 The Fragility of "Big RPC"

The concentration of traffic through Infura and Alchemy creates systemic risk.

• Shared Fate: Many RPC providers ultimately run on the same cloud infrastructure (AWS us-east-1 or Google Cloud). A failure at the cloud provider level can cause a cascade of outages across multiple "competing" RPCs, taking down major portions of the DeFi and NFT ecosystem simultaneously. This reality reveals that the "decentralization" of the application layer is often an illusion resting on a centralized hardware layer.2

• The "Paused" Blockchain: When Infura experiences downtime (as happened frequently in 2020-2022), users of MetaMask effectively see the Ethereum blockchain as "down." While the blockchain itself continues to produce blocks, the access is severed. This effectively centralizes the availability of the network.4

3.2 The Censorship Vector: Tornado Cash and OFAC

The most existential threat to Web3's value proposition is censorship. Gateways, being centralized corporate entities, are subject to local laws and regulations.

• The August 2022 Watershed: When the US Office of Foreign Assets Control (OFAC) sanctioned the smart contracts associated with the privacy protocol Tornado Cash, the implications for gateways were immediate.

• Implementation of Censorship: Major providers like Infura and Alchemy implemented blocking at the RPC level. When a user attempted to send a transaction to a sanctioned address via MetaMask (using Infura), the request was rejected before it ever reached the blockchain mempool. This created a "permissioned" layer on top of a permissionless protocol. The gateway acted as a firewall, enforcing US sanctions globally, even for users in jurisdictions not subject to US law.31

• The "Two-Tiered" Ethereum: This event bifurcated the network access. Users running their own nodes or using censorship-resistant providers could still interact with Tornado Cash, while the majority of users (reliant on default RPCs) were blocked. This demonstrated that while the protocol is robust, the interface is fragile.31

3.3 Surveillance and the Panopticon

Privacy in Web3 is often misunderstood. While the ledger is public, the link between a user's physical identity (IP address) and their digital identity (Wallet Address) is not—unless a gateway logs it.

• The Consensys Controversy: In November 2022, Consensys updated Infura's privacy policy to explicitly state that they collect IP addresses and wallet addresses when users send transactions. This confirmed the long-held suspicion that gateways are building massive databases linking real-world identities to on-chain behavior.11

• The Surveillance Capability: Because a dominant gateway sees a significant percentage of all network traffic, they possess a "God's Eye View" of the economy. Unlike a bank that sees only its own customers' transactions, Infura or Alchemy can see the flow of funds across the entire ecosystem, creating a surveillance capability that rivals or exceeds that of traditional financial institutions.35

---

4. The Decentralized Revolt: Federation and DePIN

The risks outlined above have catalyzed a movement to decentralize the infrastructure layer itself. This has given rise to Decentralized Physical Infrastructure Networks (DePIN) and federated alliances.

4.1 Pocket Network (POKT): The Relay Mesh

Pocket Network represents the most radical departure from the centralized model. It functions as a two-sided marketplace protocol rather than a company.

• Mechanism: Developers stake POKT tokens to access the network. Their requests are routed to a mesh of tens of thousands of independent full nodes run by community members globally.

• Shannon Upgrade: The 2025 "Shannon" upgrade introduces a permissionless gateway architecture. Previously, users still accessed Pocket via a centralized portal. The new PATH gateway allows for trustless dispatching of JSON-RPC relays, where the quality of service (QoS) is handled by the protocol rather than a central load balancer.13

• Censorship Resistance: Because requests are routed pseudo-randomly to independent nodes in different jurisdictions, no single entity can effectively censor a specific contract or user. If one node blocks a request, another fulfills it. This architectural redundancy provides true resilience.30

4.2 Infura's DIN (Decentralized Infrastructure Network)

Infura's response to the centralization critique is the Decentralized Infrastructure Network (DIN).

• Federated Model: Rather than a fully permissionless P2P network, DIN is a federation of "high-quality" partners, including cloud giants like Microsoft and Tencent, as well as crypto-native providers.

• Failover Protection: The primary selling point is reliability. If Infura's own nodes go down, traffic is automatically rerouted to a partner in the DIN. This eliminates the SPOF risk while maintaining enterprise-grade Service Level Agreements (SLAs).15

• EigenLayer Integration: DIN leverages EigenLayer for economic security. "Watchers" (Actively Validated Services or AVS) verify the freshness and validity of responses from providers. This creates a "trust-but-verify" mechanism, ensuring that partners in the federation are not serving bad data.15

4.3 Aggregators: The "Expedia" of RPCs

Services like dRPC operate as aggregators. They do not necessarily run their own nodes but route traffic to a pool of underlying providers (which can include Alchemy, QuickNode, or independent operators).

• Load Balancing Algorithm: dRPC's algorithm monitors the latency and health of all underlying providers in real-time. It routes requests to the best-performing provider for that specific chain and region at that moment.

• Commoditization: This model treats RPC providers as interchangeable commodities, forcing them to compete purely on price and performance. It reduces the vendor lock-in risk for developers.26

---

5. The Verification Revolution: Light Clients and the End of "Trust Me"

The most significant technological shift occurring in the 2024-2026 timeframe is the move from trusted infrastructure to verified infrastructure. This shift is powered by Light Clients, which allow devices to verify blockchain data without the massive overhead of a full node.

5.1 The "Trust-Me" Problem

In the standard RPC model, when a wallet asks, "What is the balance of Account X?", the RPC provider sends back a number. The wallet has no way to know if this number is true. It must trust the provider. This is known as a "Trust-Me" architecture. If the provider is malicious or compromised, they could display false balances or trick the user into signing a bad transaction.14

5.2 Helios: The Verified Light Client

Developed by a16z crypto, Helios is a game-changer for the Ethereum ecosystem. It is a light client written in Rust that compiles to WebAssembly (WASM), allowing it to run directly in a browser or mobile wallet.

• Sync Mechanism: Helios does not download the blocks. Instead, it syncs with the Beacon Chain (Consensus Layer). It downloads block headers and verifies the signatures of the "Sync Committee"—a randomly selected group of 512 validators.

• Merkle Proofs: When Helios needs data (e.g., an account balance), it queries an untrusted RPC provider (like Alchemy). However, it asks for the data plus a Merkle Proof. Helios then cryptographically verifies this proof against the state root in the verified block header.

• The Result: If the RPC provider lies, the Merkle proof will fail verification mathematically. This converts the RPC provider from a "Trusted Oracle" into a "Dumb Pipe." The user no longer needs to trust Infura or Alchemy; they only need to trust the Ethereum consensus protocol.14

• Wallet Integration: By 2026, leading wallets like Rainbow and MetaMask (via the Snaps system) are integrating Helios. This allows them to offer a "Trustless Mode," where the user's connection to the blockchain is cryptographically verified, protecting them from data manipulation and censorship.40

5.3 The Portal Network

While Helios solves the verification problem, it still relies on centralized RPCs to fetch the data. The Portal Network aims to decentralize the data fetching itself.

• DHT Architecture: The Portal Network is a peer-to-peer network designed specifically for light clients. It uses a Distributed Hash Table (DHT) to store blockchain history and state.

• Lightweight Nodes: Unlike full nodes that must store everything, a Portal node only stores a small slice of the data (e.g., a specific range of history). When a light client needs data, it queries the Portal Network, which routes the request to the specific node holding that data.

• The Endgame: This architecture allows a smartphone to access any piece of Ethereum data directly from the P2P network, bypassing centralized gateways entirely. It represents the "endgame" for decentralized access.42

---

6. Indexing Gateways: Ordering the Chaos

While RPCs handle raw data, Indexing Gateways handle organized data. This is a critical distinction for dApp developers who need to display complex user histories or aggregated statistics.

6.1 The Graph: Decentralized Indexing

The Graph is the dominant protocol in this space. It functions as a decentralized query layer for the internet.

• Subgraphs: Developers define "Subgraphs," which are open APIs describing how to index data from a specific contract.

• Network Participants:

• Indexers: Node operators who stake GRT tokens and run the hardware to index subgraphs.

• Curators: Users who signal which subgraphs are high-quality by staking on them.

• Delegators: Token holders who delegate stake to Indexers to earn a share of query fees.

• The Gateway Component: In The Graph's decentralized network, the "Gateway" acts as a market maker. It routes user queries to the most performant and cost-effective Indexers. It handles the payment channels (using state channels for micro-payments per query) and ensures Quality of Service (QoS).7

6.2 Substreams and Firehose

To address the performance limitations of sequential indexing, The Graph introduced Firehose and Substreams.

• Firehose: This technology extracts data from blockchain nodes in a highly efficient, streaming format, bypassing the slow JSON-RPC polling methods.

• Substreams: This allows for parallel processing of data streams. Instead of indexing block 1, then 2, then 3, Substreams can process huge ranges of blocks simultaneously. This enables massive throughput, allowing dApps to build real-time analytics dashboards that were previously impossible on decentralized infrastructure.45

6.3 Centralized Competitors

Despite The Graph's dominance, centralized indexers like Goldsky and Satsuma (often built on modified versions of The Graph's open-source stack) remain popular. They offer lower latency and simpler developer experiences (no GRT token management) but reintroduce the SPOF risks. The market is currently seeing a "hybrid" approach where dApps start with centralized indexers for speed and migrate to The Graph for decentralization as they mature.

---

7. Storage Gateways: Bridging Web2 and Web3 Content

The final pillar of the gateway stack is storage. Since blockchains cannot efficiently store large files (images, frontend code, PDFs), these assets live on decentralized storage networks like IPFS.

7.1 The IPFS Gateway Problem

IPFS uses content addressing (ipfs://QmHash...) rather than location addressing (https://server.com/file). Standard web browsers (Chrome, Safari) do not natively understand the IPFS protocol.

• The Bridge: An IPFS Gateway acts as a translator. It accepts an HTTP request (e.g., https://ipfs.io/ipfs/QmHash), fetches the content from the IPFS swarm, and serves it back to the user over HTTP.

7.2 Public vs. Dedicated Gateways

• Public Gateways: Operated by Protocol Labs, Cloudflare, and others as a public good. These are free but often slow, rate-limited, and unreliable for production apps. They also pose a privacy risk, as the gateway operator can see exactly what content a user is requesting.10

• Dedicated Gateways: Services like Pinata and Cloudflare Web3 offer paid, private gateways.

• Pinata: Focuses on the NFT creator economy. They provide "Submarining" (access control), allowing creators to attach private data to NFTs that is only accessible via a dedicated gateway with a valid token.

• Performance: Dedicated gateways use massive caching networks (CDNs) to ensure that decentralized content loads as fast as centralized content. This is crucial for NFT marketplaces, where slow-loading images directly impact sales.47

---

8. Integration: The User Experience Layer

The complexity of these gateways is hidden from the user by the wallet layer. However, the wallet's choice of integration defines the user's security model.

8.1 Default Providers and User Choice

Historically, wallets hardcoded a single RPC provider (e.g., MetaMask -> Infura). This created vendor lock-in. Modern wallets are moving toward "Multi-RPC" configurations.

• Rainbow Wallet: Known for its user-centric design, Rainbow is aggressively integrating verified data sources and offering clearer controls over which RPCs are used.

• MetaMask Snaps: The Snaps system allows developers to extend MetaMask's functionality. This has enabled the creation of Snaps that allow users to connect to non-EVM networks (like Bitcoin or Solana) or to swap out the default Infura connection for a privacy-preserving alternative like Pocket Network or a local light client.49

8.2 The Rise of Account Abstraction (ERC-4337)

The introduction of Account Abstraction creates a new type of gateway: the Bundler.

• Role of the Bundler: In ERC-4337, users do not send transactions; they send "UserOperations" (UserOps). These UserOps are collected by a Bundler, which batches them into a transaction and submits them to the blockchain.

• Gateway Evolution: The Bundler effectively becomes the write-gateway. It handles gas payments (Paymasters) and transaction ordering. Major RPC providers like Alchemy are pivoting to become dominant Bundlers, seeing this as the future of transaction submission. This shifts the "gateway" value proposition from simple connectivity to complex transaction orchestration.51

---

9. Future Horizons: The Gateway of 2030

As we look toward the end of the decade, the gateway landscape will be defined by Modularization and Embedded Verification.

9.1 The Modular Blockchain Fragment

The explosion of Layer 2 (L2) and Layer 3 (L3) chains means a single application might interact with dozens of different networks.

• The Aggregation Opportunity: It will become impossible for a single provider to run high-quality nodes for every long-tail AppChain. This favors aggregators (like dRPC) and federated networks (DIN) that can dynamically route traffic to specialized providers for specific chains.

• Interoperability Gateways: Gateways will evolve to handle cross-chain intents. A user might send a request to "Swap USDC on Base for ETH on Arbitrum." The gateway (likely an Account Abstraction Bundler) will handle the bridging and execution across multiple chains abstractly.

9.2 Verification as a Standard

The "Light Client" will cease to be a niche tool and become the industry standard.

• Embedded Verification: Browsers and mobile OSs may eventually integrate light client logic natively. "Trustless RPC" will be the default expectation. Providers that cannot provide Merkle proofs for their data will be flagged as "Insecure" by wallet software, forcing the entire industry to upgrade to verifiable infrastructure.

9.3 Conclusion

The evolution of Web3 gateways tells the story of the industry's maturation. We moved from the "DIY" era of running local nodes to the "Convenience" era of centralized giants like Infura and Alchemy. Now, driven by the hard lessons of censorship and fragility, we are entering the "Verification" era.

The "Gateway Paradox" is being resolved not by eliminating the gateway, but by stripping it of its power. Through technologies like Helios, DIN, and The Graph, the gateway is being transformed from a trusted gatekeeper into a verifiable utility—a dumb pipe that serves the data we need, without requiring the trust we can no longer afford to give. The future of Web3 access is resilient, federated, and mathematically verified.

---

Table 2: The Evolution of Gateway Architecture

Works cited

1. Web3 Concepts and General Introduction (Chapter 1), accessed February 5, 2026, https://www.cambridge.org/core/books/web3/web3-concepts-and-general-introduction/DE6BF60494E78717AD9C15DA3D3BC1BC

2. The Hidden Centralization of Web3: Why Decentralization is not what it seems | by Blessing Mba | Medium, accessed February 5, 2026, https://medium.com/@blessingmba3/the-hidden-centralization-of-web3-why-decentralization-is-not-what-it-seems-55b2e00dc8c7

3. Bridging Web2 and Web3: Design Patterns for Hybrid Platforms - Almax Agency, accessed February 5, 2026, https://almaxagency.com/design-strategy/bridging-web2-and-web3-design-patterns-for-hybrid-platforms/

4. This single point of failure can kill web3's dream of an open, decentralized internet, accessed February 5, 2026, https://cryptoslate.com/this-single-point-of-failure-can-kill-web3s-dream-of-an-open-decentralized-internet/

5. Top 10 Base RPC Providers in 2026 | Quicknode, accessed February 5, 2026, https://www.quicknode.com/builders-guide/best/top-10-base-rpc-providers

6. Top 10 Web3 Infrastructure Providers in 2026 - Quicknode, accessed February 5, 2026, https://www.quicknode.com/builders-guide/best/top-10-web3-infrastructure-providers

7. What is The Graph Network? - The Graph Academy, accessed February 5, 2026, https://thegraph.academy/ecosystem/the-graph-network/

8. What is the Graph? Know How Does It Work | Shardeum, accessed February 5, 2026, https://shardeum.org/blog/what-is-the-graph/

9. Cloudflare Web3 | IPFS & Ethereum, accessed February 5, 2026, https://www.cloudflare.com/application-services/products/web3/

10. IPFS Privacy. How Private is IPFS? | by Matt Ober | Pinata - Medium, accessed February 5, 2026, https://medium.com/pinata/ipfs-privacy-711f4b72b2ea

11. Infura Collecting MetaMask Users' IP, Ethereum Addresses After Privacy Policy Update, accessed February 5, 2026, https://decrypt.co/115486/infura-collect-metamask-users-ip-ethereum-addresses-after-privacy-policy-update

12. What Is Web2.5? A Builder's Guide to the Web2–Web3 Bridge - Hacken.io, accessed February 5, 2026, https://hacken.io/discover/web2-web3-bridge/

13. Understanding PATH: Decentralized Gateway Infrastructure for the Shannon Upgrade, accessed February 5, 2026, https://pocket.network/path-gateway/

14. a16z/helios: A fast, secure, and portable multichain light client for Ethereum - GitHub, accessed February 5, 2026, https://github.com/a16z/helios

15. Decentralized Infrastructure Network (DIN): the Multichain RPC that does not fail. - Infura, accessed February 5, 2026, https://www.infura.io/solutions/decentralized-infrastructure-service

16. INFURA 'Boomerang' Architecture. Rethinking the decentralized… | by Michael Wuehler | Medium, accessed February 5, 2026, https://medium.com/infura/infura-boomerang-architecture-6dc27ef56646

17. Build with Infura - The most reliable blockchain node provider, accessed February 5, 2026, https://www.infura.io/platform/infrastructure

18. Why Infura Is the Secret Weapon of Ethereum Infrastructure - Consensys, accessed February 5, 2026, https://consensys.io/blog/why-infura-is-the-secret-weapon-of-ethereum-infrastructure

19. Pros and Cons of Running Your Own Node - Alchemy, accessed February 5, 2026, https://www.alchemy.com/overviews/running-your-own-node

20. Introducing Alchemy Supernode: Industry Leading Ethereum API, accessed February 5, 2026, https://www.alchemy.com/blog/introducing-alchemy-supernode

21. What is an Ethereum node? - Alchemy, accessed February 5, 2026, https://www.alchemy.com/overviews/what-is-an-ethereum-node

22. What is a Blockchain Node Provider? Why Do I Need One? - Alchemy, accessed February 5, 2026, https://www.alchemy.com/blog/what-is-a-node-provider

23. Best RPC Node Providers 2025: The Practical Comparison Guide - GetBlock.io, accessed February 5, 2026, https://getblock.io/blog/best-rpc-node-providers-2025-the-practical-comparison-guide/

24. Alchemy vs. Quicknode: Web3 Node Provider Comparison in 2025, accessed February 5, 2026, https://www.alchemy.com/overviews/alchemy-vs-quicknode

25. Comparing RPC Provider Performance | Quicknode Guides, accessed February 5, 2026, https://www.quicknode.com/guides/infrastructure/comparing-rpc-providers

26. Top Ethereum RPC providers for 2025 | Chainstack Blog, accessed February 5, 2026, https://chainstack.com/top-ethereum-rpc-providers-for-2025/

27. Understanding Blockchain Reorgs (and How to Manage Them) | by Vladyslav Semenchuk, accessed February 5, 2026, https://medium.com/@vladyslav.semenchuk9/understanding-blockchain-reorgs-and-how-to-manage-them-e9f02c70ba38

28. Top 6 Base RPC Providers 2025: Pricing & Performance - Dwellir, accessed February 5, 2026, https://www.dwellir.com/blog/top-6-base-providers-2025

29. The 12 Best Blockchain Node Providers (2025) - Alchemy, accessed February 5, 2026, https://www.alchemy.com/overviews/blockchain-node-providers

30. 7 Best RPC Providers Without Compute Units (2025) - Dwellir, accessed February 5, 2026, https://www.dwellir.com/blog/rpc-providers-without-compute-units-2025

31. RPC Censorship: The Silent Attack on Blockchain Integrity - ChainScore Labs, accessed February 5, 2026, https://www.chainscorelabs.com/en/blog/security-post-mortems-hacks-and-exploits/infrastructure-and-rpc-attacks/why-rpc-censorship-is-an-existential-attack-vector

32. Tornado Cash Suffers Several Setbacks as Infura, Alchemy, Circle, Github Comply With Sanctions | by Crypto Saving Expert | Medium, accessed February 5, 2026, https://medium.com/@CryptoSavingExpert/tornado-cash-suffers-several-setbacks-as-infura-alchemy-circle-github-comply-with-sanctions-2e63f4d525bf

33. OFAC sanctions on a cryptocurrency protocol: What does that mean for Web3?, accessed February 5, 2026, https://www.weforum.org/stories/2022/10/cryptocurrency-regulation-sanctions-web3/

34. ConsenSys Wants Your IP Address, Crypto Wallet, Bank Account - Blockworks, accessed February 5, 2026, https://blockworks.co/news/consensys-wants-your-ip-address-crypto-wallet-bank-account

35. Blockchain RPC Provider That Won't Track You: Case of GetBlock, accessed February 5, 2026, https://getblock.medium.com/blockchain-rpc-provider-that-wont-track-you-case-of-getblock-6089028a423c

36. Introduction to the Decentralized Infrastructure Network (DIN) - Simply Staking, accessed February 5, 2026, https://simplystaking.com/introduction-to-the-decentralized-infrastructure-network-din

37. High‑Performance EVM Layer‑1 for Scalable DeFi - Infura, accessed February 5, 2026, https://www.infura.io/networks/monad

38. Best Pocket Network (POKT) Alternatives & Competitors - SourceForge, accessed February 5, 2026, https://sourceforge.net/software/product/Pocket-Network-POKT/alternatives

39. Building Helios: Fully trustless access to Ethereum - a16z crypto, accessed February 5, 2026, https://a16zcrypto.com/posts/article/building-helios-ethereum-light-client/

40. Ethereum may finally kill “trust me” wallets in 2026, and Vitalik says the fix is already shipping - CryptoSlate, accessed February 5, 2026, https://cryptoslate.com/ethereum-may-finally-kill-trust-me-wallets-in-2026-and-vitalik-says-the-fix-is-already-shipping/

41. Connect to a Website or App - Rainbow Wallet, accessed February 5, 2026, https://rainbow.me/support/app/connect-to-a-website-or-app

42. State of light clients, and how Portal can help, accessed February 5, 2026, https://blog.ethportal.net/posts/light-clients

43. Lantern: A Light Client For Ethereum | by Pier Two | August 2024 | Medium, accessed February 5, 2026, https://medium.com/pier-two/lantern-a-light-client-for-ethereum-8094ddf89492

44. The TheGraph Protocol more technically explained | Medium - Yves Boutellier, accessed February 5, 2026, https://yvesboutellier.medium.com/thegraph-more-technically-explained-9a7fa64ab6dc?source=user_profile---------0----------------------------

45. About The Graph | Docs, accessed February 5, 2026, https://thegraph.com/docs/en/about/

46. Cloudflare's public IPFS gateways and supporting Interplanetary Shipyard, accessed February 5, 2026, https://blog.cloudflare.com/cloudflares-public-ipfs-gateways-and-supporting-interplanetary-shipyard/

47. Public Gateways vs. Dedicated Gateways - Pinata Help Center, accessed February 5, 2026, https://knowledge.pinata.cloud/en/articles/6297294-public-gateways-vs-dedicated-gateways

48. The Difference Between a Public IPFS Gateway and a Dedicated Gateway? - Pinata, accessed February 5, 2026, https://pinata.cloud/blog/whats-the-difference-between-a-public-ipfs-gateway-and-a-dedicated-gateway/

49. MetaMask Developer - Extend MetaMask by building Snaps, accessed February 5, 2026, https://metamask.io/developer/snaps

50. Reimagining self custody - MetaMask, accessed February 5, 2026, https://metamask.io/news/metamask-roadmap-2025

51. Data APIs Overview | Alchemy Docs, accessed February 5, 2026, https://www.alchemy.com/docs/data