A user adds a custom network to their MetaMask wallet extension, intending to access a legitimate Layer 2 protocol or emerging blockchain ecosystem. The RPC endpoint address looks plausible, the network parameters appear correct, and the interface accepts the configuration without complaint. What the user cannot immediately see is whether that endpoint is controlled by a malicious actor, designed to intercept transactions, steal private key material, or execute targeted phishing attacks. The MetaMask wallet extension does not validate custom RPC providers by default; it passes requests to whatever endpoint the user specifies. That delegation is a fundamental feature, not a failure\u2014self-custody demands user responsibility\u2014but it also means that connecting to a honeypot node can expose assets before a single transaction is approved.<\/p>\n
The security of MetaMask networks depends partly on Ethereum and EVM-compatible mainnet defaults, which are curated and well-known. Custom networks are different. They may route through infrastructure controlled by bad actors, display falsified transaction details, intercept approval transactions, or simply log every address and interaction attempt. The difference between a legitimate private RPC service and a trap can be invisible in the user interface. Detecting that difference requires understanding what makes an endpoint dangerous, how attacks work, and what precautions can reduce exposure without requiring advanced systems administration knowledge.<\/p>\n
<\/p>\n
The MetaMask wallet extension architecture separates key management from network communication. The user’s Secret Recovery Phrase and private keys remain on the local device, controlled entirely by the wallet application. Network requests\u2014balance queries, transaction broadcasting, contract interactions\u2014are sent to an RPC endpoint specified in the network configuration. This separation is intentional and sound. The problem arises when the endpoint itself becomes the vulnerability.<\/p>\n
A malicious RPC provider can observe every transaction request before it is signed, every address queried, and every contract interaction attempted. This visibility alone can reveal the user’s financial behavior, trading strategies, holdings across different addresses, and timing patterns. More aggressively, a compromised endpoint can return falsified data: showing incorrect balances, confirming transactions that were never broadcast, or providing manipulated contract data that tricks the user into approving a harmful transaction. Because the MetaMask wallet extension displays information returned from the RPC, a user may believe they are looking at legitimate network state when they are actually seeing a constructed lie.<\/p>\n
The attack surface expands when approval transactions are involved. If a user intends to approve spending a token with a decentralized application, they see a request to sign a transaction. The content displayed in MetaMask comes partly from the RPC endpoint’s response. A malicious endpoint can subtly alter the token address, the spending limit, or the destination contract while the transaction looks legitimate in the interface. The user signs what they believe is a harmless approval, but the actual transaction that reaches the blockchain contains different instructions. By the time the signature is applied, the private key has never touched the malicious endpoint\u2014but the damage is already done.<\/p>\n
Honeypot nodes are often created by cloning the appearance of legitimate services. An endpoint URL might resemble a real provider’s address, or it might be promoted through social engineering in a Discord channel, forum post, or direct message claiming to offer “faster” or “cheaper” access to a blockchain. Because MetaMask networks require only a valid HTTPS endpoint and a chain ID, the barrier to creating a fake custom network is trivial. The barrier to detecting it is much higher.<\/p>\n
Before adding any custom network to MetaMask, several verification steps can reduce the risk of connecting to a malicious endpoint. The first is to confirm the source of the recommendation. If you are adding a network for a legitimate protocol\u2014a Layer 2 solution, a testnet, or a new blockchain\u2014that protocol should have an official website, verified documentation, and clear instructions on how to configure the network correctly. The official source is the only source that matters. Blog posts, Reddit threads, Discord messages, and even GitHub repositories can be faked or compromised. Check the official domain ownership, use HTTPS, and navigate directly rather than following links from unknown sources.<\/p>\n
The RPC endpoint URL itself should match the official documentation exactly. Common variations include adding a port number, changing HTTP to HTTPS, including an API key suffix, or using a subdomain that looks similar but is not quite correct. The URL `https:\/\/rpc.example.com` is not the same as `https:\/\/rpc-example.com` or `https:\/\/example-rpc.com`. Attackers rely on users copying a URL quickly without noticing these differences. If the official source recommends multiple RPC endpoints, check that you are using one of them. If the official source provides no RPC endpoint and you are searching for one independently, cross-reference multiple sources to ensure they all recommend the same providers.<\/p>\n
For popular networks, several third-party services maintain lists of public RPC endpoints. These lists can be checked for consistency. If you find an endpoint recommended in multiple independent sources\u2014an official documentation site, a community-maintained endpoint list, and a block explorer\u2014the confidence in its legitimacy rises. This is not a guarantee; a coordinated attack could fake multiple sources. But it makes casual malicious endpoints less likely to succeed.<\/p>\n
The endpoint’s response behavior can also be tested before importing the network into MetaMask. Using a command-line tool such as curl or a simple Python script, you can send a basic RPC request to the endpoint and examine the response. A legitimate endpoint should respond with valid JSON-RPC data. For example, a request to `eth_chainId` should return a hexadecimal chain identifier that matches the official documentation. An endpoint that returns malformed data, an HTTP error, or suspiciously slow responses should be rejected immediately. This does not require technical expertise beyond copying a command; it provides a basic sanity check before trusting the endpoint with transaction requests.<\/p>\n
Once an endpoint is under consideration, specific RPC queries can reveal attack patterns. A legitimate endpoint should consistently return the same data for immutable queries. For instance, calling `eth_blockNumber` multiple times in quick succession should return the same block number or only slightly higher numbers if blocks are being mined in real time. An endpoint that returns wildly different block numbers, or that suddenly jumps backward, is either misconfigured or deliberately returning false data.<\/p>\n
Another test involves querying the endpoint’s peer information and client version. Using the `web3_clientVersion` RPC method, a legitimate endpoint returns the software it is running (for example, “Geth\/v1.13.0” or “Erigon\/2.48.0”). An endpoint that refuses this request, returns an unexpected client version, or provides inconsistent responses across multiple calls may be filtering requests or masking its true identity. This is not definitive evidence of malice, but it is a warning sign that warrants further investigation before connecting a MetaMask wallet extension with significant assets.<\/p>\n
Testing address balance queries against a known reference provides another layer of validation. If you have a small amount of funds on a different, verified device or wallet connected to a different RPC provider, query the balance of that address on both endpoints. They should match. If the suspicious endpoint shows a different balance, it is either out of sync with the network or returning falsified data. Do not assume the endpoint is simply behind in synchronization; verify by checking a block explorer independently. A public block explorer typically uses multiple RPC providers internally, so it can serve as a neutral reference point. If the block explorer and the official MetaMask networks show one balance but your custom endpoint shows another, the custom endpoint cannot be trusted.<\/p>\n
For EVM wallet security more broadly, testing the endpoint with a read-only contract query can expose endpoints that intercept or modify requests. Query a simple, publicly known contract function\u2014such as checking the total supply of a major token\u2014on both your custom endpoint and a known-good endpoint. The results should be identical. If they differ, the custom endpoint is either corrupted or returning modified data. This test is especially useful because it does not require you to spend funds; it is a pure verification step that takes seconds.<\/p>\n
Certain characteristics strongly suggest that an endpoint should be avoided immediately. If the URL is flagged by browser security tools, contains an unrecognized domain registration, or uses a self-signed SSL certificate (indicated by a security warning in the browser), do not proceed. While legitimate private RPC services may use custom domains, they will have valid SSL certificates issued by a trusted certificate authority. A browser warning is a red flag that deserves serious attention.<\/p>\n
Endpoints that promise unrealistic performance improvements are another warning sign. If a service claims to offer transaction speeds far beyond what is physically possible on the network, or fees substantially lower than legitimate providers, it is likely either fraudulent or intentionally intercepting requests. Legitimate RPC providers compete on reliability and support, not on claims of defying network physics. Similarly, endpoints that are not affiliated with known infrastructure providers (Infura, Alchemy, QuickNode, Ankr, Lava, and others for major networks) but claim to offer “official” service should be treated as suspicious unless verified directly through an official source.<\/p>\n
The promotion channel itself matters. An endpoint recommended in a private message, promoted in a token Discord channel, or found in a reply to a social media post about struggling with high fees should be approached with extreme skepticism. Legitimate RPC providers are promoted through official documentation and mainstream developer channels. Opportunistic attacks often use direct messaging or community channels where users are frustrated and less likely to question a solution that sounds helpful.<\/p>\n