What Is Account Abstraction? ERC-4337 vs Native AA, Explained

"Account abstraction" (AA) is one of those terms that's everywhere and rarely defined cleanly. Strip away the jargon and it's a simple idea: let a smart contract, rather than a fixed private key, decide what makes a transaction valid. That one change unlocks the wallet UX people actually want — gasless transactions, pay-fees-in-any-token, social recovery, session keys, batched actions — none of which a plain Ethereum account can do. This explainer covers what AA actually is, the two ways chains deliver it (ERC-4337 on top of Ethereum vs. native AA built into the protocol), and what it means when you're reading and sending transactions over RPC.

The starting point: EOAs vs. contract accounts

Ethereum has always had two kinds of accounts:

• Externally-owned accounts (EOAs) — controlled by a private key. If you can produce a valid ECDSA signature for the account's key, the transaction is valid. That's the only validity rule, and it's hard-coded. Your MetaMask address is an EOA.
• Contract accounts — smart contracts with code, but no key of their own. They can't initiate transactions; they only run when an EOA (or another contract) calls them.

The limitation: only EOAs can start transactions, and their validity rule is frozen — one key, one signature scheme (ECDSA/secp256k1), no custom logic. You can't say "this transaction is valid if two of three signers approve," or "if a session key signs and stays under a spending cap," or "if someone else pays the gas." The account can't hold logic.

Account abstraction erases that distinction — it makes the thing that initiates a transaction a programmable contract, so validity becomes code you write instead of a fixed key check.

What AA unlocks

Once an account is a contract that defines its own validity, a lot becomes possible:

• Gasless transactions / sponsored gas — a paymaster can pay fees on the user's behalf, so a new user can transact without first acquiring the native token. (This is the cliff that kills onboarding on most chains.)
• Pay gas in any token — fees settled in USDC instead of the native coin, since the account logic decides how fees are handled.
• Social recovery — lose your device and recover the account via trusted guardians, instead of a seed phrase being the single point of failure.
• Session keys — grant a dApp or game a temporary, scoped key (spend up to X, only these contracts, expires in an hour) so users aren't signing every action.
• Batching — do "approve + swap" (or many calls) in one atomic transaction.
• Custom signatures — multisig, passkeys/WebAuthn, or quantum-resistant schemes, because the account verifies signatures however its code says.

If those features sound familiar, it's because they're exactly what "smart account" chains advertise — AA is the machinery underneath.

Approach 1: ERC-4337 — AA without changing Ethereum

Ethereum's base protocol still requires an EOA to originate a transaction. Changing that is hard, so ERC-4337 delivers account abstraction on top of Ethereum without a consensus change, using a parallel system:

• UserOperation — instead of a normal transaction, a user signs a UserOperation object describing what they want done. It lives in a separate mempool, not the regular transaction pool (mempool refresher).
• Bundlers — actors who collect UserOperations, wrap them into a real transaction, and submit them on-chain (paying gas, reimbursed via the system). Conceptually cousins of the block-building actors in the MEV supply chain.
• EntryPoint contract — a singleton contract that verifies and executes each UserOperation against the user's smart account contract.
• Paymaster — an optional contract that agrees to pay/sponsor gas, enabling the gasless and pay-in-any-token flows.

The key RPC consequence: ERC-4337 traffic doesn't look like normal transactions. You don't send it with eth_sendRawTransaction; you submit UserOperations to a bundler via its own JSON-RPC methods (eth_sendUserOperation, eth_getUserOperationReceipt, etc.), which are provided by bundler infrastructure rather than being core node methods. Your standard eth_* calls still work for reading the resulting on-chain effects — but the submission path is separate.

Approach 2: native AA — the account model is AA

The other approach is to build account abstraction into the protocol itself, so there are no EOAs at all — every account is a smart contract from the start. No EntryPoint, no separate bundler mempool; the chain's own transaction flow understands smart accounts.

Two chains we've spotlighted show this:

• zkSync Era — native AA is a first-class part of the protocol (transaction type 113 / EIP-712), with built-in paymaster support. Accounts are contracts by default; you don't bolt on ERC-4337.
• Starknet — takes it furthest: there is no such thing as an EOA. Every account is a deployed contract with its own signature logic, you send INVOKE transactions through your account, and a new account must be DEPLOY_ACCOUNT-ed before it can transact.

A related idea shows up as fee delegation on Kaia: a native transaction type where a second party pays the gas — a protocol-level take on the "someone else covers fees" benefit that paymasters provide.

The trade-off between the approaches: ERC-4337 works on Ethereum today with no protocol change (at the cost of a parallel mempool and extra infrastructure), while native AA is cleaner and cheaper but only exists on chains designed for it.

What this means when you're building over RPC

A few practical takeaways:

• The sender may not be who paid. With a paymaster, the address that funded gas differs from the user acting. If you attribute activity or costs by fee-payer, AA will surprise you — read the transaction receipt carefully to see what actually happened.
• Submission paths differ. For ERC-4337, transactions enter via a bundler's eth_sendUserOperation, not eth_sendRawTransaction. For native-AA chains, you use that chain's account-aware transaction type/flow (e.g. Starknet's INVOKE).
• Nonce assumptions may not hold. Smart accounts can implement their own nonce/replay schemes, and batching means "one transaction" can contain many actions — so the strict one-key-one-lane model from nonce management is an EOA property, not a universal one.
• Reading state is unchanged. Balances, logs, and receipts still come from ordinary eth_* reads; AA changes how transactions are authorized and submitted, not how you query results.

The short version

Account abstraction makes the thing that initiates a transaction a programmable smart contract instead of a fixed private key — so your code defines what makes a transaction valid. That unlocks gasless/sponsored gas, pay-fees-in-any-token, social recovery, session keys, batching, and custom signature schemes. Two delivery models: ERC-4337 adds AA on top of unmodified Ethereum via UserOperations, bundlers, an EntryPoint, and paymasters (submission goes through a bundler, not eth_sendRawTransaction); native AA builds it into the protocol so every account is a contract and there are no EOAs — as on zkSync Era and Starknet. When building, remember the fee-payer may differ from the user, submission paths differ, and nonce assumptions are an EOA thing — but reading on-chain results stays plain eth_*.

Building smart-account apps across chains? A flat-rate Ethereum RPC endpoint — plus 75+ other chains including zkSync Era and Starknet under one key — gives you the reads your AA stack needs over HTTP and WebSocket. Grab a free key and point your stack at:

https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY

---

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.