Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
security-post-mortems-hacks-and-exploits
Blog

Why RPC Censorship Is an Existential Attack Vector

An analysis of how compliant RPC providers, like Alchemy and Infura, can silently filter transactions, breaking dApp functionality and violating the foundational promise of permissionless blockchains. This is not a bug; it's a systemic risk.

introduction
THE ATTACK VECTOR

Introduction

RPC censorship is a systemic risk that undermines blockchain neutrality by allowing centralized infrastructure providers to filter transactions.

RPC censorship is a systemic risk that undermines blockchain neutrality by allowing centralized infrastructure providers to filter transactions. This creates a single point of failure, turning a decentralized ledger into a permissioned database controlled by the RPC endpoint.

The attack is existential because it targets the user's initial connection to the chain. Unlike miner/validator-level censorship, which is visible on-chain, RPC filtering is opaque and occurs before a transaction is ever broadcast, making it difficult to detect or quantify.

Infura and Alchemy dominate the market, processing the majority of Ethereum RPC requests. Their compliance with OFAC sanctions, which began filtering Tornado Cash transactions, demonstrated the centralized choke point in practice, forcing protocols like MetaMask to scramble for compliant alternatives.

Evidence: Over 60% of Ethereum's RPC traffic flows through Infura or Alchemy. When Infura's API keys were temporarily revoked for dApps like Uniswap, it caused immediate, widespread service outages, proving the fragility of this dependency.

deep-dive
THE INFRASTRUCTURE ATTACK

Anatomy of a Silent Kill: How RPC Censorship Works

RPC censorship is a protocol-level denial-of-service that exploits centralized infrastructure dependencies.

RPC endpoints are centralized chokepoints. A single provider like Infura or Alchemy can filter transactions based on OFAC lists, silently dropping them before they reach the public mempool. This is not a consensus-layer attack; it is a pre-consensus blacklist enforced by infrastructure.

The attack is invisible to users. A wallet shows a successful transaction broadcast, but the RPC node never relays it. The user experiences a silent failure, blaming network congestion or gas fees while their intent is censored at the gateway. This breaks the core UX promise of permissionless access.

Decentralized alternatives are non-trivial. Running a personal Geth node is the textbook solution, but hardware and sync-time costs are prohibitive for most. Light clients and services like POKT Network or Eden Network offer resilience but require explicit integration, creating fragmentation.

Evidence: After the 2022 OFAC sanctions, >50% of Ethereum blocks were built by OFAC-compliant validators, a direct result of RPC-level filtering propagating to the chain tip. This proves infrastructure centralization dictates chain-level outcomes.

EXISTENTIAL ATTACK VECTOR

RPC Market Share & Censorship Risk Matrix

Comparative analysis of leading RPC providers based on market share, censorship resistance, and decentralization metrics. Centralized RPC is a single point of failure for user access and transaction ordering.

Metric / FeatureInfura (Consensys)AlchemyPublic RPC EndpointsDecentralized RPC (e.g., Pocket, Ankr)

Estimated EVM Mainnet Market Share

40%

30%

<10%

<5%

Censorship of OFAC-sanctioned addresses

Requires API Key / Centralized Auth

Single-Entity Infrastructure Control

Geographic / Jurisdictional Risk

High (US)

High (US)

Low

Low

Supports MEV-Boost & MEV-Share Relays

Default Transaction Privacy (e.g., Flashbots)

Node Operator Decentralization (Est. Count)

1

1

1000s

10,000s

case-study
EXISTENTIAL ATTACK VECTORS

Case Studies: Censorship in Action

Censorship isn't hypothetical; it's a deployed tactic that threatens finality, neutrality, and billions in value.

01

The Tornado Cash OFAC Sanctions

The canonical case. In August 2022, OFAC sanctioned Tornado Cash smart contracts, forcing centralized RPC providers like Infura and Alchemy to censor related transactions. This created a two-tiered Ethereum, where compliant nodes filtered blocks, directly violating the network's credibly neutral base layer.

  • Impact: Broke the core promise of permissionless access.
  • Result: Spawned the MEV-Boost Relay censorship crisis, with relays filtering ~70% of blocks at its peak.
~70%
Blocks Censored
$10B+
Protocols at Risk
02

