Your Crypto Transaction Was Gas-Free. So Who Actually Paid?

On May 31, 2026, a wallet on Arbitrum transferred 15 USDT0 without paying the network fee directly from its own ETH balance.

The transaction went through an account abstraction system, with a third-party bundler submitting it and a Paymaster covering the gas cost through Ethereum’s native fee mechanism.

But the blockchain recorded another transfer.

Alongside the 15 USDT0 sent to the intended recipient, the wallet sent 0.016085 USDT0 to the Paymaster’s address.

The EntryPoint contract separately recorded a gas charge of 0.000003345001682892 ETH for the operation.

The transaction succeeded. The intended recipient received the tokens. The wallet did not have to supply ETH for gas.

Yet someone had paid the network, and the user had transferred an additional amount of a stablecoin to the payment infrastructure.

This is the distinction hidden behind many transactions marketed as ‘gas-free.’

A blockchain cannot process transactions without consuming computational and data resources. Removing the gas payment from a user’s wallet interface does not eliminate those resources or their cost.

Instead, account abstraction allows the responsibility for providing the network’s native fee token to be transferred elsewhere.

Sometimes an application genuinely subsidizes that cost. In other cases, a service pays the network in ETH and collects reimbursement in a token such as USDC or USDT.

The difference matters because those arrangements have very different economic consequences.

And when execution fails, the identity of the party funding the gas becomes even more important.

What Happens When a Wallet Sends Without ETH?

Ethereum transactions normally require the submitting account to fund network fees using ETH.

That creates a practical problem for someone whose wallet contains stablecoins but no ETH.

A user might hold hundreds of dollars in USDC yet be unable to complete a simple transfer because the wallet lacks the native asset needed for gas.

ERC-4337 changes how this requirement can be handled.

Under the ERC-4337 account abstraction specification, users can authorize a UserOperation that describes an action their smart account should perform.

A UserOperation resembles a transaction request, but it is not itself the ordinary blockchain transaction ultimately submitted for inclusion.

That work is handled by a bundler.

The bundler receives UserOperations, validates them, and submits a transaction calling a shared contract known as EntryPoint.

EntryPoint coordinates account validation, execution, and gas accounting. It can reimburse the bundler using funds deposited by either the smart account or a Paymaster.

A Paymaster is a contract that agrees to fund the gas costs of qualifying UserOperations.

This arrangement separates the party authorizing the activity from the party supplying the native currency needed to execute it.

Consider a wallet sending USDC.

The wallet can authorize the transfer through its account logic. A Paymaster can then accept responsibility for the gas, provided the operation satisfies its sponsorship conditions.

The bundler submits the operation to Ethereum or a compatible network, pays the blockchain transaction fee, and receives compensation through EntryPoint.

The user does not necessarily need to hold ETH.

But the network still charges for execution.

As explained in OpenZeppelin’s account abstraction documentation, Paymasters can either sponsor transactions on behalf of users or allow them to cover costs using ERC-20 tokens.

The two arrangements may appear similar in a wallet interface.

Economically, they are not the same.

An application that sponsors transactions using its own budget is taking on an operating expense. A Paymaster that charges users in stablecoins is changing the currency in which those users pay.

Both remove the need for users to manage ETH.

Only the first necessarily removes the direct transaction fee from the user’s financial burden.

There is also an important development beyond traditional smart contract wallets.

EIP-7702 allows externally owned accounts to delegate execution to designated code, making certain smart-account capabilities available without requiring users to abandon their existing wallet addresses.

That helps explain why the practical benefits of account abstraction extend beyond wallets originally deployed as standalone smart contracts.

The underlying cost relationship, however, remains.

Somebody still needs to fund the execution.

Two Real Arbitrum Transfers Reveal the Payment Split

Ravel examined two Arbitrum transactions recorded on May 31, 2026, to identify what happened behind the apparent abstraction of gas payments.

