← All posts

Account Abstraction 101: ERC-4337, EntryPoint, and Paymasters Explained

Account abstraction is one of the most consequential upgrades to how Ethereum-compatible chains handle transactions, and it's also one of the most misunderstood. This guide breaks down the core pieces: ERC-4337, the EntryPoint contract, and paymasters, and explains how they fit together.

What account abstraction actually changes

Traditionally, a transaction on an EVM chain has to come from an externally owned account (EOA), a wallet controlled directly by a private key. Account abstraction lets a smart contract act as the account instead. That unlocks things a plain EOA can't do on its own: batching multiple actions into one transaction, custom signature schemes, session keys, and gas sponsorship.

ERC-4337 is the standard that made this possible without requiring a change to Ethereum's core protocol. It introduced a parallel transaction type called a UserOperation, along with the infrastructure needed to process it.

The EntryPoint contract

The EntryPoint is the central onchain contract that every UserOperation flows through. It validates each operation, coordinates with bundlers that package UserOperations together, and handles payment: either the sending smart account's own deposit covers gas, or a paymaster does.

EntryPoint v0.7 is the current version most account abstraction infrastructure is built on. It refined how deposits, stakes, and paymaster validation work compared to earlier versions, and most new paymaster deployments, including Trustware's, are built directly on top of it.

Where paymasters fit in

A paymaster is a smart contract that can agree to cover the gas cost of a UserOperation on someone else's behalf. This is what makes gas sponsorship possible: an application can subsidize a user's transaction so the user never needs to hold the native gas token at all.

Under the ERC-4337 model, sponsorship only applies to UserOperations, which by definition come from smart accounts, not EOAs. That's part of why account abstraction and gas sponsorship are tied together so closely: without a smart account layer, there's no UserOperation for a paymaster to sponsor in the first place.

Ownership is the next layer of this stack

Most explanations of account abstraction stop at "here's how the pieces work." The question that matters more as this infrastructure matures is who owns each piece, particularly the paymaster, since that's the contract holding real money.

Trustware's paymaster system is built on ERC-4337 and EntryPoint v0.7, but with one structural difference from most of the market: every client deploys and owns their own paymaster contract, with sponsorship funds under their sole control. Account abstraction made gas sponsorship possible. Client ownership determines who actually controls it.