Entry Point

What Is an Entry Point in Crypto?

In cryptocurrency, an entry point can generally mean the contract, function, or interface through which a user begins a blockchain operation.

In account abstraction, Entry Point usually refers to the central EntryPoint smart contract defined by ERC-4337.

The EntryPoint contract coordinates the validation, execution, gas payment, account deployment, and settlement of operations submitted by smart accounts.

The official ERC-4337 specification describes a system in which users submit objects called UserOperations instead of sending ordinary transactions directly from externally owned accounts.

Special network participants called bundlers collect these UserOperations and submit them to the EntryPoint contract through a normal blockchain transaction.

The EntryPoint then checks whether each operation is authorized, determines how its gas will be paid, calls the relevant smart account, and settles the final gas cost.

The EntryPoint is not a wallet, token, blockchain, private key, or separate cryptocurrency network.

It is shared smart contract infrastructure used by compatible account-abstraction wallets, bundlers, account factories, paymasters, and applications.

What Is ERC-4337?

ERC-4337 is an account-abstraction standard that enables programmable smart accounts without requiring a new Ethereum transaction type at the consensus layer.

Traditional externally owned accounts use protocol-defined signature and nonce rules.

An ERC-4337 smart account can use contract code to define its own authorization logic.

This can support multisignature approval, passkeys, recovery systems, session permissions, spending limits, batched actions, and other programmable wallet features.

ERC-4337 introduces a separate UserOperation flow while ultimately settling activity through ordinary transactions included in blocks.

The Ethereum account-abstraction overview explains that ERC-4337 provides smart-account functionality without changing Ethereum’s base consensus rules.

The EntryPoint is the shared on-chain contract that connects the different parts of this system.

Why Is It Called the EntryPoint?

The contract is called EntryPoint because it is the main trusted gateway through which ERC-4337 operations enter a smart account.

A compatible smart account normally accepts ERC-4337 validation and execution calls only from an EntryPoint address it trusts.

Bundlers do not call arbitrary wallet execution functions as though they were the wallet owner.

Instead, they submit UserOperations to the EntryPoint, which asks each smart account to validate its own operation.

This structure separates the party paying for and submitting the blockchain transaction from the account that authorizes the underlying action.

It also gives bundlers one standardized contract interface for processing many different smart-account designs.

What Is the Current EntryPoint Version?

As of July 16, 2026, the official account-abstraction repository identifies EntryPoint v0.9.0 as its latest release.

The official account-abstraction release page lists the v0.9 EntryPoint address as

.

The release notes describe v0.9 as ABI-compatible with EntryPoint v0.7 and v0.8 for existing account and paymaster interfaces unless an implementation chooses to use new features.

Bundlers must still understand the new version before participating in its UserOperation mempool.

Older EntryPoint versions can continue to exist and process operations on networks where infrastructure still supports them.

A wallet must use a bundler, paymaster, factory, and smart-account implementation that support the same EntryPoint version.

Developers should verify the address, network, deployed bytecode, code hash, release notes, and security reports before changing versions.

Why Do Multiple EntryPoint Versions Exist?

The EntryPoint is deployed as a smart contract, so its code cannot simply be edited in place when the deployment is immutable.

A new version is generally introduced by deploying a new EntryPoint contract at a new deterministic address.

Wallets and infrastructure can migrate after reviewing the new contract and adding support for its behavior.

This approach avoids giving one administrator unrestricted power to replace the code of the existing singleton.

It also means that account-abstraction infrastructure can become fragmented across versions during migration periods.

A UserOperation intended for one EntryPoint must not be submitted as though it were intended for another version.

The selected EntryPoint address is included in important security calculations, including the operation hash.

What Is a UserOperation?

A UserOperation is a structured request describing an action that a smart account wants to perform.

It is sometimes shortened to UserOp.

A UserOperation is not an ordinary Ethereum transaction, although a bundler eventually includes it inside an ordinary transaction sent to the EntryPoint.

Its fields identify the smart account, nonce, execution data, gas limits, fee limits, signature, optional account-deployment data, and optional paymaster information.

Current versions use a packed representation called

