ERC-4337 has been live on Ethereum mainnet since March 2023. Adoption has been slower than its proponents expected, faster than its critics predicted. The interesting question for teams building cross-chain protocols isn't whether account abstraction is useful — it obviously is. The interesting question is what it means for how cross-chain operations work.
We've been working through the practical implications for the Defimec routing layer over the past year. This is what we've found.
The quick ERC-4337 summary
ERC-4337 introduces a new transaction type called a UserOperation. Instead of a transaction signed by an externally owned account (EOA) being submitted directly to the mempool, UserOperations are submitted to a separate mempool and processed by entities called bundlers. Bundlers package UserOperations into regular Ethereum transactions and submit them on behalf of users.
The key innovation: account logic is moved into a smart contract (the smart account). This means things that previously required protocol-level changes — multi-sig authorization, social recovery, session keys, sponsored gas payments — can now be implemented as smart contract logic without needing Ethereum to change.
What this changes for cross-chain UX
The most significant change for cross-chain applications is gas abstraction. Currently, a user initiating a multi-chain operation needs to hold native tokens on every chain to pay gas. Moving from Ethereum to Avalanche requires ETH on Ethereum and AVAX on Avalanche. For non-technical users, managing gas tokens across chains is a real barrier.
ERC-4337's paymaster mechanism allows gas to be paid in any token, or paid on behalf of users by a third party. When combined with cross-chain messaging, it becomes possible to design flows where a user authorizes an operation on one chain and the protocol handles gas on all destination chains automatically.
We've implemented a version of this in the Defimec SDK. Users with smart accounts can initiate cross-chain transfers and authorize gas payment in USDC — the protocol converts and forwards native gas tokens as needed on each chain. The end-user experience is a single action with no manual gas management.
The new risks
Account abstraction introduces risks that didn't exist with EOA-based accounts. The most significant ones for cross-chain applications:
| Risk | Description | Mitigation |
|---|---|---|
| Validation logic bugs | Errors in custom validation logic can allow unauthorized operations or block legitimate ones | Minimal custom validation; use audited reference implementations where possible |
| Bundler censorship | Bundlers can selectively exclude UserOperations — no permissionless guarantee | Use multiple bundlers; design operations to be bundler-agnostic |
| Paymaster failure | If a paymaster is out of funds or unresponsive, gas-sponsored operations fail | Fallback to user-paid gas path; monitor paymaster balance proactively |
| Session key scope creep | Overly broad session key permissions create large blast radius if compromised | Strict permission scoping; time limits on all session keys |
Cross-chain account abstraction — the harder problem
ERC-4337 is Ethereum-specific. Other chains have their own account abstraction implementations, and they're not all compatible. Starknet has native account abstraction. Solana has a different model entirely. BNB Chain has ERC-4337 support, but Solana doesn't.
For truly cross-chain account abstraction — where a single account identity and authorization model works across all chains — there is no complete solution yet. The most promising approaches involve cross-chain messaging to synchronize account state, but the security assumptions are complex.
The hardest part of cross-chain account abstraction isn't the technical implementation. It's deciding what "the same account" means when each chain has different execution semantics, different finality, and different fee mechanisms.
Our current approach is pragmatic: we support ERC-4337 smart accounts on EVM-compatible chains and provide simplified (but not unified) account models on non-EVM chains. Full cross-chain account unification is a longer-term goal, not a current product feature.
What to adopt now vs. what to wait on
If you're building cross-chain applications today, the most mature and safe parts of ERC-4337 to adopt are:
- Gas sponsorship via paymasters — well-tested, standardized implementations available
- Batch transactions — bundle multiple operations into a single UserOperation
- Session keys with strict scoping — for improving UX in specific, well-defined flows
Areas where we'd be more cautious:
- Custom validation logic — high audit surface, easy to get wrong
- Cross-chain account synchronization — no mature standard yet
- Social recovery schemes for high-value accounts — recovery paths are complex to audit
Account abstraction is one of the more genuinely useful Ethereum improvements in years. The cross-chain layer is still catching up. Build on the mature parts, watch the experimental parts carefully, and don't let UX improvements create security regressions you haven't thought through.
