When a wallet or a bridge spans more than one chain, what is actually holding it together, and who has to be deployed, funded, or online for that to stay true?
No single state holds it together. What we call a multichain system is a set of single-chain systems joined at seams, and every seam depends on somebody's deployment, inventory, or uptime. Every cross-chain design redistributes risk; none removes it. So the question is never which architecture is safest, but which seam you end up owning and whether it fails loudly enough for anyone to notice. The product narrative runs the other way: unified liquidity layers and delegation standards will eventually reduce the seam to an implementation detail. I think the seam is the thing itself.
The account side shows this most cleanly, because there the seam is invisible by construction. CREATE2 produces the same smart account address across EVM chains when the deployer address, salt, and init code are identical. The address can be the same. The deployment and state are not. On one chain the account exists with guardians configured; on another there may be no bytecode at that address at all. Run recovery there and the call reaches nothing, reverting or silently succeeding depending on the call path. You cannot recover what does not exist.
We tried four ways out and none held. Pre-deploying everywhere wastes gas and still misses chains added later. Merkle roots of guardians solve information availability, not existence. A registry adds latency and a new failure point while the account stays undeployed. Scoping recovery to deployed chains is honest and a worse experience. Where we landed: guardians per chain, recovery only where the account exists, and a deployment map visible in the UI. Key backup covers loss of access; it is not recovery from compromise.
EIP-7702 changes the deployment ergonomics, not the state model. It can make an EOA execute delegated code and even permits chain-agnostic authorizations, but every chain still processes the authorization separately and maintains its own delegation, nonce, and storage. Recovery state does not become global. Unsupported chains add another fallback path; supported chains remain separate state machines. Propagating recovery through cross-chain messaging makes account recovery conditional on bridge availability precisely when an independent recovery path is most valuable.
The bridge side has the same shape with different collateral: LP pools depend on inventory, lock-and-mint on trust and asset identity, intents on solver availability, hybrids on external dependencies. None is universally safest, so I rank them by failure legibility. A dry pool errors. Thin solver participation widens quotes and slows fills; I have seen a degraded solver fill orders at 2 to 3 percent worse rates for hours before anyone noticed.
Even the clean failure path has an owner. For approved integrations, deBridge DLN can automatically cancel an unfilled market order after a timeout and return funds on the source chain. That is a legible failure, and not a trustless one: cancellation overrides the destination order authority to a deBridge-controlled address, and the returned funds are generally not the asset originally sent — usually USDC.
On February 1, 2026, CrossCurve was exploited through a publicly callable express-execution path. Published loss estimates ranged from about $1.4 million to $3 million. The receiving contract inherited Axelar's AxelarExpressExecutable base without overriding its public entry point, and a "1 of 2" confirmation scheme chosen to save gas left the second confirmation off the path entirely. The contracts had been audited and their source code verified on block explorers. Neither fact established that the integration path was safe, which is the general point: review is scoped to components while risk accumulates at joins.
The account layer fails the same way. A Kernel account does not return a plain 65-byte ECDSA signature: the leading bytes encode a validation mode and type, and on the validator path a 20-byte validator address sits ahead of the inner signature. An integrator that assumes ECDSA and reaches for ecrecover does not get a clean failure — it gets a revert on length, or a plausible-looking wrong address — and the order is rejected before it ever reaches the contract path that would have validated it. ERC-1271 is the correct interface; adoption remains uneven.
One thing this page should not pretend. Bridge architectures are substitutable, so failure legibility is a useful ranking criterion. Wallets are not ranked on that axis alone: chain coverage, recovery assumptions, and on-chain enforcement choose the model, often MPC for key management and smart accounts where rules must bind at the asset layer. The shared unit of analysis is the seam, not the ranking criterion.
What would change my mind
Independent chains having a boundary is definitional. The contestable claim is that the boundary remains a user-visible, non-substitutable security and availability constraint.
I would revise that claim if one recovery authorization could instantiate or update the same recovery policy on a previously unused supported chain, without prior deployment, pre-funding, or a weaker fallback. On the bridge side, show a system completing transfers within stated price and time bounds when any one messaging provider, solver set, or liquidity source is unavailable, without manual rescue or a change in asset identity.
If both properties hold across heterogeneous chains and repeated provider failures, the seam has become a substitutable implementation detail rather than the architecture's binding constraint.