Centralized RPC Providers Can Track Your IP, Filter Transactions, And Log User Behavior—The Decentralized Ledger Doesn't Matter If The Access Layer Is Compromised

As a security researcher who’s spent the last year analyzing Web3 infrastructure vulnerabilities, I need to talk about something that keeps me up at night: the surveillance and censorship risks created by our dependence on centralized RPC providers.

We’ve built this beautiful censorship-resistant, decentralized blockchain—and then we route nearly all access through a handful of companies that can see everything you do.

What RPC Providers Can Actually See

Let me be specific about what centralized RPC providers can monitor:

  • Your IP address on every single request
  • Every wallet address you query (which reveals your personal addresses)
  • Your transaction patterns and timing (what you’re doing and when)
  • What dApps you’re using (inferrable from contract queries)
  • Your entire interaction pattern with the blockchain

Even with HTTPS encryption, the RPC provider sees the wallet addresses in your requests. It’s similar to using a VPN provider—they claim not to log, but you’re fundamentally trusting them with your activity data.

The Censorship Vectors Are Real

This isn’t theoretical. We’ve already seen:

  • Infura blocking Tornado Cash addresses in 2022 (later reversed after community backlash)
  • Geo-blocking certain countries based on compliance requirements
  • Potential government pressure to censor or monitor specific addresses

The technical censorship capabilities include:

  1. Transaction filtering before submission to mempool
  2. Selective degradation (certain addresses get slower service)
  3. Data harvesting for surveillance purposes
  4. Forced KYC requirements for API access

The Uncomfortable Irony

We spent years building a censorship-resistant blockchain, then routed all practical access through censorable gatekeepers.

The blockchain itself might be unstoppable, but if users can’t submit transactions or read state without going through a provider that can block them, the censorship-resistance becomes theoretical.

Enterprise & Nation-State Risks

Two scenarios worry me:

Corporate surveillance: RPC providers could sell aggregated usage data to hedge funds, analytics firms, or surveillance companies. The data is incredibly valuable—imagine knowing which wallets are querying specific contracts before major price movements.

Government subpoenas: Nation-states can compel RPC providers to hand over user data or implement filtering. If the U.S. government wanted to sanction specific addresses, pressuring Alchemy and Infura would be far easier than attacking the blockchain itself.

What Can We Do About It?

The solutions exist but aren’t yet mainstream:

Run your own node - Eliminates trust, but we’ve discussed the K/month cost barriers

Use VPN + multiple RPC providers - Reduces correlation risk, doesn’t eliminate it

Light clients in browser - Trustless but still immature for production use

Privacy-preserving RPC protocols - Active research area, using techniques like onion routing

Decentralized RPC networks - dRPC, Pocket, Lava eliminate single point of control

The long-term solution is light clients running directly in browsers and wallets, eliminating the need to trust any RPC provider. But until we get there, we need to take privacy seriously at the infrastructure layer.

Call To Action

We need:

  • Privacy-first RPC providers that don’t log (similar to privacy-focused VPN services)
  • Industry standards for data minimization and retention policies
  • Transparency requirements - what data do providers actually collect?
  • User education - most people don’t realize their RPC provider sees everything

Has anyone here actually read Alchemy or Infura’s privacy policies? Do we know what they’re logging?

TL;DR: Decentralized ledgers don’t matter if the access layer is compromised. RPC centralization creates surveillance and censorship risks that undermine Web3’s core values. We need better solutions before this becomes a serious problem.

You’re absolutely right to sound the alarm on this. The privacy and censorship risks are severely underrated by most of the Web3 community.

Privacy Tech Solutions In Development

The good news is there are technical solutions being worked on:

Light clients eliminate the need to trust RPC providers for state reads entirely. You verify the consensus yourself, so the provider can’t lie to you or censor what you see.

Privacy-preserving request routing - Similar to Tor, we could route RPC requests through multiple hops so no single provider sees both your IP and your query content.

Local validation of RPC responses - Even when using centralized RPC, clients could validate responses against consensus proofs, eliminating trust in data integrity (though not metadata privacy).

My Personal Setup

I take this seriously enough that I:

  • Route all my development traffic through Tor
  • Rotate between 4-5 different RPC providers
  • Run my own nodes for sensitive operations
  • Never use API keys tied to my real identity

Is it overkill? Maybe. But I won’t depend on centralized providers to be good stewards of my privacy.

The Real Long-Term Solution

Stateless Ethereum clients and the Portal Network are the real answers. Once every browser and wallet can run a light client that verifies consensus without trusting anyone, this whole problem evaporates.

But realistically we’re 2-3 years away from that being production-ready. Until then:

We need privacy-first RPC services - providers that commit to not logging, regularly audit their infrastructure, and have transparent data policies. Think of it as the ProtonMail or Mullvad VPN of blockchain access.

