A contract address is the fixed address where a smart contract sits on a blockchain. It derives from the creator address plus a nonce or salt, and belongs to program code, not a private key. Anyone sending tokens there addresses the program directly.
Ethereum distinguishes two account types: accounts under the control of a private key, and contract accounts. Those contract accounts run a smart contract on the EVM. Both share the same address format. As a result, users regularly mistake a contract address for a wallet address. The difference lies in the origin. A wallet address derives from a public key under secp256k1. A contract address, however, comes from the data of the deployment transaction. No key pair therefore belongs to a contract address.
How CREATE and CREATE2 compute the address
A contract address first arises from a transaction without a recipient in the to field. That transaction's data field carries the init code. From that input, the CREATE opcode builds the hash keccak256(rlp([sender, nonce])). Specifically, the hash's last 20 bytes form the address, 42 characters long in hex notation with the 0x prefix. The nonce counts the outgoing transactions of the creator and rises with each one. Consequently, anyone deploying the same code twice receives two different addresses.
CREATE2, however, replaces the nonce with a freely chosen salt and folds the init code into the hash. EIP-1014 describes the formula, while the Constantinople hard fork activated the opcode on the main chain on 28 February 2019. Because the creator chooses the salt, they control the address and can publish it before the contract exists. Developers call this counterfactual deployment. In both cases, the address itself stays permanent. Should the contract receive new code through a proxy pattern, that leaves the address untouched.
| Feature | CREATE | CREATE2 |
|---|---|---|
| Formula | keccak256(rlp([sender, nonce]))[12:] | keccak256(0xff ++ sender ++ salt ++ keccak256(init_code))[12:] |
| Depends on | nonce of the creator | freely chosen salt |
| Address computable before deployment | No | Yes |
| Introduced | original EVM opcode | EIP-1014, Constantinople hard fork 28 February 2019 |
Other chains also derive addresses, yet they calculate differently. Solana addresses are usually Ed25519 public keys. Program Derived Addresses, however, emerge deterministically from seeds and a program ID via SHA-256. Such addresses are guaranteed to lie outside the Ed25519 curve. No private key exists for them as a result.
How do you recognize a real contract address?
A block explorer displays a contract address in mixed upper and lower case, just like any Ethereum address. That spelling encodes a checksum under EIP-55. Specifically, a hex letter appears in upper case under one condition. The matching nibble in the keccak256 hash of the lowercase address must reach at least 8. The pattern therefore comes not from the address as text, but from its hash. A single wrong character changes that hash completely. Consequently, the pattern of upper and lower case letters usually changes with it. When the spelling does not match the hash, the address is faulty.
EIP-55 places an average of 15 check bits into an address. A randomly generated address that someone mistypes still passes the checksum with a probability of 0.0247%. Thus, in arithmetic terms, roughly one in 4,049 mistyped addresses slips through unnoticed. Those check bits occupy no extra character. Instead, they sit entirely in the upper and lower case of the letters.
However, the checksum is not mandatory, and an address written entirely in lower case remains valid. A fully valid address that belongs to someone else passes just as easily. After all, the checksum tests the character string and not the intent behind it. Nor does the checksum reveal whether a program or a key pair sits behind an address.
When a fake address matches the real one
Under the name address poisoning, the block explorer Etherscan describes how attackers replicate addresses that belong to others. In address spoofing, an attacker first generates a vanity address. Its first and last characters match those of the genuine address. Subsequently, the attacker sends the victim a worthless transaction, which shows up in the victim's history. Anyone who compares only the start and the end there sees no difference. Fake ERC-20 contracts also circulate, and they imitate the names and symbols of well-known tokens. In event spoofing, a forged transfer event via transferFrom simulates a movement that never took place.
One documented case hit a single wallet in May 2024. The attacker had replicated the first and last characters of the target address beforehand. The transfer ran to roughly USD 68 million. Later, the attacker returned the funds.
Zero-value transfers are one channel through which a fake address enters a transaction history in the first place. Etherscan has therefore hidden token transfers without value by default since April 2023. Still, the reliable source for a contract address remains the project page, not the transaction history.