when passing the data on-chain.

The EntryPoint uses the information to coordinate validation, execution, and gas settlement.

A UserOperation does not become valid merely because its data has the correct format.

The smart account, EntryPoint, bundler rules, and any selected paymaster must all accept it.

Main UserOperation Fields

The

field identifies the smart account that will validate and execute the operation.

The

field helps prevent replay and can support several ordered operation channels.

The account-deployment fields allow an undeployed smart account to be created as part of its first operation.

The

field describes the call that the smart account should execute.

Gas fields place limits on validation, execution, and other work paid for by the operation.

Fee fields define the maximum gas price and priority fee the operation accepts.

Paymaster fields identify an optional contract that agrees to cover gas costs.

The

field contains authorization data interpreted by the smart account’s validation logic.

A signature does not have to be a basic single-key signature because the smart account can implement another secure authorization method.

How a UserOperation Reaches the EntryPoint

A wallet first constructs a UserOperation describing the requested blockchain action.

The wallet obtains the correct nonce and estimates the gas fields required by the operation.

The smart account’s authorization system signs or otherwise approves the operation.

The wallet sends it to a bundler through an account-abstraction RPC method.

The bundler simulates the validation logic before accepting the operation.

Accepted operations can enter a dedicated UserOperation mempool.

The bundler selects a group of operations and submits them to the EntryPoint in one blockchain transaction.

The EntryPoint validates and executes the operations according to ERC-4337 rules.

After execution, the EntryPoint pays the bundler’s chosen beneficiary from the gas funds charged to the accounts or paymasters.

What Is a Bundler?

A bundler is an account-abstraction participant that collects, validates, groups, and submits UserOperations.

The bundler pays the native network transaction fee when sending the bundle transaction to the blockchain.

It expects the EntryPoint to reimburse the operation costs from smart-account or paymaster deposits.

This creates an important economic requirement because bundlers must reject operations that could consume gas without paying.

A bundler normally simulates an operation several times as blockchain state changes between initial receipt and final submission.

The standardized ERC-7769 JSON-RPC interface defines methods that wallets and bundlers can use to exchange UserOperations and retrieve their status.

A bundler is not the owner of the smart account and should not be able to authorize an operation that the account rejects.

The handleOps Function

The primary EntryPoint function is

.

It accepts an array of packed UserOperations and a beneficiary address.

The bundler calls this function in the transaction that delivers a bundle on-chain.

The EntryPoint processes the operations through validation and execution stages.

It checks account deployment when necessary, verifies nonces, calculates required prefunding, calls account validation, checks paymaster validation, and confirms that sufficient gas funding exists.

It then calls the smart accounts to execute their requested actions.

After processing, it calculates actual costs and transfers collected fees to the beneficiary.

The beneficiary is commonly controlled by the bundler, but the protocol function accepts an address selected for the payment.

Validation and Execution Are Separate Stages

ERC-4337 separates validation from the operation’s main execution.

During validation, the EntryPoint determines whether the account authorizes the operation and whether its gas costs can be paid.

During execution, the smart account performs the requested calls.

This distinction is important because an operation can pass authorization checks but still fail during its application call.

For example, a smart account may correctly authorize a token transfer that later fails because the account lacks the required token balance.

Gas is still consumed by validation and failed execution.

The account or paymaster can therefore be charged even when the intended application action does not succeed.

The validateUserOp Function

An ERC-4337 smart account implements a function called

.

The EntryPoint calls this function during validation.

The account receives the packed operation, its hash, and information about any missing gas funds.

The account must confirm that the caller is a trusted EntryPoint.

It must then apply its own authorization rules to the operation.

A simple account might verify one cryptographic signature.

A more advanced account might require several signatures, a passkey proof, a recovery guardian, a session-key permission, or a spending-policy check.

The account can also return a validity range that limits when the UserOperation may be included.

Why the Smart Account Must Trust the Exact EntryPoint

The EntryPoint receives permission to call sensitive validation and execution paths on a smart account.

A smart account should therefore reject calls from an untrusted contract pretending to be the EntryPoint.

