What does a token contract address identify?
For an ERC-20 token on an EVM network, the contract address identifies the program that manages the token's balances and rules. It is different from your own receiving account address. MetaMask's token-contract explanation makes this distinction because confusing the two can lead to incorrect wallet setup or transfers.
Record the network together with the full address. A matching name, ticker or logo is not enough to identify a deployment, and an address string alone does not identify which network you are inspecting. This guide covers EVM token contracts; it is not a universal address checklist for every blockchain.
The task here is evidence checking. You can read public documentation and explorer pages without connecting a wallet, approving a spender or sending funds. Identifying the intended token is one check; deciding whether its behavior and risks are acceptable requires further work.
Start from an independently located source
Open the project's established documentation independently, rather than following a direct-message link or treating a search advertisement as authority. Find the current deployment record and its network. If a migration is mentioned, establish whether the record is for the old contract, the new contract or a bridge representation.
Copy the full address into the relevant network's explorer and compare it with that deployment record. MetaMask documents finding the contract field on token explorer pages. Check the domain and network before using the result; similar-looking pages or the same ticker can describe another asset.
Write down where the address came from and when you checked it. If the project documentation and explorer disagree, mark the identity unresolved. Do not choose whichever page looks more polished or treat a high follower count as a replacement for evidence.
A token appearing in a wallet or activity feed does not oblige you to visit its linked website. Use the same independent-source check for unsolicited tokens. No public-address lookup requires a recovery phrase.
What does verified source code actually prove?
Source verification generally checks that submitted source code and compiler settings reproduce the deployed code under the verification service's rules. It makes the code available for inspection. Ethereum.org explains this code-to-deployment relationship; it is different from certifying that a token is safe.
A verified contract can still have undesirable permissions or behavior. Record the verification status separately from audit evidence, administrative powers and your assessment of the intended use. “Verified” does not mean profitable, endorsed by the explorer, audited or guaranteed to remain available.
If source is unavailable, your ability to inspect behavior is more limited. That does not automatically establish fraud, but it leaves an evidence gap. Do not replace the gap with a conclusion that the contract is safe.
For security claims, open the actual audit and compare its scope and version with the deployment you identified. Our existing audit guide covers that evaluation; this guide's checklist does not replace a code review.
Why do proxy and implementation addresses matter?
A proxy delegates execution to implementation code. An upgrade can change the implementation while leaving the proxy address unchanged. Record the proxy and the implementation shown at the time of inspection, and look for the project's explanation of who can authorize an upgrade.
Etherscan can expose proxy-related fields, but its documentation describes detection limitations. A “Read as Proxy” interface is not proof that every execution path has been verified. An explorer's displayed implementation can need further checking after an upgrade or with a custom design.
Do not substitute an implementation address for the token address in a transfer or application merely because it contains the code. The purpose here is to trace the relationship. If you cannot establish that relationship or its current state, record it as unresolved.
An unchanged token address therefore does not settle the question of whether an older audit still covers the current behavior. Keep the observation date and, when available, the block reference with your notes.
Five-minute exercise: compare four fictional records
This worksheet uses labels instead of usable blockchain addresses. Nothing below is a real token or a destination for funds. An independently located project record says the intended deployment is Network A, contract ALPHA, symbol LEAF, decimals 6.
Record 1: Network A, ALPHA, LEAF, source verified, implementation P1. Record 2: Network B, ALPHA, LEAF, source verified. Record 3: Network A, BETA, LEAF, source verified. Record 4: Network A, ALPHA, LEAF, source verified, implementation P2 observed later.
Record 1 matches the stated identity, but its safety has not been established. Record 2 has the wrong network for this task. Record 3 has the wrong contract despite the same symbol. Record 4 retains the identity but introduces a changed implementation that requires investigation; an earlier P1 audit cannot be assumed to cover P2.
Now add a raw balance of 2,500,000 units for ALPHA. With the stated 6 decimals, the display quantity is 2,500,000 ÷ 10^6 = 2.5 tokens. If the declared decimals were 8 instead, the same raw number would display as 0.025 tokens. Neither quantity is a dollar valuation.
ERC-20 treats name, symbol and decimals as optional metadata. Check what the actual token and interface provide instead of assuming every token uses 18 decimals. Do not apply this division again to a balance an explorer has already formatted.
Try this prompt: Using only the fictional project record and four explorer records above, separate identity matches from unresolved security evidence. Explain the implementation change and calculate the display balance once. Do not rank tokens, invent a market price or recommend a transaction.
Save a record you can check again
Your evidence sheet should contain the network, full token address, source URL, observation time, verification status, any proxy/implementation relationship and unresolved questions. Keep the token address separate from your own account address and from any proposed spender.
If an application asks for an approval, checking the token alone is insufficient: the spender, amount and permission mechanism also matter. Use our approval guide for that separate task. A familiar token can be involved in an unsafe authorization.
Repeat the relevant checks after a migration, upgrade or conflicting announcement. The useful result is a traceable statement such as “identity matched this deployment record on this network; current implementation not yet confirmed,” rather than a universal green-light label.
For this exercise, stop after the evidence sheet. No funds, signature, token import or wallet connection is needed to demonstrate the reasoning.
- Match the network and complete address to independently located documentation.
- Separate source verification from audit and permission evidence.
- Record proxy implementation uncertainty and observation time.
- Treat raw units, displayed tokens and currency value as separate quantities.
Sources & further reading
- MetaMask: what a token contract address identifies
- MetaMask: finding a token contract address
- Ethereum.org: source code verification
- Etherscan: proxy contracts and detection limitations
- ERC-20: token metadata, decimals and balances
Educational content. Examples are illustrative. Protocols, products and rules can change; consult the linked documentation for current details.