The first transaction recorded at 11:06:25 UTC involved a wallet sending 15 USDT0 to another address.

Arbiscan identifies the submitted transaction as an account abstraction bundle processed through EntryPoint version 0.8.

The transaction was submitted by an address labelled ‘TokenPocket: ERC-4337 Bundler 1.’

The transaction logs show two USDT0 transfers from the wallet.

One delivered 15 USDT0 to the intended recipient. The other sent 0.016085 USDT0 to the address recorded as the Paymaster.

The corresponding UserOperationEvent recorded 165,954 units of gas used and an actual gas cost of 3,345,001,682,892 wei.

Converting wei into ETH produces:

3,345,001,682,892 ÷ 10¹⁸ = 0.000003345001682892 ETH

That amount was paid through the EntryPoint system to the bundler.

The user did not need to send ETH directly to fund the operation.

However, the accompanying USDT0 transfer demonstrates that the interaction was not costless in the ordinary financial sense.

A second transaction recorded at 12:19:10 UTC provides a useful comparison.

It involved the same wallet sending 5 USDT0 to the same recipient.

The Paymaster address was also the same.

This time, the additional transfer to the Paymaster was 0.016106 USDT0.

The EntryPoint recorded 165,941 gas used and an actual gas cost of 0.000003343383582466 ETH.

Ravel’s comparison of the two transactions is summarized below.

Source: Arbitrum EntryPoint events and ERC-20 transfer logs. Values are rounded where indicated.

The comparison reveals something interesting.

The amount sent to the recipient fell from 15 USDT0 to 5 USDT0, a decline of two-thirds.

Yet the token amounts transferred to the Paymaster barely changed.

The difference between the two Paymaster receipts was just 0.000021 USDT0, approximately 0.13% of the first receipt.

The native gas costs were also nearly identical.

Both operations performed broadly comparable work, even though their payment amounts differed significantly.

This is consistent with an important property of blockchain fees: transferring a larger numerical amount of the same token does not necessarily require proportionally more computation.

A transaction’s cost depends on its execution and data requirements, not simply the monetary value being transferred.

That changes how users should interpret fee percentages.

For the first transfer, the additional 0.016085 USDT0 represents approximately 0.107% of the 15 USDT0 sent.

For the second transfer, 0.016106 USDT0 represents approximately 0.322% of the 5 USDT0 sent.

The fee’s relative weight was about three times greater in the smaller transfer.

These percentages are based on two observed transactions. They do not establish a universal Paymaster pricing schedule.

They do, however, demonstrate why a small transaction can bear a comparatively large fee burden even when its gas requirements are almost unchanged.

There is another comparison worth making.

For the first transaction, Arbiscan displays an ETH price of approximately $2,004.42 at the relevant time.

Using that reference price, Ravel calculates the recorded 0.000003345001682892 ETH gas cost at approximately $0.0067.

The accompanying 0.016085 USDT0 transfer had a nominal dollar value of about $0.0161.

That is approximately 2.4 times the dollar value of the recorded native gas charge.

The difference should not automatically be characterized as a 140% profit margin.

The public transaction alone does not establish the Paymaster’s complete operating expenses, pricing arrangement, token-conversion terms, or whether other services are bundled into the amount collected.

Nevertheless, the comparison makes one point unmistakable.

The amount charged or transferred through the token-payment mechanism need not equal the network gas cost when both are expressed in dollar terms.

Removing ETH from the user experience does not necessarily mean passing through the network fee at cost.

A Failed Operation Can Still Leave the Paymaster With a Bill

The more revealing test of gas sponsorship comes when an operation does not succeed.

In an ordinary Ethereum transaction, a failed execution can still consume gas.

ERC-4337 does not abolish that principle.

If a Paymaster has accepted responsibility for a UserOperation that proceeds into execution, it can remain responsible for the gas consumed even when the intended action reverts.

The protocol makes this explicit through its Paymaster settlement process.

