A cross-chain smart account is a single account identity that operates on multiple blockchains, sharing permissions, recovery rules, and execution policy across every chain it touches. Instead of holding a separate wallet, signing key, and balance on each network, a user controls one account whose state and authorizations apply everywhere. Cross-chain smart accounts compose four Ethereum standards: ERC-4337 account abstraction, ERC-7579 modular account interfaces, ERC-7715 wallet permissions, and ERC-7964 cross-chain signatures. Rhinestone Omni Accounts is the canonical implementation that ties these standards into a working framework, with Safe, Biconomy Nexus, and ZeroDev Kernel offering parallel approaches. This article explains what cross-chain smart accounts are, how they work end to end, the standards stack underneath them, and the trade-offs every team should understand before building.
​

An externally owned account (EOA) is bound to a single private key and exists at the same address on every EVM chain, but its nonces, allowances, and history are isolated per chain. A smart account is a contract account, deployed per chain, that can hold programmable validation logic, session keys, and module hooks. A cross-chain smart account is a smart account whose authorization surface, intent execution, and recovery span multiple chains as if it were one account.
​

Three properties distinguish the category from earlier multi-chain wallets. First, signature portability: one signature authorizes execution on a different chain than the one the user signed on. Second, shared permission state: a session key issued on Ethereum can be honored by the same account on Base or Arbitrum without re-signing. Third, intent-based execution: the user states a desired outcome ("swap 1,000 USDC on Arbitrum for ETH on Base") and a solver network produces the underlying transactions across chains.
​

Reference points for scale: Ethereum holds $45.8B in TVL across DeFi protocols, Base $4.4B, Arbitrum $1.7B, and Solana $5.5B, per DeFiLlama chain rankings. Each is a separate execution environment that a cross-chain smart account stitches together for the user.
​

Before account abstraction landed in production, every chain treated wallets as independent. A user with funds on Ethereum, Base, and Polygon held three EOAs (often the same address, controlled by the same key) but had to manage three nonces, three gas balances, and three sets of token approvals. Bridging required signing on the source chain, waiting for finality, and signing again on the destination chain. Recovery was a per-chain problem: if a key was compromised, the user revoked allowances chain by chain.
​

Smart contract wallets like Safe reduced some of this friction by adding multisig and modular logic, but each Safe deployment was still a separate account. A user with a Safe on Ethereum and a Safe on Polygon had two accounts, often with different owner sets and nonce counters. Session keys, social recovery, and spending limits all had to be configured twice.
​

The user-experience cost showed up in conversion. A 2025 Ramp study reported in their UX research notes found that more than half of new wallet users abandoned cross-chain flows when prompted to switch networks more than once. Cross-chain smart accounts collapse that friction into a single signing event.
​

The architecture has four layers: a base smart account, a set of modules, an off-chain orchestrator, and a solver network. Each layer leans on a specific Ethereum standard.
​

The base account is either an ERC-4337 contract account or an EIP-7702 upgraded EOA. ERC-4337 introduced UserOperations, a transaction-shaped struct that bundlers route through the EntryPoint contract. ERC-4337 account abstraction made smart accounts viable without protocol changes. EIP-7702, live on mainnet since the Pectra upgrade, lets a regular EOA temporarily delegate to contract code, giving plain keys access to smart-account features without migrating addresses. EIP-4337 vs EIP-7702 trade-offs determine which path a wallet team picks.
​

ERC-7579 standardizes how validators, executors, fallback handlers, and hooks plug into a smart account. It was authored by Rhinestone, Biconomy, ZeroDev, and OKX to keep modules portable across account implementations. A validator written for a Safe with the ERC-7579 adapter also works on Biconomy Nexus and ZeroDev Kernel. Read ERC-7579 modular smart accounts for the full interface specification.
​

ERC-7715 lets a wallet grant scoped permissions to a third party: a session key valid for 24 hours, a spending limit of 500 USDC per day, a contract-address allowlist. The grant is stored as account state and queried by the validator on every UserOperation. ERC-7715 wallet permissions explains how the grant lifecycle works.
​

ERC-7964 defines a signature envelope that explicitly binds a UserOperation to a target chain ID and account address. Without it, a signature valid on Ethereum could be replayed on Optimism if both chains hosted the same account address. ERC-7964 makes cross-chain authorization safe by including the destination chain in the signed payload. ERC-7964 cross-chain signatures covers replay protection in detail.
​

