By Eco research. Updated Apr 2026.
​

A cross-L2 replayable account is a smart account or contract that shares the same address on every EVM-compatible chain, achieved through deterministic deployment using CREATE2 or a factory pattern. The term "replayable" refers to the ability to replay the same deployment transaction on any chain and arrive at an identical address. This design solves the fragmented-address problem that affects multisig wallets, protocol contracts, and smart accounts when users operate across Optimism, Arbitrum, Base, and other EVM rollups simultaneously.
​

Cross-L2 replayable accounts are smart contracts deployed to the same address on multiple EVM chains using a deterministic address derivation formula. The address is computed from the deployer contract address, a salt, and the contract's init bytecode hash. Any chain running the same factory with the same parameters produces an identical target address.
​

The concept emerged from the fragmentation of EVM state across rollups. A user whose EOA (externally owned account) is the same on every chain, because EOA addresses derive from private keys rather than deployment state, naturally expects the same property to hold for smart wallets. Without deterministic deployment, Safe multisig wallets, Kernel accounts, and Biconomy smart accounts each generate a distinct address on every chain, forcing users to manually reconcile which chain holds which address and whether the configuration at each address is consistent.
​

CREATE2, introduced in EIP-1014 in 2018, computes a contract address as keccak256(0xff || deployer_address || salt || keccak256(init_bytecode))[12:]. Holding the factory address, salt, and bytecode constant across chains produces the same 20-byte target address everywhere. The canonical Nick Johnson deterministic-deployment-proxy, at 0x4e59b44847b379578588920cA78FbF26c0B4956C, is deployed on more than 200 EVM networks and serves as the universal entry point.
​

The CREATE2 address formula requires a fixed factory address on every chain, which is the bootstrapping challenge. The canonical solution is the deterministic-deployment-proxy authored by Nick Johnson, deployed at 0x4e59b44847b379578588920cA78FbF26c0B4956C on almost every EVM mainnet and testnet. This proxy accepts a salt and init bytecode and deploys via CREATE2, making it the entry point for cross-chain deterministic deploys. The Safe protocol uses this proxy to achieve the same multisig address on every supported chain.
​

CREATE3, a pattern popularized by the 0xSequence CREATE3 library, extends CREATE2 by separating the salt from the bytecode in the address formula. A CREATE3 address depends only on the deployer address and the salt, not the init bytecode, so the contract's implementation can be upgraded without changing its address. This is useful for protocol teams deploying upgradeable proxy contracts that must share an address across chains even when the implementation differs between deployments.
​

The table below summarizes the key differences between CREATE, CREATE2, and CREATE3 for cross-chain address planning.
​

A shared address across chains reduces onboarding friction, tightens security, and enables cross-chain intent verification. When a smart account shares one address everywhere, users can receive funds on any chain without asking "which address do I have on that chain." Misconfigured signer sets on separate addresses are also eliminated, because the deployment is cryptographically tied to one init bytecode hash.
​

Security is materially improved when the address is consistent. A multisig deployed at different addresses on different chains creates a risk that the signer set or threshold differs between deployments, either through misconfiguration or an upgrade applied to one chain but not others. When the address is the same, the deployment is fully replayable and the config is cryptographically tied to the same init bytecode hash, making mismatches detectable. This is why Safe's cross-chain deployment guide explicitly recommends using the deterministic-deployment-proxy to ensure address parity before the Safe is funded on any new chain.
​

Cross-chain intent verification is the third benefit. Protocols that route user intents, signed messages specifying a desired outcome across chains, benefit from knowing that a user's account at 0xABCD on Arbitrum shares its contract configuration with 0xABCD on Base. Solvers filling cross-chain intents can verify the account's permission logic, spending limits, and owner keys by reading one address instead of maintaining a chain-specific mapping. For more on the account abstraction infrastructure that powers smart accounts, the ERC-4337 article provides foundational context.
​

ERC-7702, finalized in Ethereum's Pectra upgrade, adds smart-contract execution capability to an existing EOA by including an authorization tuple in a transaction. The EOA's address is unchanged and no new contract address is created, so the "replayable" address benefit already exists for EOAs. ERC-7702 activations must be signed per-chain using a mandatory chainId field, so smart-account behavior must be re-enabled independently on each chain.
​

