# Grokking ERC-4337 transaction fees

In Account Abstraction, transactions are handled differently than in EOA wallets. They are called UserOperations and work through separate Mempool operated by bundlers.

Bundlers collect and execute these UserOps through an EntryPoint contract. One of the responsibilities of EP is to ensure that the bundler is paid back the gas fee used to execute the transaction. This should be sponsored by Smart Contract Wallet itself.
In order to do that, SCW is expected to do a deposit of ether on EP contract and then EP uses this deposit to pay back the bundler. This deposit is what we call a Gas Bank.

What this means to you as a user is that **this EP deposit will be the actual transaction fee**. Not the *Transaction Fee* field that you normally view in explorers like Etherscan.

## Examining an AA transaction

Let's look at an example AA transaction on Polygon:
https://polygonscan.com/tx/0x8bf51350bcc0b039d5cef1e536210684c24e28e09fcd6788a3b88454f9647de4

<br /><br />

Here the field *From* is the address of the bundler that executed this transaction:

<br />

As we mentioned above, AA transactions are executed on the EP contract. This is a common contract used for all AA transaction. It is deployed by the Account-Abstraction EIP-4337 standard developers on the same address in every network:

<br />

First transfer in this transaction is a transfer of MATIC from our SCW wallet to EntryPoint contract:

<br />

Then in the next transfer MATIC is transferred to the bundler address, so it's get compensated for executing this tx:

<br />

As you can see, real TX cost was a bit lower than the bundler compensation:

It's impossible to calculate the exact TX fee before execution, so the bundlers will always get a little more. We are working to streamline this process so that commission discrepancies are as small as possible.

Also note, that our transfer to EP is greater than the bundler reward. Extra funds will stay on an EP contract. This is what we call a Gas Bank.
Gas Bank funds will be used to cover your future transaction costs. There's also an option to withdraw them from EP using contracts `wihtdrawTo` method.

## How do we calculate gas fees in AA?

AA transactions consist of 5 gas parameters that need to be pre-calculated before execution:

- The `verificationGasLimit`, `preVerificationGas` and `callGasLimit` values are used to calculate the total gas consumption of UserOp. These parameters are calculated by our Bundler providers - we use Stackup and Alchemy.
- The `maxFeePerGas` and `maxPriorityFeePerGas` determine how much a user is willing to pay for a transaction and the speed at which it is executed. They greatly affect the total cost of transactions, so we're using a specialized price oracles such as Blocknative to calculate them.

## Why AA fees bigger than EOA

### Difficulties with L2 gas estimation. Optimism overpayments

We have had cases where users reported large overpayments to bundlers on Optimism.

Its important to understand the L2 distinctions, especially when it comes time to estimate gas fees:

> L2s like Polygon, Arbitrum and Optimism will “roll up” many transactions into a single batch and then post them onto the layer 1 blockchain. This transaction cost isn’t free as L2s need to pay for the calldata costs incurred when posting a large batch of data to the L1 chain.
>
> L2s need a way to charge their users for these incurred L1 calldata costs. Rollup frameworks like Polygon, Arbitrum and Optimism achieve this in different ways.
>
> Source: alchemy.com/blog/l2-gas-and-signature-aggregators

This means, that in L2 case a bundler submitting a bundle transaction on an L2 is charged for L1 fees. Currently, bundlers cannot effectively estimate L1 fees, so they had to solve this problem by increasing the L2 gas. Because of this, you can sometimes overpay for a user operation on Optimism.

> Stackup comment:
>
> This is an ongoing issue with L2 + Rollup integration that has to do with the preVerificationGas (PVG). L2 gas is based on 2 components, the L1 callData cost and the L2 execution cost. During estimation the bundler grabs the latest L1 callData cost and adds it to the PVG. However, sometimes after a user has sent the UserOp, the L1 callData cost can decrease significantly but the PVG has already been locked in. Hence why you sometimes see the transaction fee is a lot lower than userOp fees.

We're in contact with bundlers to resolve this issue as soon as possible.

### Insufficient performance of bundlers

Today most of AA transaction bundles contain only one userOperation.
You can view this statistics here - dune.com/johnrising/erc-4337-profitability

This is simply because there is not much volume. Not many user operations are being sent at the same time, so they aren't bundled into a single transaction. Obviously, this means that transactions do not utilize the efficacy of bundles and are more expensive than if there were many user operations happening at once.

We expect changes for the better with increased adoption of the account abstraction standard.

## Complete transaction payment flow

## Useful links - tech stuff

Actual Dune statistics:
- [johnrising/ Bundle Health](https://dune.com/johnrising/erc-4337-profitability)
- [niftytable/ Smart Accounts Adoption Stats](https://dune.com/niftytable/account-abstraction)

Alchemy:
- [How User Operation Fees are Estimated and Charged](https://www.alchemy.com/blog/user-operation-fee-estimation)
- [ERC-4337 Gas Estimation for L2s and Signature Aggregators](https://www.alchemy.com/blog/l2-gas-and-signature-aggregators)
- [You Could Have Invented Account Abstraction: Part 1-4](https://www.alchemy.com/blog/account-abstraction)