Account Abstraction Beyond Ethereum

Account abstraction is often introduced as an Ethereum story — a way to turn a single-key wallet into a programmable smart account using ERC-4337. But the idea does not stop at Ethereum L1. It travels two very different ways: outward across the EVM chains that share Ethereum's execution model, and natively into chains that were designed with account abstraction baked into the protocol from day one. This article maps that wider landscape, explains how native account abstraction differs from the ERC-4337 standard layered on top of Ethereum, and is careful about one boundary in particular: where the general ecosystem ends and what SSP actually supports begins.

This is the final article in our account abstraction series. If the core concepts are new, start with Account Abstraction from First Principles, then compare the two account models in EOA vs Smart Account: The Differences That Matter. Here we assume you know roughly what a smart account is and zoom out to the rest of crypto.

The same standard, everywhere the EVM runs

The first way account abstraction spreads is the simplest: it rides along with the EVM. ERC-4337 is not a base-protocol change. It is a contract-level standard built on an EntryPoint contract, UserOperation objects, bundlers, and optional paymasters — none of which require consensus modifications. That design choice has a powerful consequence. Any chain that runs the Ethereum Virtual Machine can host the same EntryPoint, the same bundler infrastructure, and the same smart-account contracts.

That is exactly why the major EVM L2s and sidechains support ERC-4337 the same way Ethereum does:

• Polygon runs the EVM, so the identical smart-account contract and EntryPoint deploy without modification.
• Base is an EVM L2 where ERC-4337 account abstraction works the same as on L1.
• BNB Smart Chain is EVM-compatible and hosts the same standard.
• Avalanche C-Chain runs the EVM and supports the same contract-level account abstraction.

Because the standard is portable, a wallet's smart-account logic written for Ethereum carries over to these chains essentially unchanged. This portability is precisely what lets SSP run its design across every EVM chain it supports — the same 2-of-2 contract behaves identically whether it is deployed on Ethereum, Polygon, Base, BNB Smart Chain, or Avalanche. For the practical, per-chain view of using SSP across these networks, see Using SSP on Polygon, Base, and Other EVM Chains.

Native account abstraction: when it is the protocol, not a layer

The second way account abstraction spreads is fundamentally different. Some chains did not wait for an opt-in standard — they built account abstraction directly into the protocol, so there is no "EOA versus smart account" distinction at all. Every account is a smart account by default.

Starknet: every account is a contract

Starknet has had account abstraction from day one. On Starknet there are no externally owned accounts in the Ethereum sense; every account is a contract account, written in the Cairo language. Because account behavior is defined by contract code at the protocol level, signature schemes, validation rules, multisig, and fee logic are properties of the account itself rather than features bolted on afterward.

The contrast with Ethereum is instructive. On Ethereum, the default account is an EOA with one hard-wired ECDSA check, and ERC-4337 exists to layer programmable accounts on top without a hard fork. On Starknet, there is nothing to layer on — the programmable account is the baseline. There is no separate EntryPoint standard to adopt because account abstraction is not optional. The Starknet documentation at docs.starknet.io describes this account model in detail.

zkSync Era: native AA with built-in paymasters

zkSync Era takes a similar protocol-native approach. Account abstraction is part of the protocol rather than an add-on, and the system includes built-in paymaster support at the protocol level. On Ethereum, a paymaster is a contract defined by the ERC-4337 standard and routed through the EntryPoint; on zkSync Era, paymaster functionality is a first-class feature of the chain itself, so sponsoring fees or paying gas in another token is part of how the network is designed to work. The zkSync documentation covers its native account abstraction and paymaster model.

Native AA versus ERC-4337: the core difference

It is worth stating the distinction plainly, because it is the conceptual heart of this article:

• ERC-4337 is an opt-in standard layered on top of an unchanged protocol. Ethereum's base layer still only natively understands EOAs and their single ECDSA signature. Smart accounts exist because developers agreed on a shared set of off-chain and on-chain components — the EntryPoint, the alternative mempool, bundlers — that simulate protocol-level account abstraction without a consensus change. It is brilliant precisely because it required no hard fork, and it is portable to every EVM chain for the same reason.
• Native account abstraction is built into the protocol. On Starknet and zkSync Era, the chain itself treats every account as programmable. There is no opt-in, no separate standard to adopt, and no distinction between a "normal" account and a smart one — the smart account is the account.

Both deliver the same end-user benefits: multiple signers, custom validation, recovery logic, and flexible gas. They simply arrive from opposite directions — one as a carefully engineered layer, the other as a foundational protocol decision. If you want the formal specification of the layered approach, EIP-4337 is the canonical reference.

Where SSP fits — and where it does not

This is the boundary to be precise about. SSP is a self-custodial wallet built around 2-of-2 multisig: one key in the SSP Wallet browser extension, the second in the SSP Key mobile app, with neither device able to move funds alone. On EVM chains, SSP implements that as an ERC-4337 smart account whose validation logic verifies a single Schnorr-aggregated signature built from both keys. SSP's smart contracts were audited by Halborn in 2025.

Because ERC-4337 is portable across the EVM, SSP's approach carries across the EVM chains it supports: Ethereum, Polygon, Base, BNB Smart Chain, and Avalanche C-Chain. The same 2-of-2 smart-account contract runs on all of them.

Starknet and zkSync Era appear in this article as the broader ecosystem — examples of chains where account abstraction is native to the protocol. They are not part of SSP's supported chain set. SSP brings ERC-4337 account abstraction to the EVM chains listed above; it does not run on Starknet, zkSync Era, or other non-EVM chains. When you read about native AA elsewhere in crypto, treat it as context for how widespread the smart-account model has become, not as a claim about where SSP operates.

Why this matters

Step back and the pattern is clear: the smart-account experience is becoming the default across much of crypto, not a niche feature for power users.

• On the EVM, ERC-4337 brings programmable accounts to Ethereum and every compatible chain without a hard fork, which is what makes a wallet like SSP able to offer the same 2-of-2 security on Polygon, Base, BNB Smart Chain, and Avalanche that it offers on Ethereum.
• On natively-abstracted chains, the question "is this an EOA or a smart account?" simply does not arise, because there is only one kind of account and it is programmable.

For a self-custody user, the takeaway is that the rigid single-key model is no longer the only option, and increasingly is not the default one. Whether account abstraction arrives as a layered standard or a native protocol feature, the destination is the same: accounts you can program, with security rules — like SSP's two-device multisig — that a single private key could never enforce on its own. To revisit how that model compares to the original Ethereum account, see EOA vs Smart Account: The Differences That Matter, and for the standard in isolation, What Is Account Abstraction (ERC-4337)?.