Does a valid checksum mean an address is safe?

No. An EIP-55 checksum only confirms the address string is internally consistent and probably not mistyped. A scammer's address has a valid checksum too. Safety comes from sourcing the address correctly and reviewing the verified contract, not from the checksum.

What does the green 'verified' badge on Etherscan actually prove?

It proves the published human-readable source recompiles to the exact bytecode deployed on-chain, so you are reading the real logic. Etherscan states explicitly that verified does not mean audited or safe; a contract can be verified and still malicious.

The address behaves correctly now. Can it change later?

Yes, if it is a proxy. A proxy delegates to an implementation address that an admin can upgrade. Check the ERC-1967 implementation slot, review the current implementation, and note who holds upgrade rights before treating current behavior as permanent.

A strange address matching mine appeared in my transaction history. Was I hacked?

Almost certainly not. That is address poisoning: an attacker sent a tiny or zero-value transfer so their lookalike appears in your history, hoping you will copy it later. Your keys are unaffected. Do not use that address; obtain the real one from a trusted source.

Why compare the whole address instead of the first and last few characters?

Because attackers specifically generate lookalikes that match the ends, since that is the part people check. Only a full-string comparison, or at least a middle segment, reliably distinguishes a genuine address from a crafted lookalike.

How to Verify a Contract Address Before Interacting

A repeatable procedure for confirming that an address is the contract you think it is: checksum validation, sourcing the address from an authoritative place, reading verified source on a block explorer, resolving proxy implementations, and ruling out lookalikes.

Why an address needs verification at all

An account address on an EVM chain is a 20-byte value, normally written as 40 hexadecimal characters after a 0x prefix. Nothing about that string tells you what it is. The same format is used for a person’s wallet, a legitimate token, a router used by a decentralized exchange, and a contract written specifically to take your funds. The protocol does not distinguish between them, and it will not stop you from sending assets to, or granting an approval to, the wrong one. Verification is the manual work of establishing, before you sign, that a given address is the specific contract you intend to interact with.

The failure modes are consistent. People paste an address from a Telegram message, a search advertisement, or a screenshot; they trust an address because a website displayed it; or they copy an address out of their own transaction history without realizing it was planted there. Each of the steps below closes one of those gaps.

Step one: validate the checksum

Ethereum addresses are case-insensitive at the protocol level, so 0x5aaeb6... and 0x5AAEB6... refer to the same account. EIP-55 exploits that spare capacity by encoding a checksum in the pattern of upper- and lower-case letters. The algorithm hashes the lowercase address with Keccak-256 and, for each alphabetic character, capitalizes it when the corresponding hash nibble is 8 or greater. The result is a mixed-case address that most wallets will reject if a character is wrong.

0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed

According to the EIP-55 specification, the net probability that a randomly mistyped address passes the check by accident is roughly 0.0247 percent. Two caveats matter. First, an all-lowercase address contains no checksum information, so no error detection is possible; treat any interface that hands you a lowercase address with extra caution. Second, a checksum only proves the string is internally consistent. It proves nothing about whose address it is. A scammer’s address has a valid checksum too.

Step two: source the address from an authoritative place

This is the single most important step, and no on-chain check substitutes for it. Decide where the canonical address should come from before you go looking, so an attacker cannot supply the answer. Reliable sources include the project’s own documentation on a domain you typed yourself, an official token list, or a link from a verified account you reached independently. Unreliable sources include search-engine advertisements, direct messages, replies under a social post, QR codes from strangers, and any address a support agent sends you.

Where multiple independent sources exist, cross-check them. If a token’s contract is listed identically on the project’s documentation, a reputable token list, and the explorer’s labelled entry, that agreement is meaningful. If the only place an address appears is the message that is asking you to use it, you have verified nothing.

Step three: read the contract on a block explorer

Open the address on a block explorer such as Etherscan. A contract account shows a Contract tab; a plain wallet does not. If you expected a token or an application and the explorer shows no contract code, stop.

Look for verified source. When a developer verifies a contract, the explorer recompiles the submitted Solidity or Vyper with the exact compiler version and settings and compares the output to the bytecode already deployed on-chain. If they match, the source becomes publicly browsable and is marked with a verification badge. As ethereum.org and Etherscan both note, verification establishes that the human-readable code you are reading is the code that actually runs.

Understand precisely what that badge does and does not mean:

It does mean the published source corresponds to the deployed bytecode, so any review you or others perform is review of the real logic.
It does not mean the contract is safe, audited, or benign. Etherscan states plainly that a contract can be verified and still be malicious by design. Verification is a precondition for scrutiny, not a substitute for it.

On the verified code, sanity-check the basics that match your expectation: the token name and symbol, the declared decimals, and the presence or absence of functions that let an owner change tax, pause transfers, or blacklist addresses. Also read the explorer’s own labels and warnings, which frequently flag reported scams and phishing.

Step four: resolve proxy contracts

Many modern contracts are proxies. A proxy holds the state and forwards every call to a separate implementation (or logic) contract via delegatecall. This lets a project upgrade behavior without changing the address users interact with, but it also means the code that runs is not the code stored at the address you are looking at.

ERC-1967 standardizes where a proxy records its implementation: a fixed storage slot derived so that it cannot collide with ordinary variables.

0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc

Explorers detect this pattern. When a contract follows ERC-1967, Etherscan shows a note that it is a proxy, offers a Read as Proxy / Write as Proxy view, and links to the current implementation address. Two practical consequences follow. First, verify the implementation’s source as well, not just the proxy shell. Second, recognize that whoever controls the admin slot can point the proxy at new logic at any time; an address that behaves correctly today can be upgraded to behave differently tomorrow. If upgradeability is unexpected for what you are using, treat it as a finding, not a footnote.

Step five: rule out lookalikes and address poisoning

The last class of error is visual. Attackers generate addresses whose first and last characters match one you already use, then get that lookalike into your field of view. The most common technique is address poisoning: the attacker watches your on-chain activity, generates an address matching the first and last few characters of one you transact with, and sends you a tiny or zero-value transfer so their lookalike appears in your transaction history. Because ERC-20’s transferFrom emits a Transfer event even for a zero amount, this costs the attacker almost nothing. Later, when you copy a recent counterparty out of your history at a glance, you copy theirs. MetaMask, Trezor, and Chainalysis all document this pattern, and Chainalysis has traced tens of millions of dollars in losses to it.

Defences are concrete:

Compare the entire address, or at minimum a run of characters from the middle, never only the ends. Attackers optimize for the ends because that is what people check.
Do not copy addresses out of transaction history. Use a saved address book entry you created from a verified source, or re-obtain the address from that source each time.
Send a small test transaction to a new destination before a large one where the cost of that test is acceptable.
Be aware that a poisoned entry in your history is not a compromise of your wallet. It is bait. Ignoring it is sufficient; you do not need to move funds because a dust transfer appeared.

Putting the checks in order

The steps are cumulative and cheap relative to what they protect. In sequence: confirm the string is well-formed and checksummed; confirm it came from a source an attacker could not control; confirm on an explorer that it is a contract with verified source that matches your expectations; if it is a proxy, resolve and inspect the implementation and note who can upgrade it; and confirm by full-string comparison that it is not a lookalike. Only after all five should you connect a wallet, grant an approval, or sign. None of these steps requires trusting a person, and that is the point: verification replaces trust in a counterparty with checks you can perform yourself.

Sources

Note: CamoCrypt is security & education only — no prices, no predictions, no investment advice. Verify every address and contract yourself; we cannot recover lost funds and neither can anyone who contacts you claiming they can.

How to verify a contract address before interacting