Trusting the wrong address could allow a malicious contract to bypass assumptions about nonce handling, gas accounting, caller identity, or execution order.

A wallet implementation must define how it recognizes an approved EntryPoint version.

Some accounts use one fixed address, while upgradeable or modular accounts may support a controlled migration process.

Adding a new EntryPoint should be treated as a security-sensitive wallet upgrade rather than a routine interface setting.

UserOperation Hash and Replay Protection

The UserOperation hash binds the operation to important data used during authorization.

The hash includes the EntryPoint address and blockchain chain ID.

This prevents a valid operation intended for one EntryPoint or network from being reused automatically on another one.

The signature itself is excluded from the underlying operation hash so the account can validate the supplied authorization data against that hash.

Current paymaster-signature designs can also exclude a separate paymaster signature from the hash to allow wallet and paymaster signing to happen in parallel.

Developers must follow the exact hashing rules for the selected EntryPoint version.

Incorrect domain separation can create replay risks or make legitimate operations impossible to validate.

EntryPoint Nonce Management

The EntryPoint provides nonce management to prevent the same UserOperation from being executed repeatedly.

ERC-4337 uses a two-part nonce containing a 192-bit key and a 64-bit sequence value.

Each key can represent a separate ordered channel for one smart account.

This allows an account to maintain normal operations, administrative operations, or other categories without forcing every action into one global sequence.

The

function returns the current nonce for a sender and nonce key.

A bundler should check the nonce before accepting and later including an operation.

The smart account can apply additional nonce restrictions when its security model requires them.

Counterfactual Smart Account Deployment

An ERC-4337 wallet address can often be calculated before the smart account contract is deployed.

This is called a counterfactual address.

The wallet can receive crypto assets at the calculated address before its first account-abstraction operation.

The first UserOperation includes account-deployment information identifying a factory and initialization data.

The EntryPoint uses its SenderCreator helper to call the factory and create the smart account at the expected address.

The deployed address must match the UserOperation’s sender field.

If the account does not exist and the operation contains no valid deployment information, validation fails.

EntryPoint v0.9 and initCode

EntryPoint v0.9 changes how deployment data is handled when the sender account already exists.

In earlier behavior, nonempty

was expected only for the operation that deployed the account.

Version 0.9 can ignore the deployment data when the sender contract already exists and emit an

event.

This helps undeployed accounts prepare parallel operations using different nonce channels.

Account code must not assume that nonempty deployment data always proves that the operation is the account’s first operation.

Developers migrating to v0.9 should review any logic that depends on this older assumption.

Gas Prefunding

A bundler pays the network fee for the transaction that calls the EntryPoint.

The EntryPoint must therefore confirm that each UserOperation can reimburse its maximum expected cost.

During validation, it calculates a required prefund using the operation’s gas limits and fee settings.

The smart account can hold a deposit inside the EntryPoint for this purpose.

If the account’s deposit is insufficient, the account may transfer additional native currency to the EntryPoint during validation.

When a paymaster sponsors the operation, the paymaster’s deposit is used instead.

Insufficient prefunding makes the operation invalid for inclusion.

EntryPoint Deposits

The EntryPoint maintains deposits used to pay future UserOperation gas costs.

Smart accounts and paymasters can add native currency to these deposits.

The

function adds funds for a specified account or paymaster.

The EntryPoint’s

function reports an entity’s gas deposit.

The authorized entity can use

to remove an available deposit according to the contract rules.

A deposit is not a yield-bearing balance and does not represent a tokenized investment.

It is prefunded native currency held for account-abstraction gas settlement.

What Is a Paymaster?

A paymaster is an optional smart contract that agrees to cover the gas cost of selected UserOperations.

This can let an application subsidize user activity or apply another fee arrangement.

The paymaster places native currency in its EntryPoint deposit.

During validation, the EntryPoint calls

to ask whether the paymaster accepts responsibility for the operation.

The paymaster can evaluate account identity, call data, time limits, signed authorization, spending policies, or other conditions.

If it returns context data, the EntryPoint can call the paymaster’s

function after execution.

The paymaster still pays gas when the account’s application call reverts after successful validation.