The postOp mechanism distinguishes successful operations from reverted ones, allowing the Paymaster to complete its accounting based on the execution outcome.

Ravel found a real example.

On June 12, 2026, an Arbitrum account abstraction transaction was submitted through an address labelled ‘TokenPocket: ERC-4337 Bundler 2.’

The transaction used EntryPoint version 0.8, and the same Paymaster address was observed in the May 31 examples.

But this time, the UserOperation did not complete successfully.

The event shows:

The recorded cost converts to 0.000004318032152 ETH.

Arbiscan listed an ETH reference price of approximately $1,671.89 for the transaction, putting that charge at roughly $0.0072.

The figure is small for one operation.

The conceptual implication is not.

The on-chain records indicate that the failed UserOperation still generated a non-zero cost through EntryPoint, with a Paymaster identified as its gas payer.

Interestingly, the surrounding bundle transaction was marked successful at the blockchain transaction level.

That is not a contradiction.

The outer transaction successfully executed the EntryPoint process and settled the operation’s accounting. The UserOperation contained within it had a failed execution result.

This distinction matters when interpreting transaction explorers.

A successful bundler transaction does not necessarily mean every UserOperation it contains achieved its intended result.

Nor does a failed UserOperation necessarily imply that the bundler’s entire transaction reverted.

The cost was still recorded.

The explorer does not show a corresponding ERC-20 transfer from the user in this failed transaction’s token-transfer summary.

That does not establish that no off-chain reimbursement, later settlement, or separate fee arrangement existed.

It establishes the narrower fact visible in the transaction: the Paymaster was assigned a non-zero native gas cost despite the UserOperation reporting failure.

For Paymaster operators, this creates a financial exposure that does not exist merely on paper.

An application sponsoring large volumes of user activity may need to pay for some operations that produce no successful customer action.

That is one reason Paymasters use validation rules, spending limits, simulations, and sponsorship policies.

They can restrict which operations they accept and how much gas each operation is permitted to consume.

Yet simulation cannot perfectly guarantee a successful final execution, because blockchain state can change between validation and inclusion.

A Paymaster’s business model must therefore account for failed operations as well as successful ones.

Gas Sponsorship, Token Payments, and the Business Behind Both

The word gas-free can conceal several different payment arrangements.

In a genuinely sponsored transaction, the application or another third party absorbs the fee as an expense.

A wallet provider might offer a limited number of free transfers to new customers. A game might sponsor interactions to prevent players from having to acquire ETH before using it.

From the user’s perspective, there may be no direct gas charge.

From the sponsor’s perspective, each operation consumes part of an operating budget.

A different arrangement allows the user to pay in an ERC-20 token.

The Paymaster provides the native gas funding and obtains compensation through a stablecoin or another supported asset.

This is closer to currency conversion and payment intermediation than a subsidy.

The distinction is visible in the services offered by infrastructure providers.

Pimlico’s account abstraction documentation separates its Verifying Paymaster, which enables application-funded sponsorship, from its ERC-20 Paymaster, which lets users pay their gas costs in tokens.

Circle provides another real-world example.

Its Paymaster service allows users to cover blockchain gas expenses using USDC rather than maintaining balances of the native gas token.

Circle distinguishes that service from Gas Station, a separate product that enables developers to sponsor fees for their users.

That product distinction illustrates the economic difference.

One removes the need for users to own the network’s native currency.

The other allows an application to take responsibility for the transaction cost.

There can also be less explicit forms of subsidy.

An application might choose to absorb transaction expenses because it earns revenue from subscriptions, trading activity, service charges, or another commercial relationship.

A transaction may be free at the moment of execution while still contributing to the application’s broader operating expenses.

That does not make the offer misleading by itself.

Businesses regularly subsidize specific activities to improve customer experience.

The question is whether users understand which part of the service is free and which party ultimately carries the expense.

For developers, the economics become more important at scale.

