Custom Network Tokens and Scam Wallets: Why MetaMask and Trust Wallet Are Targets for Airdrop Impersonation

MetaMask and Trust Wallet have become the largest non-custodial wallet applications in the market, with millions of users across Ethereum, Solana, Polygon, Arbitrum, Optimism, and dozens of other chains. That scale makes them attractive targets for fraud. One of the most persistent attack vectors relies on a feature that is also one of the wallets’ core strengths: the ability to add arbitrary custom networks and tokens. A user who receives a notification about an airdrop, adds the token contract to their wallet by pasting an address into a custom token field, and sees a balance appear in their portfolio may feel they have successfully claimed something valuable. In reality, they may have added a malicious contract that can drain their connected accounts across multiple chains.

The confusion arises because flexibility in a crypto wallet guide cuts both ways. The same architecture that lets a user quickly experiment with emerging blockchains and tokens also makes it possible for an attacker to create a convincing replica of a legitimate airdrop. MetaMask, Trust Wallet, and similar applications do not automatically curate which tokens can be added; they rely on user discretion, network transparency, and blockchain explorers to verify legitimacy. That places a responsibility on the individual to distinguish between a genuine protocol distribution and a social engineering trap. The financial stakes are high, and the attack is becoming more sophisticated.

Why MetaMask and Trust Wallet make custom tokens easy to add

Both wallets were designed to support new networks and tokens without waiting for developers to build formal integrations. When a user encounters an ERC-20 token on Ethereum, a BEP-20 token on Binance Smart Chain, or a token on any EVM-compatible chain, they can paste the contract address into a custom token field. The wallet then queries the blockchain, retrieves the token’s name, symbol, and decimal places, and displays it in the user’s portfolio. This workflow is necessary because thousands of tokens exist, and no wallet can feasibly maintain an exhaustive list of all legitimate ones.

The user experience is intentionally streamlined. Once the contract address is confirmed, the token appears immediately. A user can then see their balance, transfer the token, or swap it on a decentralized exchange. The wallet does not perform an independent security audit or verify the token’s legitimacy; it simply reads the contract’s metadata from the blockchain. This is not a bug—it is a deliberate design decision that prioritizes accessibility and openness over gatekeeping. The trade-off, however, is that an attacker can create a token contract with a name and symbol that closely resembles a real one and distribute instructions to add it to unsuspecting users.

The broader context is that Ethereum’s token standards, documented in detail, define the interface that MetaMask and other wallets use to interact with tokens. The ERC-20 standard specifies how tokens report their name, symbol, and balance. It does not define whether a token is legitimate, secure, or actually owned by the project it claims to represent. An attacker can deploy a contract that perfectly conforms to ERC-20 while doing nothing more than track balances—or they can add hidden functions that drain funds when certain conditions are met.

How airdrop impersonation works in practice

A typical impersonation flow begins with social engineering. The attacker creates a contract on Ethereum, Polygon, or another chain and chooses a name and symbol that closely mimic a real project. For instance, if a legitimate protocol called “Portal” is announcing an airdrop on Polygon, an attacker might deploy a contract called “Portal” or “PORTAL” on the same chain, often using a slightly different symbol or formatting to avoid immediate detection. The attacker then distributes messages via Discord, Twitter, email, or wallet notifications claiming that users should “add this token to their MetaMask or Trust Wallet to see their airdrop balance.”

The message includes a contract address, which the user pastes into the custom token field. The wallet displays the attacker’s contract metadata, showing the legitimate-sounding name and symbol. If the attacker has also distributed fake tokens to the user’s address ahead of time (a tactic called “dusting”), the wallet will show a balance immediately. The psychological effect is powerful: the user has a balance of a token they did not actively receive, and the wallet is showing it to them. The user may then assume the airdrop is real and try to transfer or swap the tokens on a decentralized exchange.

At that point, the attack enters its second phase. When the user attempts to sell the token, the contract’s code may execute a hidden function that drains the user’s wallet. Some contracts use a sophisticated variation in which the drain is triggered not by a transfer but by an approval. The user grants the contract spending rights—necessary for swapping—and the contract’s fallback function then transfers approved tokens or ETH from the user’s other holdings. The attacker does not even need the user to successfully execute the swap; the act of granting approval is the trigger.