Paymaster Deposits vs. Stakes

A paymaster deposit and paymaster stake have different purposes.

The deposit pays UserOperation gas costs.

The stake is locked as part of the system’s defense against denial-of-service and reputation abuse.

The

function locks stake with an unstake delay.

The paymaster must first call

and wait for that delay before withdrawing the stake.

The

function releases an eligible unlocked stake.

Having a large deposit does not automatically satisfy a staking requirement.

Having a stake does not replace the deposit required to pay sponsored gas.

EntryPoint v0.9 Paymaster Signatures

EntryPoint v0.9 adds support for a separate

value.

Earlier flows could require the wallet to wait for complete paymaster data before signing its UserOperation.

The newer design allows the wallet signature and paymaster signature to be generated in parallel when the paymaster supports the feature.

The separate paymaster signature does not alter the UserOperation hash under the specified encoding.

This can reduce delay in sponsored-operation user flows.

Wallets, paymasters, and bundlers must all understand the version-specific encoding before using it.

EntryPoint Stakes and Reputation

ERC-4337 validation can involve account factories, paymasters, signature aggregators, and other contracts.

Malicious entities could attempt to waste bundler resources or make operations invalid after they enter the mempool.

Staking allows some entities greater validation-time storage access while exposing them to reputation consequences.

Bundlers can monitor entities that repeatedly cause invalid bundles or abusive behavior.

The precise off-chain reputation policy can vary between bundler implementations.

Staking reduces certain attack incentives but does not prove that a paymaster or factory is trustworthy.

What Is UserOperation Simulation?

Simulation is the off-chain process a bundler uses to predict whether a UserOperation will pass EntryPoint validation.

The bundler performs calls and traces against current blockchain state without committing the simulated changes.

Simulation checks account creation, nonce validity, account authorization, paymaster approval, gas funding, and restricted validation behavior.

The bundler normally simulates when it first receives the operation, again when selecting it for a bundle, and again before submitting the bundle.

Repeated simulation is necessary because another transaction can change balances, deposits, nonces, contract code, or other relevant state.

A successful simulation does not guarantee that the application execution itself will succeed.

ERC-7562 Validation Rules

Programmable validation creates denial-of-service risks that do not exist in the same form for ordinary account signatures.

A malicious account could make validation depend on unstable state or consume large amounts of bundler resources.

The ERC-7562 validation rules limit opcodes, storage access, and other behavior used during public UserOperation mempool validation.

Bundlers enforce these rules off-chain before including operations.

The restrictions apply to validation rather than every action performed during the account’s main execution.

An operation accepted in a private or alternative mempool may follow different policies from the canonical shared mempool.

UserOperation Execution

After validation succeeds, the EntryPoint calls the smart account to execute the requested operation.

The account interprets its

according to its implementation.

The operation may call one contract, transfer crypto assets, or execute a batch of several actions.

The EntryPoint does not decide whether the application-level action is financially sensible.

It coordinates account authorization, gas accounting, and execution according to the contract rules.

A properly authorized operation can still interact with a malicious token, unsafe contract, or unfavorable financial position.

The IAccountExecute Interface

A smart account can optionally implement

.

This interface provides an

function that receives the current packed UserOperation and its hash.

The EntryPoint can call this function instead of directly calling the account with the original execution data.

This allows the account to inspect more complete UserOperation information during execution.

The exact execution method depends on the EntryPoint version and the account’s supported interfaces.

The getCurrentUserOpHash Function

EntryPoint v0.9 adds

.

This function allows a contract to query the hash of the UserOperation currently being executed.

The value is available only within the relevant execution frame.

Outside UserOperation execution, the function returns a zero value under the specified interface.

This feature can help third-party contracts bind execution behavior to the exact UserOperation being processed.

Developers should not treat a zero result outside the execution frame as evidence that a caller is trustworthy.

Gas Settlement and the Beneficiary

The EntryPoint measures the gas associated with processing each UserOperation.

It charges the responsible account or paymaster according to actual cost and the operation’s fee limits.

Collected fees are sent to the beneficiary supplied in the bundler’s

call.

