A user connects MetaMask to what they believe is the Ethereum mainnet, approves a transaction worth $500, and clicks confirm. The transaction appears to process. But the wallet’s default Remote Procedure Call (RPC) endpoint—the server that broadcasts the transaction to the network—may not belong to the Ethereum network at all. It could be a third-party service, a node operated by a company the user has never heard of, or in some cases, a misconfigured endpoint that never confirms the transaction. This scenario is not hypothetical. It unfolds daily across millions of crypto wallet sessions, and most users never realize their transaction metadata, wallet balance queries, and account history have been routed through servers they did not explicitly choose and whose operators they do not know.
The problem begins with a design choice that prioritizes convenience over transparency. When a crypto wallet like MetaMask connects to a blockchain network, it must communicate through an RPC endpoint—essentially a server that receives wallet requests, queries the blockchain, and broadcasts transactions. MetaMask, Trust Wallet, Phantom, and most other non-custodial wallets do not operate their own network infrastructure at scale. Instead, they default to third-party RPC providers, and the wallet does not always make this relationship visible or offer simple configuration controls. For users who believe their non-custodial wallet means “I control everything,” the reality of silent endpoint switching and metadata leakage represents a significant blind spot in wallet security and privacy expectations.
How RPC endpoints work and why the default matters
An RPC endpoint is a server that implements the JSON-RPC protocol standard, allowing a client application—in this case, a crypto wallet—to request information and perform actions on a blockchain. When you open MetaMask and check your Ethereum balance, the wallet sends a request to an RPC endpoint asking for the balance of your address. When you approve a transaction, MetaMask serializes the transaction, signs it with your private key (which stays on your device), and sends the signed transaction to an RPC endpoint to be broadcast to the network.
The endpoint operator does not hold your private keys; that security boundary is intact. However, the endpoint operator learns your IP address, wallet address, account balance, transaction history from your perspective, which tokens you own, which dapps you interact with, and the timing and pattern of your activity. This metadata, when combined across multiple sessions and users, becomes valuable intelligence for building behavioral profiles, identifying high-value targets, and tracking fund flows. Ethereum’s protocol documentation specifies the RPC interface, but it does not mandate which endpoint you use or require wallets to disclose their default choices transparently.
MetaMask’s architecture uses Infura as its default RPC provider for Ethereum mainnet connections in many jurisdictions. Infura is owned by Consensys, a legitimate company in the blockchain ecosystem, but the point is that the wallet user did not explicitly authorize this choice. Phantom defaults to Helius for Solana. Trust Wallet uses a combination of internal nodes and third-party providers. Coinbase Wallet routes through Coinbase’s infrastructure. Each choice shifts the trust assumption: you are now assuming that the RPC provider will not misuse metadata, will remain operational, will not log transactions beyond what is necessary, and will not cooperate with surveillance without proper legal process.
The wallet security assumption that breaks silently
Most users understand a crypto wallet as a tool that keeps their private keys locally and never exposes them to external servers. That mental model is correct in isolation. But it coexists with an implicit second assumption: that the wallet communicates with “the blockchain,” as if that were a single, unambiguous server. In reality, every wallet user is picking a gateway, and that gateway operator has a front-row seat to account activity. The security of non-custodial wallet systems depends on more than cryptographic key management; it depends on endpoint privacy.
A compromised or malicious RPC endpoint can perform several attacks that a non-custodial wallet’s key management alone cannot prevent. A sybil attack can create fake responses to balance queries, showing inflated balances to encourage risky transactions. A man-in-the-middle endpoint can broadcast your transaction simultaneously to multiple networks or delay it indefinitely. An endpoint can refuse to relay your transaction while relaying competing transactions from the operator’s preferred counterparties, creating a form of transaction censorship. Most critically, an endpoint can correlate wallet addresses, transaction patterns, IP addresses, and timestamps to identify users at scale.
The user interface of most wallets does not convey this risk. MetaMask shows a simple network selector—Ethereum, Polygon, Arbitrum—with no indication of which RPC provider handles each network or any easy way to configure it. When you switch networks, you may unknowingly switch RPC providers as well. A user might believe they are using the Arbitrum network as a privacy mechanism (smaller transaction volume, potentially less analysis possible), only to discover that their endpoint is logging every query to an analytics service. The wallet security design is sound; the transparency failure is the weak point.
Why auto-switching between networks creates metadata exposure
Many wallets, including MetaMask, offer automatic network switching when a dapp requests a different chain. A website you visit can send a message to your wallet saying “please switch to Optimism” or “please add this token on Base.” Most users click approve without reading the network request carefully. The wallet switches, and often, a new RPC endpoint is now in use without any notification. A user might think they are still connected to a privacy-focused chain or a specific provider, when in reality, the wallet’s default for that network has taken over.
This switching compounds the metadata problem. An attacker or malicious website can enumerate which endpoints you respond to by watching connection patterns. By triggering network switches and observing timing, an adversary can infer which RPC provider your wallet uses for each chain and correlate that with other metadata. Over time, this fingerprinting can tie your wallet to a specific device, browser, or user profile. A comprehensive security analysis from OWASP identifies this pattern as a variant of browser fingerprinting, where application-level behavior reveals identity even when network-level identifiers are obscured.
The default RPC endpoints used by popular wallets are well-known and widely used. Infura, Alchemy, QuickNode, and a handful of other providers power the majority of wallet connections. This concentration creates a centralizing force in blockchain systems that were designed to be decentralized. An endpoint provider or a government regulator could theoretically demand a list of all addresses and their activity from a single RPC provider and obtain a large portion of the user base’s transaction history. Individual wallet users have no contractual relationship with these providers and no transparency into data handling practices.
Configuration risks and the missing documentation
Most wallet documentation explains how to use the wallet but not how to configure RPC endpoints, and when configuration is documented, it is often treated as an advanced feature. MetaMask’s settings allow you to add custom RPC endpoints for new networks, but the default networks come pre-configured and are not easy to change without resetting the wallet or manually modifying each network’s settings individually. For users who want to run a personal Ethereum node and route MetaMask through it, the process involves obtaining the necessary hardware, syncing the blockchain (weeks of setup), configuring the node correctly, and updating MetaMask’s network settings. Most users never reach that point.
For those who do attempt custom RPC configuration, several failure modes emerge. An incorrectly configured endpoint can cause transactions to be rejected silently, as if they had never been sent. A user might not realize the transaction failed and submit it again, creating accidental duplicate payments. An endpoint that implements an old version of the RPC specification can cause unexpected behavior with certain token standards or transaction types. Phishing attacks also target RPC configuration: a malicious website can suggest adding a “faster Ethereum endpoint” that is actually a harvester of transaction data or a vector for transaction manipulation.
A comprehensive independent review of a crypto wallet should disclose which default RPC providers it uses for each network, whether the user can easily change them, and what happens if an RPC endpoint becomes unavailable. However, most wallet marketing materials and documentation gloss over this detail. crypto wallet review should include endpoint transparency, RPC provider policies, and configuration difficulty as core security evaluation criteria, not as footnotes. Users need this information to make informed decisions about which wallet and network combination offers the privacy and reliability they require.
How to audit and reconfigure your wallet’s RPC endpoints
The first step is to determine which RPC endpoints your wallet is currently using. For MetaMask, open Settings → Networks and examine each network configuration. The RPC URL field shows the endpoint address. If it shows https://mainnet.infura.io or a similar service URL, you are using a third-party provider. If it shows a domain you do not recognize, investigate it: some wallets use their own infrastructure, while others partner with analytics or data collection services.
Once you have identified the endpoints, the second step is to decide whether you want to change them. The options are: run your own node, use a privacy-focused RPC provider, use a different centralized provider with a better reputation for data handling, or accept the default. Running your own node is the most privacy-preserving option but requires technical skill and hardware investment. Services such as Infura, Alchemy, and QuickNode all offer free tiers, but reading their privacy policies is essential; some collect and sell anonymized usage data, while others claim stronger commitments to user privacy.
Privacy-focused RPC alternatives exist, such as Ankr, Blast, or smaller community-run nodes, but their uptime and reliability vary. Before switching to an alternative endpoint, test it with a small, non-critical transaction. Verify that the endpoint correctly responds to balance queries and processes transactions within expected timeframes. Document the endpoint configuration in case you need to troubleshoot later. If you use multiple wallets or devices, remember that each installation will need separate configuration; the change does not automatically sync across devices.
For Ethereum users specifically, the Bitcoin protocol documentation and Ethereum’s protocol documentation both emphasize the importance of independent node operation for users who require strong privacy and censorship resistance. While few users will operate their own infrastructure, understanding why it matters—and why the default wallet behavior is a compromise—helps clarify the trade-off between convenience and control.
RPC endpoint metadata leakage in the broader wallet ecosystem
This RPC problem is not limited to MetaMask. Phantom users connecting to Solana networks face similar choices. Trust Wallet users on the Polygon network route through Trust’s selected provider. Ledger, despite being a hardware wallet, still uses third-party RPC endpoints when connecting through the Ledger Live software. Trezor similarly routes through third-party endpoints despite operating a hardware device. Even wallets marketed as privacy-focused tools do not necessarily route through endpoints that prioritize privacy by default.
The larger ecosystem problem is that wallet users often believe “non-custodial” means “private,” when in reality, non-custodial only means your keys are not held by the wallet provider. Metadata leakage through RPC endpoints is a separate concern from key custody. A wallet can be perfectly non-custodial while being highly transparent to its RPC provider. Conversely, financial regulators including the FCA are increasingly scrutinizing cryptocurrency wallet providers and RPC intermediaries, and user activity data obtained from these endpoints can be subpoenaed or voluntarily provided under regulatory request.
The decentralization narrative around blockchain technology often obscures this reality. A blockchain itself is decentralized, but the wallet applications that users interact with are not. And even when the wallet software is non-custodial, the network endpoints it relies on are often concentrated among a small number of providers. Users who want to truly exit this centralized chokepoint have few options beyond operating personal infrastructure, which is impractical for the vast majority of the cryptocurrency-using population.
Regulatory context and the future of wallet RPC transparency
The European Commission’s digital finance regulations include provisions on wallet providers and custodial services, but the RPC endpoint question sits in an ambiguous zone. An RPC provider that routes transactions but does not hold keys may not be classified as a custodian under current frameworks, yet the data visibility they possess is substantial. As regulatory frameworks evolve, particularly under MiCA (Markets in Crypto-Assets Regulation), there may be requirements for RPC providers to disclose data handling practices, comply with know-your-customer rules, or even limit transaction data collection.
The practical implication for wallet users is to expect that RPC configuration will become more front-and-center in wallet design and documentation. Wallets may eventually be required to disclose which RPC providers they use by default, how user data is handled, and whether the user has reconfigured their endpoints. Some hardware wallet manufacturers and privacy-focused wallet projects are already moving in this direction, making endpoint configuration a primary, not secondary, feature.
The bigger shift may be toward distributed RPC networks and solutions that reduce single-point-of-failure and centralization risks. Projects experimenting with decentralized RPC infrastructure aim to solve this by allowing users to connect through multiple independent nodes simultaneously, verify responses against each other, and avoid reliance on any single provider. These solutions are still emerging, but they represent an acknowledgment that the current default RPC model is a design problem, not a permanent architectural truth.
Building a practical endpoint security practice
For a user who wants to reduce RPC metadata leakage without becoming a full node operator, several practical steps help. First, segregate accounts and networks: use one wallet address for on-chain activity you are willing to expose, and keep high-value holdings separate. Second, rotate between different RPC endpoints for different activities; if you use MetaMask for one dapp and a different wallet for another dapp on the same chain, you fragment the metadata trail. Third, use a VPN when connecting to RPC endpoints, particularly when using public or semi-public endpoints, to obscure your IP address from the endpoint operator.
Fourth, keep your wallet software and RPC endpoint configuration documented and tested. If an endpoint becomes unreliable, you should be able to identify the problem quickly and switch. Fifth, monitor the RPC provider’s status page and news; if there are security incidents, data breaches, or regulatory actions involving your RPC provider, that is a signal to reconfigure. Sixth, consider running a local proxy or light client that caches RPC responses and reduces the number of direct queries sent to third-party endpoints. Projects such as Ultralight and others are exploring this approach.
These practices are more demanding than simply installing a wallet and trusting the defaults. But for users who care about privacy and security, the RPC endpoint decision is as important as the wallet software choice itself. A wallet is only as private as its default configuration allows, and only as private as its RPC provider permits. Understanding this limitation and acting on it is the difference between a crypto wallet that appears secure and one that actually is.
Frequently asked questions
What happens if my crypto wallet’s RPC endpoint goes down?
Your wallet will be unable to check balances, send transactions, or interact with dapps until the endpoint is available again or you reconfigure to use a different one. Your private keys remain safe on your device, but the wallet becomes non-functional temporarily. For this reason, having a backup endpoint configured or understanding how to quickly switch endpoints is part of wallet security planning.
Can an RPC endpoint operator see my private keys or steal my cryptocurrency?
No, an RPC endpoint cannot access your private keys because they are stored on your device, not on the server. However, the endpoint operator can observe which addresses belong to your wallet, your account balances, and your transaction history. They cannot steal funds directly, but they can use this metadata for targeting, surveillance, or selling information to third parties. This is why RPC endpoint privacy matters separately from key management in a non-custodial crypto wallet.
Is running my own Ethereum or Bitcoin node the only way to have real wallet security?
Running your own node improves privacy by eliminating third-party RPC metadata leakage, but it is not the only approach to wallet security. Privacy-focused RPC providers, using a VPN when connecting to shared endpoints, segregating addresses by use case, and staying informed about your RPC provider’s data practices all reduce exposure. For most users, a combination of these approaches is more practical than operating personal infrastructure, though operating your own node remains the gold standard for users who require maximum privacy and can manage the technical overhead.