The off-chain orchestrator tracks pending intents and prevents double-spends across chains. When a user signs a cross-chain intent, the orchestrator publishes it to a solver network. Solvers compete to execute: one solver fronts capital on the destination chain, fills the user's intent, and later claims reimbursement from the source-chain account through a settlement contract. The same architecture underpins intent-based architecture for solver networks.
​

The four standards compose into a layered protocol. ERC-4337 supplies the account and bundler infrastructure. ERC-7579 supplies the module interface so validators and executors are portable. ERC-7715 supplies scoped permission state. ERC-7964 supplies the signature format for cross-chain execution.
​

A working cross-chain smart account requires all four. ERC-4337 alone gives smart-account features on one chain. Adding ERC-7579 makes modules portable. Adding ERC-7715 turns permissions into shared state. Adding ERC-7964 makes signatures safe to honor on a chain different from the one they were signed on.
​

Adjacent standards extend the stack. ERC-7802 cross-chain token standard defines how tokens move alongside intents. ERC-7683 cross-chain intents standardizes the intent format itself, so multiple settlement layers can read the same payload. Bundler networks for smart accounts covers the mempool layer that publishes UserOperations.
​

Several frameworks implement the standards stack with different trade-offs. The four most established are Rhinestone Omni Accounts, Safe with cross-chain modules, ZeroDev Kernel, and Coinbase Smart Wallet.
​

Rhinestone Omni Accounts is the reference implementation that pulls every layer together. The base is any ERC-7579 account or EIP-7702 EOA. The Resource Lock Hook module turns the account into a chain-abstracted account: a single ERC-712 signature encodes a multi-chain intent, the orchestrator locks the source-chain funds, and a solver fills on the destination chain. Rhinestone supports Safe, Biconomy Nexus, and Magic Newton accounts as base accounts. The framework is documented at Rhinestone developer docs and the source modules are at Rhinestone GitHub.
​

Safe is the most-deployed smart account framework, with more than $100B in cumulative on-chain assets across deployments according to Safe's transparency page. Safe added an ERC-7579 adapter in 2024 so any 7579 module, including Rhinestone's Resource Lock Hook, runs on a Safe account. Safe's ERC-7579 documentation covers the integration.
​

ZeroDev Kernel is a modular account built natively on ERC-7579 with focus on developer ergonomics. Kernel ships SDK helpers for session keys, gas sponsorship, and recovery. ZeroDev's cross-chain extensions reuse Rhinestone's orchestrator and add a SaaS layer for paymaster and bundler infrastructure. Read the ZeroDev Kernel documentation for SDK reference.
​

Coinbase Smart Wallet is a passkey-based ERC-4337 account that ships across all Superchain networks (Base, Optimism, and OP Stack rollups) with a unified address. It is not a full cross-chain smart account in the ERC-7964 sense yet, but it offers shared identity and recovery across the Superchain. Coinbase Smart Wallet is now the default wallet for new Coinbase Onchain users.
​

Trust Wallet's smart account approach uses ERC-4337 for EVM chains and a parallel passkey-based architecture for Solana. Phantom embeds a smart account inside its mobile wallet, with session keys for in-app DeFi flows. Both treat cross-chain functionality as a routing layer on top of the smart account, rather than encoding cross-chain authorization into the signature itself.
​

Cross-chain smart accounts unlock four categories of UX that single-chain accounts cannot deliver.
​

An autonomous agent or trading bot can hold a session key valid on Base, Arbitrum, and Polygon at once. The user signs once on Ethereum to grant a 7-day, 5,000 USDC budget. The agent executes on whichever chain has the best price for the next minute, with no further user input. Account abstraction for stablecoin apps covers session-key UX patterns.
​

Social recovery replaces a lost or compromised key with a new one across every chain in a single transaction. Without cross-chain accounts, a user with funds on five chains had to run the recovery flow five times, paying gas on each.
​

The wallet UI can present a single balance: USDT $189.6B market cap, USDC $77.6B, your portion across all chains. Cross-chain accounts let the wallet treat the multi-chain balance as one number for display and for spending decisions. The unified view depends on accurate per-chain indexing; chain abstraction vs multi-chain vs cross-chain explains the abstraction levels.
​

A game running on Base can request a session key that also works on Optimism for cross-game asset transfers. The user grants once; the validator on each chain honors the grant via shared ERC-7715 state.
​