This reimburses the entity that submitted and paid for the blockchain transaction.

Unused prefunded value remains in the account’s or paymaster’s EntryPoint deposit.

Gas estimation errors can cause an operation to be rejected, run out of gas, or reserve more funding than expected.

Can One Failed Operation Break a Bundle?

Validation failure can cause an operation to be excluded or can cause bundle submission to revert, depending on when the problem is found and which EntryPoint function is used.

This is why bundlers simulate operations repeatedly before sending the bundle.

Once an operation has passed validation, its application execution can still revert.

An execution revert is normally recorded as a failed UserOperation while gas remains payable.

Bundlers must construct bundles carefully so one state change does not unexpectedly invalidate a later operation.

Applications should read UserOperation receipts and success events rather than assuming that bundle inclusion means the requested call succeeded.

EntryPoint Events

The EntryPoint emits events that make UserOperation activity observable.

A UserOperation event can identify the operation hash, sender, paymaster, nonce, success status, actual gas cost, and gas used.

Account-deployment events can identify newly created smart accounts and their factories.

Deposit and withdrawal events record changes to prefunded gas balances.

Stake events record staking, unlocking, and withdrawal activity.

Newer versions can add events for version-specific behavior, such as ignored deployment data or EIP-7702 initialization.

Indexers must use the event definitions for the exact EntryPoint version they are tracking.

EntryPoint and EIP-7702

EIP-7702 allows an externally owned account to authorize delegation to smart contract code.

Current ERC-4337 versions can use this delegation to provide account-abstraction features to an existing address.

The official EIP-7702 specification defines the authorization mechanism at the transaction level.

An ERC-4337 bundler can include the required authorization data when submitting a compatible UserOperation bundle.

The EntryPoint includes the delegation target in relevant hashing and initialization logic.

EIP-7702 does not remove the need to secure the delegated account implementation, authorization process, and EntryPoint integration.

EntryPoint v0.9 Validity Ranges

Smart accounts and paymasters can restrict a UserOperation to a validity period.

Earlier EntryPoint behavior represented these limits through timestamps.

Version 0.9 also supports validity ranges interpreted as block numbers when the specified encoding flag is used.

This can help applications whose permissions or actions are already defined around block heights.

Bundlers must understand the encoding and avoid including operations that are not yet valid or are likely to expire before inclusion.

Deterministic EntryPoint Deployment

Official EntryPoint deployments use deterministic contract-creation techniques so the same version can have the same address on supported compatible networks.

This can simplify wallet and bundler configuration.

The EntryPoint contract documentation explains how the official repository uses a fixed deployment salt for local and compatible deployments.

A matching address alone is not enough to establish authenticity because a different network can contain different code or deployment history.

Developers should verify the bytecode and code hash at the address on every supported network.

EntryPoint vs. Smart Account

The EntryPoint is shared infrastructure used by many smart accounts.

A smart account is the user-specific contract that holds assets and defines authorization rules.

The EntryPoint does not normally store the user’s token balances or replace the smart account address.

The smart account decides whether a UserOperation is authorized.

The EntryPoint enforces the common processing, nonce, deployment, gas, and settlement framework.

A vulnerability in a smart account can affect that account even when the EntryPoint works correctly.

A vulnerability in a widely used EntryPoint version could affect many accounts and paymasters that trust it.

EntryPoint vs. Bundler

The EntryPoint is an on-chain contract.

A bundler is an off-chain participant that receives UserOperations and submits an EntryPoint transaction.

The bundler performs simulation and pays the initial network transaction fee.

The EntryPoint performs the authoritative on-chain validation and settlement.

A bundler cannot make an invalid smart-account signature valid.

However, a bundler can delay or refuse to include an operation, so wallets may benefit from access to more than one compatible submission route.

EntryPoint vs. Paymaster

The EntryPoint processes operations and settles their gas costs.

A paymaster optionally agrees to pay those costs for selected users or actions.

The paymaster defines its own sponsorship rules within ERC-4337 validation restrictions.

It must hold a sufficient deposit and may need a stake.

The EntryPoint does not force a paymaster to sponsor every valid operation.