Other variations involve a contract that appears to swap the fake token for a real one but instead routes the transaction through a malicious router that swaps the user’s real tokens for nothing. A user who has added the scam token to MetaMask or Trust Wallet and then interacts with it is vulnerable to these patterns because the wallet does not block the transaction—it merely broadcasts what the user signed. Once a transaction is on the blockchain, it cannot be reversed.

The role of wallet security in detection and prevention

Neither MetaMask nor Trust Wallet can prevent all airdrop scams because the wallets do not validate whether a token contract is legitimate. Doing so would require centralized curation or off-chain oracles, both of which introduce their own risks and reduce the wallet’s ability to support new projects quickly. Instead, both wallets have adopted warning systems and transparency tools to help users verify legitimacy.

MetaMask includes a phishing detection feature that blocks known malicious domains and contract addresses flagged by community reports or integrated security feeds. However, this approach is reactive: a new scam token must be identified and reported before the filter catches it. A user adding a custom token that has never been seen before will not receive a warning. Trust Wallet similarly maintains blocklists and warns users when they interact with flagged contracts, but the same limitation applies. An attacker can deploy a new contract, distribute it before it becomes widely known, and collect funds from dozens or thousands of users in a matter of hours.

The most effective preventive measure remains user education. A crypto wallet guide—such as those available through crypto wallet guide resources—emphasizes verifying token addresses through multiple sources before adding them. The official approach is to visit the legitimate project’s website or GitHub repository, confirm the contract address from an official statement, and cross-check it with a blockchain explorer such as Etherscan. Only after this verification should a user add the token to their wallet. If a project announces an airdrop, the correct token address should appear in multiple places: the official website, social media accounts, blog posts, and documentation. A single Discord message or a screenshot is not enough.

Custom networks and the expanded attack surface

The ability to add custom networks compounds the risk. MetaMask and Trust Wallet allow users to add any EVM-compatible chain by specifying the RPC endpoint, chain ID, and native currency symbol. A user might legitimately add a new chain they want to experiment with. However, an attacker can distribute instructions to add a fake or compromised RPC endpoint, directing the user’s wallet to connect to a server controlled by the attacker. When the user views their portfolio or approves a transaction, they are interacting with a fake representation of the blockchain supplied by the attacker’s server.

A compromised RPC endpoint can display false balances, hide transactions, or present the user with a phishing interface that looks like a legitimate swap but is actually stealing their private keys or seed phrases. The attacker’s goal is not always to steal funds directly; sometimes it is to capture the user’s recovery phrase or to redirect a transaction to an attacker-controlled address.

Protection against this threat requires checking the network details carefully. Bitcoin’s documentation and Ethereum’s specifications both establish the importance of verifying that a connection to a blockchain is legitimate and secure. For custom networks, users should verify the RPC endpoint through official sources, check that the chain ID matches documented specifications, and never import a network configuration from a link in a message. Legitimate projects provide network configuration details in plain text on their official websites, often with a download button that generates a properly formatted configuration file.

How to identify and avoid impersonation scams

The first defense is skepticism about unexpected airdrops. Legitimate projects distribute tokens through transparent, verifiable mechanisms. A user should ask: Has this project announced an airdrop on its official website? Is the announcement signed by recognized team members? Does the official website match the domain exactly (not a similar-looking misspelling)? If a user must dig to find the official announcement, the token is likely a scam.

Contract address verification is non-negotiable. The official project website should display the contract address prominently and consistently. If the same token appears to have multiple addresses, that is a red flag. Users can verify the contract on Etherscan or other blockchain explorers by searching for the contract address and checking who deployed it. If the deployer is an unknown address with no history, or if the contract has functions that do not make sense for a token (hidden mint functions, arbitrary balance changes, or approval hooks), those are additional warning signs. Some projects publish the contract address on GitHub with commit history, providing an additional layer of verification.

Before adding a token to MetaMask or Trust Wallet, a user should have the contract address confirmed from at least two independent official sources. One should be the project’s website; the second could be a recent social media post from a verified account, a GitHub repository, a blog post, or an announcement in a channel that is difficult to impersonate. A single Discord message, even from someone with a moderator role or a project name in their username, is not sufficient, because Discord accounts can be compromised or spoofed.

