One address, many chains: EVM networks and "sent on the wrong network"

Copy an address from a typical Ethereum wallet, switch to Polygon, and the address doesn't change. The same 0x… string works on BNB Smart Chain, Avalanche and Base too. That's convenient, and it's behind a whole category of mistakes: funds "sent on the wrong network".

Whether those funds can be recovered depends on one question: is the address a plain key-controlled account, or a smart contract? Here's why, and what it means for SSP.

Why EVM addresses look the same everywhere

Ethereum, Polygon, BNB Smart Chain, Avalanche C-Chain, Base, Arbitrum and many others all run the Ethereum Virtual Machine and share the same address format: 20 bytes, written as 0x followed by 40 hex characters.

For a normal account — an externally owned account, or EOA — the address is derived from a public key alone. Nothing about the network goes into it. The same private key produces the same address on every EVM chain, and that key can sign transactions on all of them.

So the address alone can't tell anyone which network a payment is meant for. The address says who; the network is a separate choice made when sending.

What "sent on the wrong network" means

Say you ask for USDC on Polygon, but the sender withdraws from an exchange using Base. The transaction succeeds — on Base. Your wallet, looking at Polygon, shows nothing.

The funds aren't in limbo; they're at your address on Base. The question is whether you control that address on Base.

Address formats and why sends fail covers the wider family of failed sends; this one is specific to networks that share an address format.

EOAs: usually recoverable

If the address is a normal EOA, the answer is almost always yes. Your private key controls that address on every EVM chain. Add the network to a wallet that holds the same key and the balance appears. You'll need a little of that network's native coin for gas before you can move it.

The main exception is an exchange deposit address: the exchange holds those keys, so recovery is up to them.

Smart-contract wallets: it depends on the contract

A smart-contract wallet is different. Its address belongs to a contract, and a contract exists only on chains where it has been deployed. Your key isn't the address; it's what the contract checks before moving funds.

Many smart wallets, including ERC-4337 accounts, use counterfactual addresses computed with CREATE2. The address is fixed in advance from the factory contract's address, a salt and the account's setup data, so it can receive funds before the contract is deployed on that chain.

That gives three cases when funds arrive on another chain:

• The same factory exists there. The same contract could be deployed at the same address, and the funds could be moved — if your wallet supports that chain.
• The factory doesn't exist there. Nothing can be deployed at that address until someone deploys an identical factory at the identical address, which isn't always possible and is never something to assume.
• Your wallet doesn't support the chain. Even if the contract could exist, you need software that can sign for it there.

EOA vs smart account goes into the broader trade-offs.

How this works in SSP

SSP's EVM vaults are ERC-4337 smart accounts, approved by both SSP Wallet and SSP Key. EVM multisig, the account-abstraction way explains the design. A few facts from the code matter here:

• The address is counterfactual. SSP Wallet computes the vault address offline with CREATE2 from the factory address, salts and your two keys. The network ID isn't part of that calculation.
• The same factory is on every supported chain. It was deployed at one address on Ethereum, Polygon, BNB Smart Chain, Avalanche and Base (plus the Sepolia and Amoy testnets) using the standard deterministic deployment proxy.
• But each network uses its own keys. SSP derives keys per network, with a different coin type for each. So your SSP vault address on Polygon is not the same as your vault address on Ethereum. Always copy the receive address from the network you actually want to use.

What happens if someone sends to your SSP address on the wrong network?

• Another SSP-supported EVM chain. For example, POL sent on Polygon to your Ethereum vault address. On Polygon, that address belongs to an account built from the same factory with keys you hold — but SSP Wallet tracks only your Polygon vault, so it won't show those funds. Recovery is possible in principle, but SSP has no built-in tool for it.
• A chain SSP doesn't support, such as Arbitrum or Optimism. SSP's factory isn't deployed there, and SSP can't sign there. Treat these funds as possibly lost. Recovery could only come from deploying the same contracts there at the same addresses, which isn't something to count on.

Habits that prevent it

• Agree on the network before agreeing on the address, and say it in words: "USDC on Base".
• Copy the address from your wallet while it's set to that network. In SSP, switch chains first, then open Receive.
• When withdrawing from an exchange, check the network dropdown as carefully as the address.
• Send a small test amount first with a new network or counterparty.

Using SSP on Polygon, Base and other EVM chains shows how to switch networks in SSP.

The honest summary

EVM chains share one address format, so one string can be valid on many networks. With a normal EOA, wrong-network funds are usually recoverable: the same key controls the address everywhere.

Smart-contract wallets only work where the contract is, or can be, deployed and where your wallet can sign. SSP's vaults are smart accounts with a separate address on each supported network. Funds sent to an SSP address on the wrong supported network won't show up, and SSP has no recovery tool; funds sent on a network SSP doesn't support may be lost. Check the network every time.