A paymaster outage or policy rejection can stop a sponsored flow even when the smart account itself is valid.

EntryPoint vs. Account Factory

An account factory deploys smart-account contracts.

The EntryPoint calls the factory through its SenderCreator mechanism when an undeployed sender includes valid creation data.

The factory must produce the expected account address.

It must also restrict sensitive creation paths according to the ERC-4337 security requirements.

The EntryPoint does not decide the smart account’s implementation, owners, modules, or recovery rules.

Those properties are established by the factory and initialization data.

Benefits of the EntryPoint Model

The EntryPoint gives bundlers one shared interface for many smart-account designs.

It allows accounts to define programmable authorization instead of depending on one fixed signature model.

It supports counterfactual account deployment as part of the first UserOperation.

It enables paymasters to sponsor gas under programmable policies.

It supports bundling several user actions into one underlying transaction.

It separates the user’s authorization from the account that pays the network transaction fee.

It can be deployed on compatible networks without requiring a consensus-layer change.

Limitations of the EntryPoint Model

The EntryPoint introduces additional contracts, RPC methods, simulations, gas fields, and infrastructure roles.

A wallet must coordinate with a compatible bundler and possibly a paymaster.

Different EntryPoint versions can divide liquidity, tooling, and mempool support.

Programmable validation creates denial-of-service risks that require strict off-chain rules.

Gas estimation is more complex than estimating a basic account transaction.

A sponsored operation can fail when the paymaster is unavailable or rejects the request.

Account abstraction improves wallet flexibility but does not eliminate phishing, malicious applications, unsafe approvals, or smart contract bugs.

EntryPoint Security Risks

The EntryPoint is a high-value shared dependency because smart accounts and paymasters grant it special authority.

A flaw in validation, gas calculation, deposits, staking, account creation, or execution could have broad effects.

Developers should use audited official deployments rather than casually modifying the core contract.

Wallets must verify the trusted EntryPoint address and version.

Bundlers must enforce validation and reputation rules consistently.

Accounts and paymasters must verify that sensitive callbacks originate from the trusted EntryPoint.

Factories must verify calls from the correct SenderCreator contract.

Signature and Authorization Risks

Account abstraction supports flexible signatures, but flexibility does not guarantee secure authorization.

A weak passkey verifier, incorrect multisignature threshold, exposed session key, or flawed recovery module can authorize unwanted UserOperations.

The account must bind authorization to the correct operation hash, chain ID, EntryPoint, nonce, validity range, and intended calls.

Wallet interfaces should clearly show the calls contained in a batch before requesting approval.

A valid smart-account signature can authorize several actions at once, including token approvals and transfers.

Paymaster Risks

A paymaster can apply restrictive or centralized sponsorship rules.

It can stop sponsoring activity when its deposit is low, its service is unavailable, or its policy changes.

A flawed paymaster can lose its deposit through incorrect validation or accounting.

A malicious user can attempt to consume paymaster resources without completing useful actions.

A compromised paymaster signer can approve operations outside the intended policy.

Users should not assume that sponsored gas means an operation is safe or free of other charges.

Bundler Risks

A bundler can censor, delay, misprice, or drop a UserOperation.

It can also return inaccurate gas estimates or stale status information.

The smart account remains protected by on-chain validation, but the user experience can still fail when the selected bundler is unreliable.

Wallets should handle timeouts, operation replacement, fee changes, and alternative bundler submission where supported.

Users should verify final on-chain receipts instead of relying only on a bundler’s pending response.

Gas Estimation Risks

A UserOperation separates several gas limits for validation, execution, paymaster work, and bundler overhead.

Setting a limit too low can cause validation or execution failure.

Setting a limit unnecessarily high can require a larger prefund, although final settlement should use actual cost within the protocol rules.

Network-specific data costs can affect

.

EIP-7702 authorization costs can also require additional accounting that the EntryPoint cannot observe directly.

Wallets should use an RPC service compatible with the selected EntryPoint version and network.

Reentrancy and External Calls

The EntryPoint calls smart accounts, factories, paymasters, signature aggregators, and application contracts.