Consider a hypothetical application processing 100,000 sponsored UserOperations.

Assume each operation consumes 150,000 gas and is charged at an effective rate of 0.03 gwei per gas.

The modeled cost per operation would be:

150,000 × 0.03 gwei = 0.0000045 ETH

Across 100,000 operations, the total becomes 0.45 ETH.

At an illustrative ETH price of $3,000, that corresponds to $1,350 in sponsored gas expenses.

This is a hypothetical budget calculation, not a reported expenditure by any actual wallet provider.

It also excludes infrastructure service charges, token-conversion costs, and other operating expenses.

The model assumes every operation has the stated gas usage and fee rate.

Real usage varies by network conditions, contract complexity, and sponsorship rules.

Still, the calculation demonstrates how a seemingly negligible transaction fee becomes a meaningful recurring expense when multiplied across a large user base.

And a portion of that budget may be consumed by operations that fail.

For a service seeking to support millions of interactions, gas sponsorship is therefore not just a wallet feature.

It is an operating-cost decision.

What On-Chain Gas Records Can and Cannot Prove

Account abstraction creates a more complicated transaction trail than an ordinary wallet transfer.

An observer examining only the outer transaction may see the bundler as the transaction sender.

That does not mean the bundler was the party economically responsible for all the gas.

The bundler supplies the network transaction and can be compensated through EntryPoint.

To understand an individual ERC-4337 operation, the observer must inspect the corresponding UserOperation details.

The EntryPoint interface defines an event named UserOperationEvent.

Its fields include the wallet address, Paymaster address, operation success status, actual gas cost, and actual gas used.

The official EntryPoint interface source code identifies actualGasCost as the amount charged to the account or Paymaster for the UserOperation.

That is a different measurement from the total transaction fee shown for the bundler’s outer transaction.

A single bundler transaction may contain multiple UserOperations. Their individual charges must not be confused with the aggregate network fee of the surrounding transaction.

The Paymaster address is also important.

A non-zero Paymaster field establishes that a particular contract accepted responsibility for the operation within the account abstraction accounting system.

It does not automatically establish who economically funded that contract.

The Paymaster might use deposits supplied by an application, receive tokens from users, draw on prepaid service balances, or operate under other arrangements.

The USDT0 transfers in Ravel’s May 31 examples provide additional evidence about that distinction.

They show stablecoins moving from the user to the Paymaster address while the operation’s native gas cost was settled through EntryPoint.

But even those transfers do not reveal the entire commercial agreement behind the service.

The source of Paymaster funding, its complete fee calculation, and any off-chain reimbursement arrangements may require additional investigation.

In the June 12 example, the absence of a visible ERC-20 fee transfer does not prove that the operation was free to every participant.

The EntryPoint still recorded a native gas cost.

These examples demonstrate why a transaction’s cost cannot always be reconstructed from a single field labelled ‘network fee.’

A more complete examination follows the payment through several layers: the blockchain transaction submitted by the bundler, the gas charged to the UserOperation, the account or Paymaster funding that charge, and any separate token transfers or commercial reimbursement.

The resulting distinction is useful for ordinary users as well as developers.

A wallet that allows transfers without ETH has removed a technical inconvenience. That can make stablecoin payments easier, particularly for people who do not want to manage multiple gas tokens.

But removing that inconvenience does not resolve the cost issue.

Sometimes the application pays.

Sometimes the user reimburses a Paymaster in another asset.

Occasionally the expense is absorbed into a broader service model.

And sometimes a failed operation still consumes a sponsor’s funds even though the intended transfer never happens.

The blockchain does not care whether a wallet interface describes the transaction as free. It charges for the resources consumed according to the network’s fee rules.

Account abstraction changes how those charges are assigned and settled.

A gas-free transaction can be free for the user, paid in another currency, or subsidized by someone else. What it cannot be is free of execution costs simply because the wallet never asked for ETH.