MEV-Boost Relay Centralization

Post-Merge, validators outsourced block building to a handful of MEV-Boost Relays. When OFAC pressure hit, major relays like Flashbots began censoring transactions. This created a systemic risk where proposer-builder separation (PBS) became a censorship vector.

  • Mechanism: Relays filtered OFAC-sanctioned addresses from blocks they built.
  • Solution Push: Drove adoption of censorship-resistant relays (e.g., Ultra Sound, Agnostic) and in-protocol PBS research.
5
Dominant Relays
33%
Validator Threshold
03

The Infura Arbitrum Outage

In 2022, Infura's misconfigured geo-blocking filter inadvertently blocked access to the entire Arbitrum network for users in certain regions. This wasn't malicious intent but demonstrated the single point of failure risk when dApps rely on a monolithic RPC provider.

  • Revealed: Infrastructure fragility and the non-sovereignty of users.
  • Catalyst: Accelerated demand for decentralized RPC networks like Pocket Network and Chainscore's own distributed gateway.
100%
Network Downtime
1
Single Point of Failure
04

Solana RPC Node Censorship

High-performance chains face unique risks. On Solana, the economic model led to RPC node centralization among a few entities. During peak congestion (e.g., NFT mints), these nodes could prioritize or deprioritize transactions based on fee bids or origin, creating a de facto censorship layer.

  • Problem: RPCs act as the gatekeeper to the mempool.
  • Architectural Flaw: Highlights the need for decentralized RPC layers and local client advocacy, even in high-throughput environments.
~5
Major RPC Providers
~400ms
Censorship Latency
counter-argument
THE REGULATORY REALITY

The Steelman: "But Compliance Is Necessary"

Acknowledging the legitimate regulatory pressure on RPC providers before dismantling the argument that censorship is a viable solution.

Compliance is a legal reality for centralized RPC providers like Infura and Alchemy. They face legitimate pressure from OFAC and other regulators to filter transactions from sanctioned addresses. This creates a direct conflict between legal survival and network neutrality.

Censorship is not compliance; it is a systemic failure. The correct response is client-level filtering, where individual users or applications apply their own compliance rules. The network's base layer must remain permissionless and neutral, as enforced by core clients like Geth and Erigon.

The existential attack vector is the centralization of this filtering power. When a few RPC endpoints become the de facto arbiters of valid state, they create a single point of failure and control. This undermines the credible neutrality that makes Ethereum a global settlement layer.

Evidence: The 2022 Tornado Cash sanctions demonstrated this flaw. Infura and Alchemy complied with OFAC by censoring transactions, but client diversity and services like Flashbots Protect provided alternative, uncensored paths, proving the system's resilience hinges on optionality, not mandated filtering.

protocol-spotlight
RPC CENSORSHIP IS AN EXISTENTIAL ATTACK VECTOR

The Antidote: Decentralized RPC Protocols

Centralized RPC endpoints are a single point of failure, enabling network-level censorship and threatening the foundational neutrality of blockchains.

01

The Single Point of Failure

Centralized RPC providers like Infura and Alchemy control access for ~80% of Ethereum traffic. This creates a critical chokepoint for censorship, as seen when they blocked Iranian users or specific wallet addresses.\n- Network-Level Blacklisting: A single provider can deny access to entire protocols or regions.\n- Protocol Risk: DApps built on a single endpoint inherit its failure and compliance risks.

~80%
Traffic Controlled
1
Chokepoint
02

The Decentralized Mesh

Protocols like POKT Network and Lava Network replace monolithic providers with a permissionless network of independent node operators. This creates a censorship-resistant mesh where requests are routed across a global pool of nodes.\n- Sybil-Resistant: Operators stake native tokens, aligning incentives for liveness and correctness.\n- Redundancy: No single operator can block or filter traffic, ensuring protocol neutrality.

30k+
Node Operators
100%
Uptime SLA
03

The Economic & Performance Flywheel

Decentralized RPCs aren't just about censorship resistance; they create a competitive market for performance. Operators compete on latency, geographic coverage, and reliability to earn rewards.\n- Cost Efficiency: Market dynamics drive down costs versus centralized premium APIs.\n- Performance Optimization: Latency-sensitive applications can route to the fastest, nearest nodes automatically.

