Account abstraction 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 (EP) contract. One of the responsibilities of EP is to ensure that the bundler is paid back the gas fee used to execute the transaction. Smart Contract Wallet (SCW) itself should sponsor this.
To do that, SCW is expected to deposit to 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
Here the field From is the address of the bundler that executed this transaction:
As we mentioned above, AA transactions are executed on the EP contract. This is a common contract used for all AA transactions. The Account-Abstraction EIP-4337 standard is deployed on the same address in every network:
The first transfer in this transaction is a transfer of MATIC from our SCW wallet to EntryPoint contract:
Then in the next transfer, MATIC is transferred to the bundler address, so it get compensated for executing this tx:
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 for AA transactions?
AA transactions consist of 5 gas parameters that need to be pre-calculated before execution:
The
verificationGasLimit,preVerificationGasandcallGasLimitvalues are used to calculate the total gas consumption of UserOp. These parameters are calculated by our Bundler providers - we use Stackup and Alchemy.The
maxFeePerGasandmaxPriorityFeePerGasdetermine 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 oracle such as Blocknative to calculate them.
Why AA fees bigger than EOA
Difficulties with L2 gas estimation. Optimism overpayments.
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.
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 answer:
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 AA transaction bundles contain only one userOperation. You can view these 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. This means that transactions do not utilize the efficacy of bundles and are more expensive than if many user operations were happening at once.
We expect changes for the better with increased adoption of the account abstraction standard.
Last updated