When adding the token, users should verify the displayed name and symbol match expectations. A token should not have extra spaces, unusual characters, or subtle variations. After adding, the user should not immediately attempt to sell or swap the token. Instead, they should leave it alone for a day or two and monitor community discussions for any reports of scams. If others are reporting the same token address as malicious, the user should remove it from their wallet without ever interacting with it. Removing a scam token from the wallet interface is simple: it does not send any transaction; it just hides the token from view.

Wallet architecture differences and their security implications

MetaMask and Trust Wallet are both non-custodial, meaning the wallet does not hold the user’s private keys or seed phrase. The user controls their own cryptographic material. This is a significant security advantage over exchange wallets, but it also means the user bears responsibility for protecting their recovery phrase and approving transactions. A scam token attack succeeds only if the user adds the token and then approves a transaction or grant of spending rights. If a user adds a scam token but never interacts with it, the wallet cannot be drained.

Some newer wallets use Multi-Party Computation (MPC) or keyless architectures that distribute key material across devices or servers, never storing a complete private key in one place. These approaches reduce the risk of seed phrase theft but do not eliminate the risk of transaction approval. A user of an MPC wallet who approves a malicious transaction will still lose funds, just as with a traditional seed-phrase wallet. The fundamental issue—that users must verify what they are approving—remains constant across wallet architectures.

Hardware wallets such as Ledger and Trezor offer additional protection by storing private keys on a secure device and requiring physical confirmation for transactions. However, they are not immune to airdrop scams. A user with a hardware wallet can still add a scam token to MetaMask or Trust Wallet and attempt to swap it, and the hardware wallet will be asked to sign the transaction. If the user confirms the signature on the device, the transaction executes just as it would on a software wallet. The hardware wallet protects the key; it does not verify the legitimacy of the transaction being signed.

What wallets and projects can do to reduce risk

Wallet developers have several options for improving the experience without eliminating the flexibility that makes the platforms valuable. Token allowlists, sourced from curated databases and community submissions, can flag tokens as verified or unverified. MetaMask and Trust Wallet already use token image registries; extending this to include security status would help. However, allowlists must be updated constantly and can create a false sense of security if users assume an allowlisted token is audited for functionality and security.

Simulation tools that preview the effects of a transaction before signing are becoming more common. These tools can show what will happen to the user’s balances if a transaction is approved, including hidden functions that might drain funds. OWASP security guidelines recommend testing and verification before execution, and wallet applications are gradually integrating this principle. If a wallet could display a preview of what a token swap will actually do—before the user signs—the risk would decrease significantly.

Projects themselves can contribute by publishing contract addresses in multiple places, using multi-signature control to limit token contract upgrades, and publishing audit reports from reputable security firms. If a token has been audited by a known firm, the report and audit address should be easy to find and independently verify.

The role of regulation and industry standards

European Union regulations on cryptocurrency wallets, under the Markets in Crypto Assets (MiCA) framework, are beginning to address wallet security requirements. These regulations may eventually require wallets to implement certain protections or warnings for high-risk transactions. The UK’s Financial Conduct Authority has also issued guidance on cryptocurrency wallet oversight, emphasizing the importance of user protection and fraud prevention. However, regulation moves slowly, and scammers adapt quickly.

Industry standards such as BIP39, which defines seed phrase and mnemonic standards, have established best practices for key generation and recovery. Standards for wallet labeling, token verification, and contract interaction remain less formalized. The lack of consensus makes it harder for users to know what they should expect from a wallet and easier for scammers to exploit confusion about what is “normal” behavior.

The long-term solution will likely involve a combination of wallet features, user education, and regulatory requirements. In the meantime, the responsibility falls primarily on users to verify before adding any token and to understand that MetaMask, Trust Wallet, and similar wallets are neutral tools. They will broadcast whatever transaction a user approves, regardless of whether the transaction is safe. That is not a flaw; it is the necessary price of a non-custodial wallet that respects user autonomy. The risk is real, but it is manageable with discipline.