EIP-7701 (native account abstraction, also called RIP-7560 when scoped to rollups) proposes a transaction type where any contract can be the "from" address without a bundler. Cross-chain address parity under EIP-7701 still depends on the same CREATE2/CREATE3 factory pattern, because the account contract must exist at the same address on each chain where a user wants to initiate transactions natively.
​

The ERC-7702 specification makes explicit that authorization tuples must be signed per-chain, so the activation is chain-specific even though the underlying EOA address is universal. This is consistent with the broader replayable accounts model: the address is universal, but each chain's activation state is managed independently by the account owner.
​

A keystore rollup is a dedicated chain that stores the authoritative configuration for a smart account: owner keys, spending limits, and module set. Rather than updating configuration on 10 chains when a key rotates, the user updates the keystore rollup once. All other chains read from that single source via cross-chain state reads or storage proofs, reducing key-rotation operations from O(chains) to O(1).
​

Vitalik Buterin's keystore migration notes, published 2023, outlined this pattern alongside Starknet's account abstraction model. Reading keystore state from another chain requires either L1SLOAD (if the keystore is an L2 anchored to Ethereum) or storage proofs for arbitrary cross-chain reads. Rhinestone's ModuleKit includes a cross-chain module registry that tracks deployed modules per address across chains, functioning as a lightweight keystore for module configuration without requiring a dedicated rollup. For background on the cryptographic proof mechanisms that underlie cross-chain state reads, the cryptographic proof explainer covers the relevant Merkle proof primitives.
​

The tradeoff with full keystore rollups is added latency: a transaction verifying the current key set from a keystore chain must either wait for an L1 settlement proof or use a storage proof path, each adding seconds to minutes of delay. For low-security or low-value accounts, a simpler replicated config is more practical. For institutional multisigs controlling large treasuries, a keystore rollup with cryptographic consistency guarantees is the more appropriate fit.
​

The main developer tools for cross-chain deterministic deployment are Safe's CLI, Rhinestone's ModuleKit, and ZeroDev's SDK. All three use the canonical deterministic-deployment-proxy at 0x4e59b44847b379578588920cA78FbF26c0B4956C, which is available on more than 200 EVM networks, and call CREATE2 with a consistent salt and bytecode to achieve address parity.
​

For teams building from scratch, the workflow has four steps:

ZeroDev's SDK exposes a deployOnAllChains helper that iterates over a user-provided chain list and fires CREATE2 deployments from the same factory address and salt. The ERC-4337 article explains how the UserOperation's initCode field triggers counterfactual deployment on first use, integrating naturally with this same factory pattern.
​

Yes. The same address guarantees that deployment bytecode and initial configuration are identical. Onchain state, such as ERC-20 balances, nonces, and storage variables, is maintained independently on each chain. Synchronizing mutable state across chains requires additional infrastructure such as a keystore rollup or cross-chain messaging. The shared address is a consistency guarantee for the contract's code, not its runtime state.
​

A collision requires the attacker to use the exact same factory address, salt, and keccak256(bytecode). Since the bytecode hash is part of the formula, using different bytecode produces a different address. Misuse of the same salt and bytecode is possible in theory but provides no financial incentive. Teams managing sensitive contracts should deploy to all target chains promptly to claim addresses before they are unused.
​

Funds sent to a counterfactual CREATE2 address before deployment are not lost; they sit at that address until the contract is deployed, at which point the contract gains access to them. If deployment never happens, funds at an undeployed address are permanently inaccessible. Most smart account frameworks trigger deployment automatically on the first UserOperation via the ERC-4337 initCode field, protecting against the "funded but never deployed" failure mode.
​

No. ERC-7702 adds smart-contract execution capability to an existing EOA by setting its code to a delegation pointer. The EOA's address is unchanged because it derives from the private key, not from a deployment transaction. The delegation must be signed per-chain to activate on each network, but the underlying address is the same everywhere.
​

Sources and methodology. CREATE2 and CREATE3 deployment mechanics verified against EIP-1014 and the deterministic-deployment-proxy repository, April 2026. ERC-7702 specification reviewed from eips.ethereum.org. Tool documentation verified against current developer docs as of Q1 2026.
​

Eco Routes operates across 15 EVM chains. When a smart account shares one address on every chain, routing logic can target a single canonical address regardless of which chain holds the user's funds at execution time, simplifying the integration surface for protocols built on Eco Routes.
​