How Ethereum accounts work under the hood

Ethereum uses two types of accounts: externally owned accounts (EOAs) and contract accounts. EOAs are controlled by private keys and are used by individuals or applications to sign transactions. These accounts are simple in structure. They include a nonce, balance, and associated public key but no internal code. When a user signs a transaction from an EOA, the Ethereum Virtual Machine (EVM) verifies the signature and deducts the gas fee before executing the transaction. Contract accounts, in contrast, are controlled by code and do not initiate actions on their own. They only respond to transactions triggered by EOAs. The EVM processes contract logic and stores state, but a contract cannot sign transactions independently or initiate them without external input.

This architecture limits the functionality of accounts on Ethereum. Since all activity must originate from EOAs and every transaction requires a valid cryptographic signature, advanced features such as multi-factor authentication, social recovery, and batched operations require complex workarounds. These constraints motivated the concept of account abstraction—to make all accounts programmable and unify the distinction between user-controlled and contract-controlled activity.

How account abstraction changes transaction validation, gas, and access

Account abstraction modifies the validation pathway of transactions by allowing the account itself to define how actions are approved and executed. Instead of enforcing a signature from a specific private key, a smart contract wallet can define its own logic for authentication. This logic might include threshold signatures, hardware device checks, or rules for spending limits and time locks.

One of the most impactful changes introduced by account abstraction is the decoupling of gas payment from the sender. Traditionally, the transaction initiator must pay for gas in ETH. Under account abstraction, the validation logic can allow third parties—called paymasters—to cover gas fees on the user’s behalf. This opens up new possibilities such as sponsoring transactions for first-time users, enabling gasless dApp interactions, or paying fees in stablecoins or native project tokens.

Furthermore, account abstraction introduces the ability to bundle multiple operations into a single transaction. For example, a user can approve a token, perform a swap, and transfer funds in one action, reducing the number of confirmations required and improving the user experience. These enhancements significantly reduce friction in dApp interactions while maintaining security and composability.

Introduction to ERC-4337 and the “alt mempool”

ERC-4337, finalized in 2023, represents a milestone in Ethereum’s journey toward account abstraction. Unlike earlier proposals such as EIP-2938, ERC-4337 does not require changes to Ethereum’s consensus layer. Instead, it operates entirely within the existing smart contract environment by introducing a parallel transaction flow using an alternative mempool and a specific contract architecture.

Under ERC-4337, transactions are replaced by UserOperations—data objects that describe desired actions but are not submitted to the traditional mempool. These UserOperations are picked up by specialized off-chain actors known as bundlers. A bundler aggregates multiple UserOperations into a standard Ethereum transaction and submits it to the blockchain.

On-chain, a singleton contract called EntryPoint verifies and processes these bundled operations. The EntryPoint interacts with user smart accounts, which define their own validation logic and delegate the execution of transactions once validated. To pay gas fees, accounts may optionally interact with paymasters, which sponsor execution costs under conditions specified in code.

This structure enables a decentralized, permissionless way to support account abstraction without modifying Ethereum’s base protocol. As a result, developers can deploy smart contract wallets that behave like EOAs from the user’s perspective but offer far richer functionality.

Solana’s approach: Native account abstraction

Solana takes a fundamentally different approach to account abstraction by supporting it at the protocol level. Solana accounts are not divided into EOAs and contract accounts. Instead, all accounts on Solana are general-purpose storage containers that can hold data, be assigned ownership, and interact with programs.

In Solana’s model, the validation of actions is embedded within the programs (smart contracts) themselves. Program Derived Addresses (PDAs) are a key element of this system. These are deterministic addresses generated from seeds and programs that have no associated private key. Instead, they are controlled by program logic and can perform actions when the appropriate conditions are met.

Because of this native flexibility, Solana has offered features like multi-signature authorization, account delegation, and third-party fee payment without requiring external standards or simulated transaction flows. Wallets like Phantom and Solflare have integrated these capabilities early on, demonstrating seamless UX and programmable control of funds. This stands in contrast to Ethereum, where similar functionality depends on overlays like ERC-4337 and bundler networks.