Private RPC for multi-wallet setups: the leak nobody checks

Your wallet doesn’t talk to the blockchain directly. It talks to a server, and that server sees more about you than almost anything else in your setup. Every time you open a wallet, it quietly asks an RPC endpoint what your balance is, what a contract holds, and what happened in the last block. When you send a transaction, it hands that transaction to the same server to broadcast. If every wallet you run points at the same default endpoint over the same connection, one company is watching all of them read and write, side by side. That’s the quiet privacy hole almost nobody configures, and it can link wallets long before anyone opens a block explorer.

What an RPC endpoint actually is

RPC stands for remote procedure call, and in practice it’s just a URL your wallet sends requests to. It’s the door between your wallet software and a full node holding a copy of the chain. Your wallet can’t store the whole chain itself, so it asks a node: is this address funded, what does this contract return, please broadcast this signed transaction. The node answers. Someone runs that node, and whoever runs it sees every question you ask. This is normal and necessary. The question is who that someone is, and how many of your wallets share them.

The default that ships with your wallet

Most wallets ship with a default endpoint already filled in, run by whatever infrastructure provider the wallet chose. You never picked it, and most people never change it. Out of the box, a huge share of wallets on a given network are funneling their reads and writes through a small handful of large providers. It’s convenient, it works instantly, and it quietly means your activity is visible to a company you never chose and can’t see. None of that is malicious. It’s just the default, and defaults are where privacy quietly leaks.

What the provider can see

A node provider sees the requests, and the requests are revealing. It sees which addresses your wallet asks about, which usually means the addresses you own or care about. It sees the transactions you submit before they’re even public. And crucially, it sees the network connection those requests came from, which carries your IP address unless something in between hides it. Put together, the provider can associate a set of wallet addresses with one origin. That’s not a block explorer view everyone shares. That’s a private view tied to your connection.

Why one endpoint links many wallets

Here’s where it matters for anyone running more than one wallet for legitimate reasons. If wallet one and wallet two both use the same default endpoint from the same home connection, the provider sees both sets of addresses arriving from the same origin, often in the same session. On a public ledger the two wallets might look unrelated. At the RPC layer they’re obviously handled by one person on one connection. The chain didn’t link them. The shared infrastructure did, at a layer most people never think to separate.

The IP address angle

The IP address is the thread that ties it together. Two wallets querying from two different countries look like two different people to a provider. Two wallets querying from one address, one after another, look like one operator. This is exactly why proxy and browser isolation matters here too. Isolating the browser while every wallet still calls the same node from the same raw connection leaves the network origin fully exposed. The layers have to be consistent, and the RPC call is one of the easiest layers to forget.

This isn’t a hypothetical concern

It’s worth being concrete here. Back in 2022, a widely used default provider updated its policy to disclose that it collected IP addresses alongside wallet addresses for requests routed through it. The point isn’t to single out one company, and this is a matter of public record, not an accusation. The point is that request logging is ordinary infrastructure practice, the data genuinely exists, and treating your RPC endpoint as a neutral pipe rather than an observer is a mistake the industry itself has already flagged out loud.

Reading versus broadcasting

There are two kinds of exposure, and they aren’t equal. Reading is asking about balances and contract state, and it happens constantly in the background. Broadcasting is handing over a signed transaction to be sent to the network. Broadcasting is the sharper one, because that provider sees your transaction first, before the rest of the network, tied to your origin. Some setups read from one place and broadcast through another for exactly this reason. Knowing the two are different is the first step to controlling each of them deliberately instead of leaking both by default.

Public endpoints from a list

One common move is to swap the default for a public endpoint pulled from a community list. This spreads your requests across more operators and off the single default, which is a mild improvement. The tradeoff is real though. Public endpoints can be slow, rate limited, unreliable, or run by parties you know even less about. You’re trading a known observer for an unknown one. It’s a step, not a solution, and it should be treated as one small adjustment rather than a fix that suddenly makes your traffic private.

Running your own node

