The Role of RPC Providers

A wallet needs to read chain data and broadcast transactions. Almost none of them run a node to do it. They query an endpoint operated by a provider.

What the provider sees

Every address your wallet queries. Which is every address you hold, continuously, as the wallet refreshes balances.

Your IP address, and therefore approximate location.

Every transaction you broadcast, before it reaches the public network.

Which applications you interact with, from the contract calls you make.

That is a comprehensive picture of your activity, held by a company you have no relationship with and probably cannot name.

Why this arrangement exists

Running a node is work. Wallet developers want their software to function on installation, on a phone, without a multi-hundred-gigabyte sync.

Providers solve that, at scale, reliably. The trade is invisible to almost every user.

The concentration

A small number of providers serve a large share of wallet traffic across major networks.

That creates three exposures.

Privacy. Discussed above.

Availability. Provider outages have made large numbers of wallets appear broken simultaneously, while the underlying networks were operating normally.

Censorship. A provider can decline to relay particular transactions. This has occurred in response to sanctions requirements, and the transaction remains broadcastable through other routes.

What can be done

Point your wallet at your own node. The complete answer, and it requires running one.

Use a different provider, which changes who sees your activity rather than whether anyone does.

Use a wallet that supports multiple endpoints and rotates between them.

Broadcast through a different route than you query with, which separates the read and write exposure.

The honest assessment

For most users, the practical risk from an RPC provider is low. They are not the entity that can take your funds, and their commercial interest is in serving queries rather than in exploiting them.

The privacy cost is real and continuous, and almost nobody has decided to accept it, because almost nobody knows the arrangement exists.

The verification point

A wallet querying a provider is trusting the answer. Balances, transaction status and contract reads all come from a party you did not verify.

A light client checks proofs against block headers rather than trusting the response, which is strictly better and is not widely deployed in consumer wallets.

Running your own node removes the question entirely for self-custodied holdings. The working balance at exchanges that let you specify the network is a different arrangement where the venue is a known counterparty by design, which is a more honest form of trust than an unexamined one.