The technology exists. We just need the will to build it and the community education to demand it.

Okay I’ll be honest - I haven’t thought much about this and after reading your post, I probably should have.

My startup uses Alchemy’s free tier and I’ve never once considered what they can see. Your post is a bit of a wake-up call.

The Pragmatic Take

But let me offer the business realist perspective: For most consumer dApps, is this risk actually meaningful to users?

People use Gmail even though Google reads their emails to serve ads. They use Google Search knowing their queries are tracked. They use social media despite comprehensive surveillance.

The average DeFi user - do they actually care if Alchemy knows they’re checking their ENS balance? Or is this more of a concern for the ideological Web3 builders than the actual end users?

What Actually Worries Me

That said, here’s what DOES scare me from a business perspective:

If Alchemy bans our API key, our app goes down immediately. That’s a single point of failure I don’t love.

After this thread, I’m definitely going to:

  1. Set up a backup RPC provider (probably Infura as fallback to Alchemy)
  2. Actually read their terms of service to understand ban scenarios
  3. Think about privacy policy disclosures

The Regulatory Risk

The real nightmare scenario isn’t voluntary surveillance - it’s mandatory KYC requirements for RPC providers.

If regulations force Alchemy/Infura to collect KYC on API users, that would be devastating for permissionless access. Suddenly you need to give your identity to a company just to read public blockchain data.

That’s the scenario that could genuinely break Web3’s open access model.

Question For The Group

What percentage of actual users care about RPC-level privacy versus what percentage of builders care?

Because if users don’t care, the market won’t reward privacy-focused solutions, and we’ll stay centralized by default.

Coming from a data engineering background, I’m very aware of what can be inferred from access patterns and metadata. This is a legitimate concern.

What RPC Logs Reveal

Even if the RPC provider promises not to look at your data, the logs are incredibly valuable:

  • MEV detection: See which wallets are querying specific contracts right before large trades
  • Competitive intelligence: Understand which dApps are gaining/losing usage
  • Trading signals: Correlate query patterns with price movements
  • Wallet clustering: Link multiple addresses to same user based on query timing/patterns

A sophisticated analytics team could extract massive value from RPC provider logs. That creates obvious incentives for data harvesting.

Who Has Access?

The questions I’d want answered:

  1. What exactly do Alchemy/Infura log? (Full requests? Just metadata? How long retained?)
  2. Who has access internally? (Engineers? Data scientists? Executives?)
  3. What’s sold/shared? (Aggregated analytics? Individual-level data? Third parties?)
  4. What’s the legal framework? (Can they be subpoenaed? By what jurisdictions?)

My Company’s Approach

We run analytics infrastructure, so we’re on the other side of this. Our policy:

  • Don’t log user IPs unless absolutely necessary for rate limiting
  • Aggregate everything before analysis (k-anonymity)
  • Delete raw logs after 7 days
  • No data sales to third parties

But I have no idea if major RPC providers follow similar principles. The lack of transparency is concerning.

Industry Standards Needed

We need something like:

  • Privacy certifications for RPC providers (audited data policies)
  • Data minimization requirements (collect only what’s operationally necessary)
  • Retention limits (automatic deletion of old logs)
  • User controls (opt-out of logging, data export rights)

At minimum this should be opt-in with informed consent, not a hidden surprise in a privacy policy nobody reads.

This thread is making me realize I’ve been way too naive about privacy in my dApp development.

User Expectations vs. Reality

Here’s what worries me: Most end users think blockchain is private/anonymous. They’ve heard about Bitcoin being used on dark web markets and assume crypto = privacy.

The reality that their RPC provider can see every wallet they check, every transaction they submit, and correlate it with their IP address would shock most users.

My Ethical Responsibility

As a developer, I feel like I have an obligation to:

  1. Disclose this in my privacy policy - “We use Alchemy to connect to Ethereum, and they can see your requests”
  2. Offer privacy-preserving options - Let users provide their own RPC endpoint if they want
  3. Support multiple providers - Don’t lock users into a single surveillance point

After this discussion, I’m going to update my app’s privacy policy this week.

The Accessibility Problem

But here’s the tension: The solutions are too technical for average users.

“Run your own node” - 99% of users can’t/won’t do that.
“Use Tor” - Most people don’t know what that is.
“Configure custom RPC” - Confusing and intimidating.

We need privacy by default, not privacy as an expert-level opt-in.

What Could Actually Work?

MetaMask could integrate a light client and make it the default. Then users get privacy without even knowing they’re doing anything special.

Similar to how browsers made HTTPS automatic - users don’t need to understand certificate chains, it just works.

We figured out usable privacy for the web. We can figure it out for Web3 too.

But until then, I think developers have a responsibility to be transparent about the tradeoffs we’re making on our users’ behalf.