These external calls can execute arbitrary contract code.

Implementations must assume that external code can revert, consume gas, or attempt reentrancy.

Smart accounts and modules should protect their own critical state during EntryPoint-triggered execution.

Paymaster post-operation logic should not assume that the account’s requested action succeeded.

Custom account-abstraction extensions require independent security analysis even when they use an audited EntryPoint.

How Developers Should Integrate the EntryPoint

The first step is to choose a supported EntryPoint version and verify its official deployment on each network.

The second step is to make the smart account trust only approved EntryPoint addresses.

The third step is to implement

with correct signature, nonce, validity, and funding behavior.

The fourth step is to use the correct UserOperation packing and hashing rules.

The fifth step is to test undeployed and already deployed account flows.

The sixth step is to integrate a bundler that supports the selected EntryPoint version.

The seventh step is to test operation simulation, replacement, failure receipts, and gas estimation.

The eighth step is to review paymaster, factory, module, upgrade, and recovery permissions.

The ninth step is to test malicious validation and execution contracts.

The tenth step is to monitor official releases, audits, and migration guidance.

How Users Encounter the EntryPoint

Most users do not call the EntryPoint manually.

A smart-account wallet constructs and submits the UserOperation in the background.

The user may see an account-abstraction operation hash before the underlying blockchain transaction is created.

After inclusion, a block explorer can show a transaction calling

on the EntryPoint.

That one transaction may contain operations from several unrelated smart accounts.

The user should inspect the individual UserOperation result rather than assuming every action in the bundle had the same outcome.

Example of an EntryPoint Transaction

Suppose Alice uses a smart account and wants to approve a token and deposit it into a crypto vault in one action.

Her wallet creates a UserOperation containing both calls.

The account’s authorization logic approves the operation using Alice’s configured authentication method.

A paymaster agrees to sponsor the network gas according to its policy.

The wallet sends the operation to a compatible bundler.

The bundler simulates the account and paymaster validation.

It then includes Alice’s operation with other UserOperations in a call to the EntryPoint’s

function.

The EntryPoint confirms the nonce, account authorization, paymaster approval, and available gas deposit.

The smart account executes the token approval and vault deposit.

The EntryPoint charges the actual gas cost to the paymaster’s deposit and pays the bundler beneficiary.

If the vault call reverts, Alice’s operation can be recorded as unsuccessful while the consumed gas remains payable.

Common EntryPoint Mistakes

One common mistake is confusing the EntryPoint with the user’s smart account.

Another mistake is submitting a UserOperation to a bundler that supports a different EntryPoint version.

A third mistake is trusting an EntryPoint address without verifying its deployed code.

A fourth mistake is assuming that bundle inclusion proves the application call succeeded.

A fifth mistake is confusing a gas deposit with a paymaster stake.

A sixth mistake is failing to include the chain ID and EntryPoint address in authorization logic.

A seventh mistake is treating a successful simulation as a guarantee of successful execution.

An eighth mistake is allowing sensitive account functions to accept calls from any supposed EntryPoint.

A ninth mistake is assuming that a sponsored transaction cannot charge tokens or apply another fee.

A tenth mistake is upgrading to a new EntryPoint without reviewing version-specific behavior and security reports.

FAQ

What is the Entry Point in ERC-4337?

The EntryPoint is the central smart contract that validates, executes, and settles UserOperations for compatible account-abstraction wallets.

Is EntryPoint a wallet?

No, it is shared infrastructure used by smart-account wallets, bundlers, factories, and paymasters.

Is EntryPoint a cryptocurrency?

No, EntryPoint is smart contract software and does not require its own token.

What is the latest EntryPoint version?

As of July 16, 2026, the official account-abstraction repository lists EntryPoint v0.9.0 as its latest release.

What is the EntryPoint v0.9 address?

The official v0.9 release lists

, but developers must verify the network, code, and official security information before using it.

Can several EntryPoint versions exist?

Yes, old and new versions can coexist while wallets, bundlers, and paymasters migrate.

What is a UserOperation?

A UserOperation is a structured account-abstraction request containing the sender, nonce, calls, gas settings, authorization, and optional deployment or sponsorship data.

