From security perspective: RPC providers are our biggest attack surface. 
The Threat Model
When you use Infura/Alchemy, you trust:
-
The company won’t get hacked
- They handle billions in transaction value
- Juicy target for attackers
- One breach = mass user compromise
-
Employees won’t go rogue
- 100+ employees with infrastructure access
- Any one could exfiltrate data
- Or modify responses maliciously
-
AWS won’t be compromised
- Most providers run on AWS
- AWS has root access to everything
- One AWS breach = multiple providers compromised
-
Government won’t force compliance
- OFAC, sanctions, censorship
- Providers are US-based (subject to US law)
- One order = ecosystem-wide censorship
This is HUGE trust assumption.
What RPC Providers CAN Do
1. Return fake data
Scenario:
- User queries: “What’s my balance?”
- Provider returns: “5 ETH” (actual: 10 ETH)
- User makes decision on fake data
- Gets rekt
Has this happened? Not publicly.
Could it? Absolutely.
Defense: Query multiple providers, compare results.
2. Front-run transactions
Scenario:
- User submits transaction to buy token
- Provider sees it in their servers
- Provider front-runs with own transaction
- Profits from user’s trade
Has this happened? Suspected but unproven.
Defense: Use private transaction services (Flashbots).
3. Censor transactions
Scenario:
- User submits transaction
- Provider never broadcasts it
- Transaction disappears
- User can’t interact with blockchain
Has this happened? Yes (Tornado Cash).
Defense: Use multiple providers or self-host.
4. Track and deanonymize
Scenario:
- Link IP to wallet address
- Build user profile over time
- Sell data to third parties
- Or comply with government requests
Has this happened? Almost certainly.
Defense: VPN, Tor, or self-host.
The March 2020 Incident
Infura consensus bug:
What happened:
- Infura’s Geth nodes fell out of sync
- Returned wrong blockchain data
- DeFi protocols made decisions on bad data
- Resulted in bad liquidations
Impact:
- Unknown but likely millions in losses
- Users blamed protocols, not Infura
- Showed single provider risk
This proves: Trusting one data source is dangerous.
The OFAC Compliance Scenario
What if US government mandates OFAC compliance?
Likely scenario:
- Treasury: All RPC providers must block sanctioned addresses
- Infura, Alchemy comply (US companies)
- BlockEden, QuickNode comply
- 92% of RPC traffic now filtered
Effect if your address is flagged:
- Can’t use MetaMask
- Can’t use 99% of dApps
- Banned from Ethereum
- No appeal process
This isn’t hypothetical.
Tornado Cash showed this can happen without laws - providers self-censored.
The Supply Chain Attack
How to compromise millions of users:
Attack Infura:
- Hack AWS account
- Access Infura servers
- Modify response data
- Steal private keys from transactions
Or:
- Social engineer Infura employee
- Get infrastructure access
- Inject malicious code
- Exfiltrate data
Or:
- Compromise npm package Infura uses
- Inject backdoor
- Deploy to production
- Own the infrastructure
One successful attack = 42% of ecosystem compromised.
What We Do for Our $500M TVL Protocol
Multi-provider verification for critical operations:
Before liquidation:
- Query 3 providers (Alchemy, BlockEden, self-hosted)
- Compare results
- Only proceed if 2/3 agree
- Alert if disagreement
Cost: 3x RPC costs for critical paths.
Worth it: Prevents catastrophic errors.
We’ve detected 3 incidents in 2024:
- One provider returned stale data
- Would have caused incorrect liquidation
- Multi-provider check caught it
The provider blamed “caching issues.”
But it was wrong data regardless.
The Data We Found
Random spot checks (10,000 samples):
Accuracy:
- 99.98% of queries return correct data
- 0.02% return wrong data (usually caching)
This sounds good, but:
- 0.02% of billions of queries = millions of wrong responses
- Wrong data during critical operation = disaster
- No way for user to detect without verification
The Monitoring We Built
Canary transactions:
Every hour:
- Send test transaction via provider
- Verify it appears on blockchain (via different provider)
- Confirm within 30 seconds
- Alert if missing
Found 8 cases in 2024 where transactions disappeared.
Providers blamed:
- “Network congestion”
- “Temporary issue”
- “Already resolved”
We suspect some were censorship attempts.
No way to prove it.
The Decentralization Paradox
Smart contracts: Decentralized
- Run on 100,000+ nodes
- No single point of control
- Censorship resistant
Access to contracts: Centralized
- 70% through 2 companies
- Easy to censor
- Easy to compromise
It’s like:
- Having decentralized gold vault (Fort Knox distributed globally)
- But one road to access it
- Road can be blocked anytime
The gold is secure but inaccessible.
What Actually Needs to Happen
1. Light clients everywhere (2-3 years)
Browsers run light clients:
- Direct blockchain access
- No RPC middleman
- Verify all data cryptographically
Projects: Helios, Lodestar
2. zk-Proofs for RPC responses (3-5 years)
Provider returns data + proof:
- Cryptographically prove correctness
- User verifies proof locally
- No trust needed
Status: Research phase
3. Decentralized RPC maturity (1-2 years)
Pocket, Lava networks mature:
- 99.9%+ reliability
- Competitive performance
- Economic sustainability
4. Multi-provider as standard (now)
Industry best practice:
- All dApps use 2+ providers
- Failover logic required
- Security audits check RPC resilience
For BlockEden
Security-first differentiation:
1. Zero-knowledge RPC
- Minimal logging (24 hour deletion)
- No IP linking to addresses
- Anonymous Tor access
- Privacy tier
2. Geographic redundancy
- Nodes in 5+ countries
- Multiple cloud providers
- Regulatory arbitrage
3. Transparent audits
- Publish infrastructure architecture
- Security practices documentation
- Incident post-mortems
- Third-party security audits
4. Censorship resistance policy
- Won’t censor unless legally required
- Publish if forced to censor
- 30-day migration notice
- Support user exit
5. Warrant canary
- Daily: “BlockEden has not received government requests as of DATE”
- If missing, users know something happened
This builds trust with security-conscious users.
The Bottom Line
RPC providers have power to:
- Censor your transactions
- Steal your data
- Return fake information
- Track all activity
We trust them because we have no choice.
This is unacceptable for “decentralized” Web3.
Solutions exist but adoption is low.
Until we fix this, Web3 is just renting decentralization from centralized providers.
Sophia