A user holds 1,000 USDC on Ethereum and wants to swap into ETH on Arbitrum, then bridge half the ETH to Base for a yield position. With a single-chain wallet, this is three transactions, three signatures, and roughly three to ten minutes of bridging time.
​

With a cross-chain smart account: the user signs one ERC-7964 envelope describing the desired end state — 0.2 ETH on Arbitrum and 0.2 ETH on Base. The signature is published to the orchestrator. A solver fronts the ETH on both destination chains within seconds. After the user's transactions confirm on Ethereum, the orchestrator releases the 1,000 USDC to the solver to repay the float. Total user actions: one signature. Total elapsed time: 30 to 60 seconds depending on solver liquidity. Solver netting explains how solvers reduce the underlying bridge hops.
​

Cross-chain smart accounts add new surface area. Three risk categories matter.
​

The validator module that authorizes cross-chain UserOperations is itself a smart contract. A bug in the validator can authorize unintended transactions on every chain the account uses. Modules require formal verification and conservative upgrade paths. Rhinestone publishes audits at Rhinestone GitHub; Safe's audit history is on Safe's audit page.
​

Without ERC-7964, signatures created for one chain can replay on another if both host the same account address. ERC-7964 closes the gap by including chain ID in the signed payload. Frameworks that pre-date ERC-7964 must apply chain-binding manually, which is error-prone.
​

Most cross-chain smart account implementations rely on a centralized orchestrator and a permissioned solver set. If the orchestrator goes down, pending intents stall. If a solver collusion forms, fills get worse. Decentralization roadmaps for these components vary; ERC-7683 and competing settlement layers like intent settlement layers are the long-term hedge.
​

Cross-chain smart accounts pair naturally with intent-based execution. The account provides the authorization surface; the intent network provides the execution. Across, deBridge, and other intent-based bridges are settlement layers that read intents produced by cross-chain accounts. The boundary is clean: account state lives on-chain in ERC-7579 modules; intent execution lives in solver networks. The intent stack 2026 maps wallet, solver, and settlement layers.
​

Eco Routes is the execution layer for stablecoin movements that cross-chain smart accounts trigger. When a Rhinestone Omni Account or Safe-with-7579 account signs an intent to move USDC from Ethereum to Base, Eco Routes selects the path: Circle CCTP for native-USDC burn-and-mint, Hyperlane for fast permissionless messaging, or a solver fill against an Eco-managed pool. The smart account holds the user's authorization; Eco Routes turns the authorization into settled stablecoin movement across 15 supported chains.
​

Teams building cross-chain smart account products need a settlement layer that abstracts which rail to use for each token movement. Eco provides that layer for stablecoins. A wallet, agent, or app that adopts ERC-7579 and ERC-7964 can call Eco's intent API and let the network pick CCTP, Hyperlane, or solver execution based on cost, finality, and current liquidity. The smart account handles authorization and permissions; Eco handles routing and settlement. Stablecoin routing where intents replace bridges covers the integration shape.
​

Chain abstraction is the user-experience goal: hide the multi-chain nature of the system. Cross-chain smart accounts are one way to deliver chain abstraction, by giving the account itself a multi-chain authorization surface. Other approaches, like meta-aggregator UIs, deliver chain abstraction without changing the account model.
​

Yes, through EIP-7702. An EOA upgraded with EIP-7702 can run any ERC-7579 module, including cross-chain validators. The user keeps the same address and private key but gains smart-account features. Read EIP-7702 explained for the upgrade flow.
​

Any EVM chain that supports ERC-4337 and the EntryPoint contract can host a cross-chain smart account. As of Q1 2026 that includes Ethereum, Base, Arbitrum, Optimism, Polygon, BSC, Avalanche, and most major rollups. Solana support exists through alternative architectures, not the EVM standards stack.
​

A multisig requires multiple signers per transaction, on a single chain. A cross-chain smart account requires one signer (or one set of permissions) and authorizes execution across multiple chains. The two compose: a Safe multisig deployed on Ethereum can hold an ERC-7579 cross-chain validator, giving the same multisig identity execution rights on every chain.
​

A bridge moves tokens or messages between chains. A cross-chain smart account is the authorization layer for those movements. The smart account decides who can move what and where; the bridge or intent network actually moves it. Bridges are infrastructure; smart accounts are identity.
​