A sponsored transaction reaches the chain as one call to a singleton contract. Before that call there is a signature the user pays nothing to produce, a sponsor’s promise to cover the gas, and at least one bundler that evaluates the arrangement three times: on arrival, while assembling a bundle, and once more for the entire bundle before submission. The economic content of “gasless” sits in that evaluation.
The ERC-4337 specification is precise about what the final step buys. Once validation succeeds and the operation can pay, execution happens exactly once and the fee is guaranteed. The validation scope rules that bundlers apply put the same boundary in a single sentence, and it is narrower than most sponsored-flow documentation implies.
The validation rules only apply during the validation phase. Once a UserOperation is validated, it is guaranteed to pay. There are no restrictions on execution, neither on the account’s callData nor on the paymaster’s postOp.
Everything a reader might mean by “the transaction worked” lives on the unconstrained side of that line. What the protocol enforces is payment, once, for whatever the account’s code then does.
The property an ordinary transaction gets for free
Account abstraction has to rebuild a guarantee that externally owned accounts never had to state. In the EOA model, a transaction that reaches the mempool and pays cannot be invalidated by anyone except the same account, and only by paying more. ERC-7562’s motivation says why that matters: a valid transaction cannot become invalid without the account paying, so a transaction must guarantee fee payment to prevent denial-of-service (DoS) attacks
. Spam stays expensive because an attacker has to keep outbidding the network.
Contract accounts have no equivalent property. Whether a UserOperation is valid depends on storage that other people’s transactions can change. A bundler that forwards a hundred operations which all pass validation and then fail at inclusion has burned real gas for nothing. ERC-4337 answers with a clean split between validation, which decides acceptance and payment, and execution, which happens afterwards. The rationale describes that separation as what keeps account logic simple, and the security section reduces the EntryPoint’s obligations to two claims: safety against arbitrary hijacking, and safety against fee draining.
Neither claim covers outcomes. An operation can be valid, paid for, executed exactly once, and still do something the signer did not intend. Leaving calldata unrestricted is a deliberate trade, because constraining execution would constrain what accounts can do, which is the point of the standard. The cost is that a sponsored flow’s guarantees have to be assembled by the people deploying it, one layer at a time.
What the EntryPoint enforces
handleOps runs two loops. The verification loop creates the account when a factory is supplied, computes the maximum fee from the declared gas limits, charges the sender’s deposit, and calls validateUserOp. The account must confirm that the caller is a trusted EntryPoint, must verify the signature over the operation hash, and must cover any missing funds. The execution loop then calls the account with the operation’s calldata and refunds the unused deposit.
Two details in that loop shape what a bundler will carry. The first is the unused-gas penalty: 10% on unused callGasLimit and paymasterPostOpGasLimit, applied once unused gas reaches 40,000. The stated reason is bundle space, since an operation that reserves a large allowance and uses little of it crowds out others in the same block. The second is the one-operation-per-sender rule, with an exemption for staked senders. Both are admission controls. They shape which operations a bundler can profitably carry, and neither says whether the operation is a good idea.
The specification’s own summary states the scope.
It enforces the simple rule that only after validation is successful and the UserOperation can pay, the execution is done and only done once, and also guarantees the fee payment.
A paymaster is an underwriter holding a deposit and a lock
When paymasterAndData is non-empty, the verification loop adds a second admission test: the EntryPoint checks the paymaster’s deposit and calls validatePaymasterUserOp. If that call returns a context, postOp runs after execution and receives a mode describing what happened. The interface comment for the reverted branch is unambiguous: UserOperation reverted. paymaster still has to pay for gas.
That line turns sponsorship into a credit decision. The sponsor buys inclusion for a request it does not control, and it pays for the attempt even when the attempt fails. Sponsors manage this the way lenders manage exposure, with a prepaid balance and a policy. The paymaster section describes the architecture as pre-charge and later refund, which is also how a token paymaster quotes a price in an ERC-20: charge the maximum, return the difference.
The balance sheet is the deposit. The stake is a different instrument. Both documents are emphatic that the stake exists to make sybil attacks expensive rather than to compensate anyone for a loss: Note that this stake is never slashed. There is no slashing mechanism involved and the only use for the stake in sybil attack prevention.
A paymaster that presents its stake as user protection is describing a lock-up, not insurance.
Exposure is then measured across the mempool rather than per operation. ERC-7562 requires each bundler to track the total gas that operations referencing a paymaster might consume, and to refuse a new one when the maximum total would exceed that paymaster’s deposit at the current gas price. The check is a “should” executed by the bundler in its own state rather than a consensus rule. A paymaster can be solvent on chain and still find its next operation refused, because the bundler is pricing a queue and not a balance.
The sponsor’s approval sits outside the operation hash
The sender signs the operation hash. The paymaster’s signature is appended after paymasterData rather than carried inside it, and the specification says that neither the signature field nor that appended paymaster signature affects the hash, which is what lets the sender and the paymaster sign in parallel.
Because the hash does not cover the sponsor’s approval, whatever binding that approval has must come from the paymaster’s own contract. A paymaster that verifies a signature over the operation fields without adding its own nonce, deadline, or per-user budget leaves an authorization that can be presented again in a different context. That is an inference from the field layout rather than a statement in the specification, and it is the first thing to test against a real implementation before shipping a sponsored flow. The same layout explains a second asymmetry worth naming: the account’s signature protects the user from the sponsor, and nothing in the standard protects the sponsor from the user.
What a bundler is allowed to look at
ERC-7562 defines the sandbox. Validation may not read the environment: TIMESTAMP, NUMBER, BASEFEE, BLOCKHASH, GASPRICE, ORIGIN, COINBASE and GASLIMIT are blocked, along with the blob-price opcodes, CREATE outside the deployment frame, and SELFDESTRUCT. The rationale is a concrete failure mode: require(block.number == 12345) might pass during mempool validation but fail when the transaction is eventually included in a later block.
Storage access is fenced the same way. An account may always touch its own storage. Associated storage inside a non-entity contract is permitted when the account already exists, or when an initCode is present and the factory is staked. Staked entities get read and write access to slots associated with them, plus read-only access elsewhere. The purpose is isolation rather than privacy, so that one storage write cannot invalidate operations sitting in other bundlers’ mempools.
The size limits follow the same reasoning: 8,192 bytes per operation, 500,000 gas for verification, 2,048 bytes of paymaster context per operation, and a 4,000 gas slack above measured validation usage. When a sponsored flow passes simulation and fails on inclusion, one of those limits is the first place to look.
Reputation is a mempool fact, not a chain fact
Each entity accumulates two counters per bundler, operations seen and operations included, and both decay hourly so that a value falls to roughly one percent after four days. Reputation compares a scaled count of seen operations against included ones, and the outcome is a ban, a throttle, or nothing at all.
Reputation stops at the mempool boundary, and the document is explicit about the scope: This affects only the P2P network, not the blockchain.
A banned paymaster is not marked on chain, its deposit is untouched, and a bundler that never saw the ban will still accept its operations. Rules also come in two classes. A network-wide violation damages the reputation of the peer that propagated the operation, while a local rule reflects one bundler’s state, and the rules state that Because this state may differ between bundlers, there is no need for consensus on local rule violations.
Alternate mempools formalise the gap, and an entity can be considered throttled or banned in one mempool, while still active on another
.
For anyone shipping a sponsored flow, admissibility is therefore a per-venue property. Two conformant bundlers can disagree about the same operation, and a flow that works against one RPC endpoint can fail against another without any party misbehaving.
The older model put trust somewhere else
ERC-2771 solves the same user problem with a different trust shape, and reading it beside 4337 shows what moved. In 2771 a trusted forwarder calls the recipient and appends the signer’s address as the last 20 bytes of calldata. The recipient has to check the forwarder, because The Recipient MUST check that it trusts the Forwarder to prevent it from extracting address data appended from an untrusted contract. This could result in a forged address.
Discovery runs through isTrustedForwarder, which must not revert and should stay under 50,000 gas. The security section is blunt about the stakes. A malicious forwarder can forge the sender for any address, an upgradeable forwarder means trusting future upgrades, and changing the allowlist is itself an attack surface. The authors recommend making the list immutable where possible.
Compare the two on the question a sponsor cares about. ERC-2771 keeps a named trust anchor that the application chooses, and it says nothing about who must relay, because the gas relay is untrusted and pays; the signer’s protection is the signature itself. ERC-4337 removes the recipient-side allowlist, makes bundlers permissionless, and constrains them with shared validation rules, deposits and reputation instead. Both designs keep a trust anchor. ERC-2771 puts it in a contract the application picks; ERC-4337 spreads it across an audited singleton, each bundler’s local policy and the sponsor’s own code.
Five checks before calling a flow underwritten
- Who holds the deposit, and is it sized for the queue the flow will create rather than the single transaction in the test?
- What does postOp do when the operation reverts, and does the sponsor’s accounting record the loss?
- Which fields does the sponsor’s authorization bind, given that the operation hash does not cover them?
- Which bundlers accept the entity, and do they share the same alternate mempool?
- What is the user pre-charged, and when does the refund land if postOp misbehaves?
Where this reading could be wrong
ERC-7562 is marked Review and states that it is in the process of peer review, so these rules describe a target that implementations approach unevenly. The canonical mempool the document assumes is in practice a set of software stacks with their own local rules, a divergence the document itself concedes. The cost argument behind the mass-invalidation defence is arithmetic rather than measurement: 5,000 gas for the storage write that invalidates an operation, 2,000 invalid operations per block, 10 million gas per block. That is a credible floor and still a model.
Two developments would change the conclusion. If reputation or stake moved on chain, a ban would travel with the entity and admissibility would become a property of the network rather than the venue. If postOp acquired an enforceable guarantee, a sponsor’s exposure would stop depending on its own code. Neither appears in the documents reviewed here.
What the three promises are
Read a sponsored transaction as three separate promises: inclusion, payment and execution. The protocol guarantees the second, and guarantees that the third happens once. Inclusion is a bundler’s commercial and policy decision, and the content of execution is whatever the account’s code does with the calldata. For a sponsor, the work is sizing the deposit against the queue and binding its own authorization. For a wallet, it is knowing which bundlers will accept the entity before telling a user that the transaction is free.