If you ship the same protocol to Ethereum, Base, Arbitrum, Optimism and a handful of other EVM chains, you quickly hit an annoying problem: your contract has a different address on every chain.

That happens because the default deployment opcode, CREATE, derives the new contract's address from the deployer account and its nonce:

address = keccak256(rlp(deployer, nonce))[12:]

The moment your deployer's nonce differs between chains (a failed transaction here, an extra deployment there), the addresses diverge. Different addresses across chains means:

• Integrations break. Every partner, frontend, subgraph and config file needs a per-chain address map.
• Users get confused. The contract they trust on mainnet looks like a stranger on an L2.
• Security gets harder. Address allowlists, signature domains and cross-chain tooling all become more error-prone.

Teams want the opposite: one canonical address, identical on every chain.

From CREATE to CREATE2 to CREATE3

CREATE2 was the first fix. It drops the nonce and derives the address from the deployer, a chosen salt, and the hash of your contract's init code:

address = keccak256(0xff ++ deployer ++ salt ++ keccak256(initCode))[12:]

Pick the same deployer, salt and bytecode on every chain and you get the same address everywhere. The catch: the address still depends on the exact bytecode. Change a constructor argument, bump the compiler, or alter a single byte of metadata and the address moves. For multichain deploys where constructor arguments legitimately differ per chain, that is a real constraint.

CREATE3 removes the bytecode from the equation. It deploys a tiny proxy with CREATE2, then has that proxy deploy your contract, so the final address depends on only the deployer and the salt:

address = f(deployer, salt)   // independent of your bytecode

Same salt, same address on every chain, even if the contract you deploy there has different constructor arguments or bytecode. This is the property that makes clean multichain deployments possible, and it is why factories like CreateX (0xba5Ed0…) ship CREATE3 helpers.

How ManyZeros gives you a vanity address that's identical everywhere

ManyZeros is a CREATE3-style deterministic factory with one extra property: the address is vanity-mined for leading zeros before you ever deploy.

The factory contract, VanityMarket, lives at the same address on every chain: 0x000000000000b361194cfe6312EE3210d53C15AA. Your contract's address is derived from a token you own (its id encodes the owner plus a 12-byte extension), not from your contract's bytecode. So:

1. You acquire an address token: buy a pre-mined leading-zero one, or request a custom pattern that is GPU-mined for you.
2. You deploy by handing your init code to the factory, burning the token to deploy your contract to that address:

import {MANY_ZEROS} from "manyzeros-foundry/IManyZeros.sol";

// The same call on Ethereum, Base, Arbitrum, Optimism, …
address myContract = MANY_ZEROS.deploy(id, initcode);

Because the factory is identical on every chain and the address comes from the token id rather than your bytecode, deploying the same token id on any chain lands your contract at the same address, proxy or not, whatever constructor arguments you pass.

Trustless, and no bridges

You buy the token on Ethereum mainnet, where the purchase is fully trustless: once the token is minted to you, nobody (not even us) can reassign it.

To use the address on another chain, the site gives you a chain-independent authorization signature. A signature valid on one chain is valid on all of them, so you claim and deploy on L2s without trusting a bridge. The authorization is granted after a short delay, to protect against Ethereum reorgs.

A canonical address that also looks the part

Because the address is mined for leading zeros, your one cross-chain address is also a recognizable, professional-looking address, the same signal used by OpenSea's Seaport (0x0000000000000068…), the 1inch token (0x111111…) and others. Across every chain, users and integrators see the same distinctive address and know it is you.

There is a modest gas bonus too: leading zero bytes are cheaper to use in calldata and can help you pack storage. It is real but small, and we measure exactly how much in the gas savings guide. The cross-chain determinism and recognizability are the reasons that actually move the needle.