The honest gold standard is running your own node. When your wallet talks to a node you control, there’s no third party in the middle logging your reads and broadcasts. The requests never leave your own machine before hitting the network. The cost is equally honest. A node takes disk space, bandwidth, sync time, and ongoing maintenance, and light clients only partially reduce that. For most individuals it’s more than they’ll take on. But if you’re serious and run many wallets, one self-hosted node quietly removes an entire category of leakage, and it’s the only option that truly does.

Rented private nodes

Between the public free tier and running your own, there’s the rented private node. Providers sell dedicated endpoints with a private key of their own, better reliability, and clearer terms. You’re still trusting a company, so this isn’t anonymity, but it can mean a defined relationship and better performance than a random public URL. The trap is thinking a paid private endpoint is private from the provider. It isn’t. It’s private from other users, not from the host. Read the wording carefully and know exactly which kind of private you’re actually buying.

Rotating providers across wallets

A practical middle path is to not put every wallet behind one endpoint. Different wallets can use different providers, so no single company sees the whole set from one origin. This doesn’t make any one wallet invisible to its provider, it just avoids handing a complete picture to a single one. Combined with a clean, separate network path per context, it meaningfully reduces how much any one observer can stitch together. It’s more effort than the default, and far less than a full node, which is exactly why it’s a reasonable place for many people to land.

Routing the connection itself

Separating who runs the node is only half of it. The other half is the connection the request rides on. Sending RPC traffic through a proxy or VPN changes the origin the provider records, so the IP tied to your requests isn’t your raw home address. This is the same principle as the proxy layer for browsers, applied to the quieter wallet traffic underneath. It doesn’t hide the wallet addresses from the node, but it breaks the link between those addresses and your literal home connection, which is often the part that actually matters.

How to check what you’re on

None of this requires trust in a sales page, because you can just look. Open your wallet’s network settings and read the RPC URL it’s actually using. That one line tells you who your wallet has been talking to this whole time. If it’s a default you never chose, now you know. If several wallets all show the same URL, now you know they share an observer. This thirty second check is the single most useful thing in this entire breakdown, because you can’t fix a leak you’ve never actually looked at.

What a sensible setup looks like

A reasonable, boring setup does a few things at once. It moves off the untouched default, it avoids routing every wallet through one identical endpoint, it puts the connection behind a clean network path so the origin isn’t your raw address, and, for a serious operator, it leans toward a self-hosted or dedicated node for the wallets that matter most. No single trick here is magic. It’s layered, ordinary hygiene, applied to the one layer people forget exists.

Light clients and phone wallets

Phone wallets and browser extensions hide all of this behind a clean interface, which is convenient and also exactly the problem. The endpoint is buried in a settings menu most people never open, and the app quietly picks a default for you the first time it runs. On mobile especially, the same wallet app carrying several accounts will happily route every one of them through one built-in endpoint over your phone connection, so the provider sees the whole set arrive together. The fix is the same as everywhere else in this: open the network settings, read what it actually uses, and change it on purpose rather than leaving the factory choice. Convenience didn’t remove the leak here, it only hid it behind a nicer screen, and a menu you never opened is still a menu full of decisions someone else made for you.

The limit worth repeating

Fix all of this and you’ve closed a real leak, not made yourself invisible. The RPC layer is about who watches your requests and from where. It does nothing about the on-chain patterns, the funding, the timing, the reconvergence, that a public ledger shows to everyone equally. A private node over a mechanical, obviously coordinated set of transactions is still a coordinated set of transactions in plain public view. This is one clean layer in the stack. Treat it as necessary, never as sufficient, and never as a promise of anything.

The mistakes people make

The common failures are simple. Leaving the default in place and assuming it’s neutral. Paying for a private endpoint and believing it’s private from the host. Spreading across public endpoints and thinking that alone equals anonymity. Or fixing the RPC layer while broadcasting every transaction from one raw home connection. Each of these is a half step mistaken for a finished job. The fix in every case is to actually look at what your wallet is doing and make each layer a deliberate choice instead of an accident.

Nothing here is financial advice or a promise about any token or drop. For the tested picks and the fuller writeup of how the RPC layer fits under the rest of a multi-wallet setup, head to the airdropfarming.org homepage.

Get new guides and videos first — join the Telegram channel.