Same contract address on every chain: how deterministic (CREATE3-style) deployment works and why it matters for meme coins

Paste a contract address into an explorer on Base and then on BNB Chain and you will usually find a contract on one and nothing on the other, or two unrelated contracts. Addresses on EVM chains are not chosen; they fall out of the deployment math, and that math normally produces different results on different chains. Some projects, including sasa's launch races, deploy a coin to the same address on every chain. This guide explains the three deployment methods that decide an address, why only one of them makes cross-chain matching reliable, what the matching address does and does not guarantee, and how to check it yourself. The reasons a coin would want to be on several chains at all are covered in cross-chain meme coins explained.

Where a contract address comes from

An EVM address is 20 bytes derived from a hash. For contracts, what goes into the hash depends on the opcode used to deploy. There are two opcodes, CREATE and CREATE2, and a pattern built on top of them that people call CREATE3. Each gives a different answer to the question: if I deploy the same thing again somewhere else, will the address match?

CREATE: address from deployer and nonce

Ordinary deployment uses CREATE. The address is a hash of the deployer's address and the deployer's nonce, the count of transactions that account has sent. The contract's code is not part of it. So the same wallet deploying the same code on two chains gets the same address only if its nonce is identical on both chains at that moment. That is fragile: one extra transaction on one chain, a failed deployment, a test transfer, and the nonces diverge forever. Projects have matched addresses this way by using a fresh wallet and sending the deployment as its very first transaction on every chain, and it works until someone makes a mistake. For a launchpad deploying many coins, it is unworkable.

CREATE2: address from deployer, salt and bytecode

CREATE2, introduced in EIP-1014, computes the address from the deployer's address, a salt the deployer chooses and the hash of the contract's creation bytecode, including any constructor arguments. Nonce is out of the picture, so the same deployer, salt and bytecode give the same address on every chain regardless of history. This is a big improvement and it is how most deterministic deployment works today.

The catch is the bytecode. If anything that goes into the constructor differs per chain, the address differs. A token whose constructor takes the address of the chain's DEX router, the native wrapped token, or a per-chain fee recipient will compile to different creation bytecode on each chain and land at different addresses. Keeping bytecode byte-for-byte identical across four chains with different DEXs and different quote assets is possible but brittle, and any later upgrade to the token code changes every future address.

CREATE3-style: address from deployer and salt only

The CREATE3 pattern removes bytecode from the equation with a two-step trick. A factory contract, itself placed at the same address on every chain, uses CREATE2 with the chosen salt to deploy a tiny, fixed proxy contract. Because the proxy's bytecode is always the same, its address depends only on the factory address and the salt. That proxy then uses ordinary CREATE to deploy the real contract. The proxy has never sent a transaction before, so its nonce is 1 on every chain, and the CREATE address depends only on the proxy's address and that nonce. Chain the two steps together and the final contract's address depends on exactly two things: the factory's address and the salt. The real contract's bytecode and constructor arguments can be anything, and can differ per chain, and the address still matches.

• Factory at the same address on every chain, deployed once via CREATE2 from a well-known deployer.
• Salt chosen per coin, for example derived from the launch ID, so every coin gets its own address.
• Proxy: fixed bytecode, so CREATE2 gives it the same address everywhere for a given salt.
• Real token: deployed by the proxy with CREATE at nonce 1, so its address is fixed by the proxy's address alone.

This is the pattern that fits a launchpad like sasa, where each coin is deployed on Base, BNB Chain, Robinhood Chain and Arc and ends up with one contract address on all four. The per-chain details, which DEX the pool uses and which asset it is paired with, do not have to be squeezed into identical bytecode.

What a matching address guarantees

• One thing to share. The creator posts a single contract address and it is correct on every chain the coin exists on. How to announce a coin launch on X explains why the address, not the name, is what goes in the post.
• One thing to search. A buyer pastes the address into sasa, a DEX or a screener and finds the coin wherever it lives, which after a race is the winning chain.
• No wrapped-token ambiguity. There is no second address on a second chain that might be a bridge IOU or a copycat.
• Clean migration. In a launch race, holders on losing chains receive their coins at the same address on the winner, so a wallet that tracked the address keeps working without changes.

What it does not guarantee

The address is a function of the factory and the salt. It says nothing about what code was deployed there. Three things follow, and buyers should keep them in mind:

1. Same address, different code is possible. Whoever controls the factory could deploy a different contract at the same address on a chain where it was not yet deployed. For a launchpad this means trusting the launchpad's deployment rules; for a random project it means verifying each chain separately.
2. Verified source matters more than the address. Each chain's explorer lets a deployer verify the source code against the deployed bytecode. Check that the token is verified on the chain you are buying on and that it has no owner powers you were not told about. The checks are listed in how to spot a rug pull.
3. A reserved address is not a live coin. An address that exists on four chains may only have a pool on one. Check the pool and its lock on the chain you are trading on; how to check if liquidity is locked shows how.

How to verify a cross-chain address yourself

1. Open the address on each chain's block explorer. Confirm it is a contract, not an empty account, on every chain claimed.
2. Compare the verified source code across chains. Minor per-chain differences in constructor arguments are expected with CREATE3-style deployment; a different contract entirely is a red flag.
3. Look at who deployed it. A deterministic factory shows up as the creator of the proxy; the proxy shows up as the creator of the token. A direct deployment from a wallet means the CREATE-with-fresh-wallet method, which deserves more scrutiny.
4. Find the pool on the chain you will trade on and confirm liquidity and lock there, not on a different chain.

Why this matters more for meme coins than for most tokens

Meme coins are bought by address, fast, by people who will not read the source. The name is copied within minutes of any coin trending, and a buyer's only defense is the contract address from an official source. If a coin's address differs per chain, a scammer only needs to publish a plausible second address for a second chain. If the address is the same everywhere, there is a single fact to verify. It also removes the question of which is the real one after a launch race: the coin that was at that address on four chains is now at that address on one, with one locked pool, and nothing else at that address anywhere is the coin. For the trading side of the same problem, see meme coin snipers, where address-watching bots are the competition for the first block.