<100ms
P95 Latency
-70%
vs. Enterprise API Cost
04

The Sovereign Stack

For protocols and DAOs, decentralized RPC is infrastructure sovereignty. It eliminates dependency on corporate entities whose interests may diverge from the chain's ethos, as seen with Tornado Cash sanctions.\n- Self-Hosted Gateways: DAOs can run their own gateway nodes, guaranteeing uncensorable access for their community.\n- Multi-Chain Abstraction: Networks like Lava provide unified access to Ethereum, Cosmos, Solana, reducing integration complexity.

0
Third-Party Risk
10+
Chains Supported
future-outlook
THE ATTACK VECTOR

Future Outlook: The Inevitable Fracturing

RPC censorship is not a bug but a systemic attack vector that will fracture the unified state of blockchains.

Censorship is a wedge that exploits the centralized choke point of RPC providers. A single entity like Infura or Alchemy can unilaterally filter transactions, creating divergent chain states for compliant and non-compliant users. This directly violates the core property of state finality.

The response is fragmentation. Protocols will hard-fork their dependency graphs, creating parallel infrastructure stacks. Projects like Pocket Network and decentralized RPC pools will serve uncensored access, while others remain with compliant providers. This creates a bifurcated user experience.

This is a protocol-level failure. The reliance on trusted third parties for core data access is an architectural flaw. The long-term fix is integrating lightweight clients and zk-proof-based state verification, moving the trust boundary from the RPC to the cryptographic proof.

Evidence: The Tornado Cash sanctions demonstrated this vector. Infura and Alchemy complied, blocking access. User activity immediately shifted to alternative endpoints and personal nodes, proving the network's resilience and the immediate demand for uncensored access.

takeaways
RPC CENSORSHIP

TL;DR: Key Takeaways for Builders

Centralized RPC endpoints are a single point of failure that can be weaponized to censor or reorder transactions, threatening protocol neutrality and user sovereignty.

01

The Problem: Single-Point-of-Failure Architecture

Relying on a single provider like Infura or Alchemy creates a centralized kill switch. A government order or corporate policy change can censor entire wallets or dApps, breaking core Web3 guarantees.

  • Risk: A single entity can blacklist addresses or filter transactions.
  • Impact: $10B+ TVL in DeFi protocols is exposed to this vector.
  • Example: The 2022 OFAC sanctions on Tornado Cash demonstrated this vulnerability.
1
Kill Switch
100%
Exposure
02

The Solution: Decentralized RPC Networks

Distribute RPC requests across a permissionless network of node operators. Projects like POKT Network and Lava Network use cryptoeconomic incentives to ensure liveness and neutrality.

  • Key Benefit: Censorship resistance via geographic and political distribution.
  • Key Benefit: Improved reliability and uptime through redundancy.
  • Trade-off: Slightly higher latency (~50-100ms) vs. centralized giants.
1000+
Nodes
99.9%
Uptime
03

The Hedge: Client Diversity & Self-Hosting

The ultimate defense is reducing dependency on third-party RPCs. Teams should run their own nodes or use lightweight clients. Ethereum's Erigon and Reth are built for this.

  • Action: Run a full node for critical infrastructure and fallback.
  • Action: Implement RPC failover logic in your application layer.
  • Reality Check: Requires ~2TB SSD and ongoing DevOps overhead.
2TB
Storage Needed
0
Third Parties
04

The Meta-Solution: Intent-Based Abstraction

Move beyond simple transaction broadcasting. Let users express what they want (e.g., "swap X for Y"), not how to do it. Systems like UniswapX, CowSwap, and Across use solvers that are RPC-agnostic.

  • Key Benefit: User transactions become unstoppable; solvers find any path.
  • Key Benefit: Better execution via MEV protection and optimized routing.
  • Future: This pattern, championed by Anoma, makes the RPC layer less critical.
0
RPC Reliance
100%
Fill Rate
ENQUIRY

Get In Touch
today.

Our experts will offer a free quote and a 30min call to discuss your project.

NDA Protected
24h Response
Directly to Engineering Team
10+
Protocols Shipped
$20M+
TVL Overall
NDA Protected Directly to Engineering Team