Refreshing a wallet can expose an address query to the service supplying chain data without creating a new payment. The RPC endpoint receives the requests directed to it; the connection information it sees depends on whether the wallet connects directly or through other infrastructure. Public blockchain data, request metadata and spending keys are different layers. Self-custody alone does not answer who sees your balance lookups.
Start with the request, not the signing device
Ethereum's JSON-RPC reference describes eth_getBalance as a query that includes the address whose balance is requested. The endpoint needs that address to answer that request. Reading a balance through this method is different from submitting a signed transaction. It also does not prove that the person making the query owns the address.
A wallet may request data for several purposes: balances, transaction history, token detection, simulations or other features. Do not assume they all use one backend. A configured RPC can be only part of the application's network activity. An indexer, security service or profile system can have its own request path and policy.
A hardware signing device does not automatically remove those network requests from the companion software. Keeping keys on a device protects a different boundary from deciding which server supplies public chain data. Likewise, a watch-only address can still be queried without authority to spend. Inspect the data path rather than infer it from the wallet's security label.
Map each observer to a particular event
| Event or layer | Possible observer | What should not be assumed |
|---|---|---|
| Address-bearing RPC lookup | The endpoint handling that request | That it received a private key |
| Direct network connection | The receiving infrastructure | That the observed address always identifies one human |
| Request forwarded through a proxy | The participating proxy and endpoint, with different views | That both necessarily see identical device details |
| Optional balance or security feature | The service implementing that feature | That changing RPC removes every other connection |
| Public ledger transfer | Anyone reading the public chain | That the ledger records who later queried it |
| Local signing | The relevant wallet or signing device | That local key custody prevents all metadata disclosure |
| A provider's privacy statement | The provider's stated handling policy | That technical visibility proves a particular retention period |
Some observed metadata can be shared by many users, while an address lookup can concern a recipient or a contract rather than the caller's own wallet. These limits matter when interpreting logs. A provider's ability to observe a request is not proof of a named owner's identity, a complete wallet inventory or an actual payment.
Read current product settings rather than old headlines
MetaMask's network-connection explanation describes the role of an RPC endpoint and the ability to choose a connection. That explains a network-data relationship, not every feature's data collection. A custom endpoint should be evaluated on its own operation, policy and correctness.
The current Basic Functionality explanation describes profile-linked features and distinguishes them from optional Metrics. It also describes a reduced mode that retains the configured RPC connection. That is a useful example of why disabling analytics and eliminating all address-related requests are different objectives. Account types and settings can differ, so check the current controls for your installation.
MetaMask's Privacy Notice describes temporary IP processing for certain offerings and proxying of some third-party requests, depending on settings. These are the company's stated practices, not an independent audit. Do not substitute a years-old retention headline or assume the same policy applies to a separately chosen provider.
A different connection path changes the trust picture
With a direct connection, the endpoint can see the network source of that connection. A proxy can alter what the final endpoint receives while becoming another participant in the path. Encryption protects communication against some observers but does not make the receiving server unable to read the request it must answer. Keep transport and endpoint handling separate in your notes.
A VPN can similarly change the address seen by a destination while introducing another provider. That does not remove the queried wallet address from an address-bearing request. Operating your own node changes dependence on a third-party RPC, but does not automatically remove other wallet services or public chain visibility. These are trade-offs to evaluate, not universal privacy switches.
A custom RPC is also a source of information your wallet uses. Verify the actual network and official connection details before selecting an unfamiliar endpoint. Do not choose it solely because someone advertises no logging. If a provider does not explain retention or shared infrastructure, write unknown rather than converting silence into a promise of immediate deletion.
Keep a small connection inventory
- Identify the wallet application, network and currently selected RPC endpoint.
- List any separate token-detection, profile, simulation, analytics or other enabled services described by that wallet.
- Read each relevant provider's current policy and distinguish observation, processing and storage claims.
- Determine whether the request path is direct or mediated where the product documents it.
- Review the function and security protections you would lose before disabling a feature.
- After a deliberate change, verify the selected network and normal balance display without signing an unrelated transaction.
For a fictional example, Wallet Birch reads a balance from Endpoint A while a separate protection feature uses Service B. Replacing A with C changes one relationship. It does not establish that B stopped receiving its own requests or that A removed earlier records. The useful inventory records both relationships and the reason for changing either, instead of one broad privacy enabled checkbox.
If you ask support about that setup, start with public configuration details and a description of the behavior. Do not send an API credential embedded in a private endpoint URL or a wallet recovery phrase. A screenshot can also contain account labels and other unrelated details. Keep the question focused on which feature contacts which service and what the documentation actually says.
For the custody distinction, read custodial versus non-custodial wallets; for signing hardware, see hardware versus software wallets. A no-account swap is a separate service interaction with its own AML policy. Choosing a particular wallet RPC does not change that order's review conditions or provide a promise that no data exists elsewhere.
FAQ
What should I read in a wallet privacy policy about RPC requests?
Look for the services handling address queries, connection information and any stated retention. Distinguish the provider's policy from technical visibility and from your wallet's other enabled features.
Does changing the MetaMask RPC endpoint remove every wallet connection?
It changes the selected endpoint relationship, but other enabled services can have separate connections. Check the current feature settings and their documented behavior.
Is a wallet balance request the same as a transaction?
A balance lookup is a read request and can occur without a new payment or spending signature. It can still carry an address to the endpoint answering it.