Is a UserOperation an Ethereum transaction?

No, a bundler packages one or more UserOperations into an ordinary blockchain transaction sent to the EntryPoint.

What does handleOps do?

It validates and executes a bundle of UserOperations and pays the selected beneficiary from the gas costs collected.

Who calls the EntryPoint?

A bundler normally calls the EntryPoint when submitting a UserOperation bundle on-chain.

Who authorizes a UserOperation?

The smart account authorizes it through its own

logic.

Can a bundler spend funds without account approval?

A correctly implemented smart account rejects operations that do not satisfy its authorization rules.

What is an EntryPoint deposit?

It is native currency prefunded inside the EntryPoint to pay future UserOperation gas costs.

What is an EntryPoint stake?

It is locked native currency used by certain entities, especially paymasters, as part of denial-of-service and reputation protections.

Is a paymaster deposit the same as its stake?

No, the deposit pays gas while the stake is separately locked with an unstaking delay.

What is a paymaster?

A paymaster is a contract that agrees to pay the gas cost of selected UserOperations.

Does a paymaster make every operation free?

No, it can reject operations, apply eligibility rules, or use another method to recover its cost.

What is UserOperation simulation?

It is the off-chain process bundlers use to predict whether an operation will pass EntryPoint validation before submitting it.

Does successful simulation guarantee execution?

No, application execution can still revert or blockchain state can change before inclusion.

Why is the EntryPoint address included in the operation hash?

It helps prevent an authorization intended for one EntryPoint version from being replayed through another contract.

Why is the chain ID included in the operation hash?

It helps prevent the same signed operation from being replayed automatically on another blockchain network.

Can the EntryPoint deploy a smart account?

It can coordinate deployment through account creation data and a factory when the sender account does not yet exist.

What is a counterfactual smart account?

It is a smart-account address calculated before the account contract is deployed.

Does the EntryPoint hold user tokens?

The user’s smart account normally holds the tokens, while the EntryPoint holds only deposits and stakes related to gas processing.

Can one EntryPoint transaction contain several users?

Yes, a bundler can include UserOperations from several unrelated smart accounts in one

transaction.

Can a failed UserOperation still consume gas?

Yes, validation and unsuccessful execution consume gas, and the responsible account or paymaster can still be charged.

Does EntryPoint support EIP-7702 accounts?

Current EntryPoint versions include support for compatible EIP-7702 authorization and delegated-account flows.

What changed in EntryPoint v0.9?

Major changes include parallel paymaster signatures, block-number validity ranges, updated handling of deployment data, current UserOperation hash queries, and additional observability improvements.

Should a project deploy its own EntryPoint?

Production wallets usually use a reviewed canonical deployment, while custom local deployments are mainly useful for testing and development.

Is the EntryPoint safe?

The official contract is heavily reviewed, but security still depends on the exact deployment, version, smart account, bundler, paymaster, factory, modules, and integration code.

Conclusion

The EntryPoint is the central on-chain gateway of ERC-4337 account abstraction.

It receives bundled UserOperations, coordinates smart-account validation, deploys accounts when needed, verifies gas funding, executes approved calls, and settles fees.

Bundlers submit operations to the EntryPoint, while smart accounts retain control over their own authorization rules.

Paymasters can sponsor gas by maintaining deposits and accepting operations through programmable validation policies.

The EntryPoint also manages nonce channels, deposits, stakes, operation events, and other shared account-abstraction functions.

As of July 16, 2026, v0.9.0 is the latest release listed by the official account-abstraction repository.

Version compatibility still requires every wallet, bundler, paymaster, factory, and account implementation to agree on the selected EntryPoint deployment.

Developers must verify the address and bytecode, protect trusted-caller checks, follow exact hashing rules, simulate operations, and review every connected contract.

Users should understand that sponsored gas and programmable wallets improve usability but do not eliminate phishing, execution failure, approval risk, or smart contract vulnerabilities.

Understanding the EntryPoint helps crypto users distinguish the shared ERC-4337 processing contract from the smart account, bundler, paymaster, and application actions built around it.