EIP-8141: Frame Transaction

[DanielVF]

I believe that EIP-8141 frame transactions as specced right now:

1. Will not be adopted widely
2. Will have a larger ongoing cost than I think we expect
3. Will hamper future protocol evolution

A simplified tempo style transaction should not suffer these same problems.

This is post one of three, discussing adoption problems, and I’ll discuss costs and simplified tempo style transaction in the later two posts.

---

I just pulled data from 10,000 blocks in the middle of Ethereum’s busy time of day. (Blocks 24598000 to 24598999). Here is a pie chart of non ERC-7702 transactions vs ERC-7702 transactions.

Out of 288,508 transactions in these blocks, 814 were EIP-7702, or 0.28%.

[A previous version of this post said there were 14 transactions to an address with EIP-7702 code. This is the number of direct EIP-7702 transactions, and did not account for calls to EIP-7702 via entrypoint contracts]

With the current transactions types, people can use any combination of wallets, software or hardware to control a given account that has assets attached to it. However, EIP-7702, EIP-4337, and EIP-8141 all try to change users to own smart contracts which own the user’s assets and identities.

On paper this sounds like the same thing, but I’m convinced that this is the core adoption killer. Users have voted hard against EIP-7702.

Smart contracts as the asset owner means:

1. In practice, most wallets do not implement this feature, because it’s expensive and dangerous.
2. Because each wallet is using its own smart contract codebase, each user account is now locked into a particular wallet vendor, at least in practice. Interoperability is gone, even on the same chain.
3. Using it requires extra setup steps from the user.

To these problems EIP-8141 adds the further barrier that to upgrade what a user smart contract account can do, or to fix bugs, or add QR auth methods, the user will have to identify and move all assets to another smart contract account. (The alternative, using upgradable proxies is probably even worse)

Needs for changes over time in authentication smart contracts aren’t theoretical. How many EIP-4337 entrypoint contract upgrades have there been? We’re up to v0.9.0, between bug fixes and new features.

Using smart contracts as the core of a users identity is too costly on wallets to even be given as choice to a users, and not selected by users even when given the choice. Not only does this obviously make adoption low, but it ensures that negative network effects continue pushing adoption down even further.

In the end the benefits of adding 7702 to ethereum and across the ecosystem has not been close to worth the cost.

We may disagree on the causes of 7702’s negligible adoption. But we absolutely must understand why such low adoption happened before rolling out a third attempt at moving away from keys to smart contracts.

---

I’m seeing the perception that EIP-8141 is a simple standard that provides an unlimited set of options for the future, and will massively reduce the amount of work on transactions in the future.

Instead, from my point of view, I see it pushing necessary complexity out from the core into clients, wallets, and mempools, requiring multiples of the amount of effort it would have taken to do it in the core. Not only does this result in more work, and more risk, but it kills interoperability.

What are the bytes that a wallet sends over a transaction to authorize moving 1 Eth from one address to another? EIP-8141 at this moment doesn’t define this. The authorizing address contract code could have any code under the sun, so we don’t know what the wallet should send.

How much gas can an authorization use? Spec doesn’t say. It’s up to people to figure out some day. If you are designing a smart contract to do auth, you don’t know.

Moving things that need to be standardized out of the EIP will result in this being much harder for teams to actually implement and will result in incompatible implementations. We’ll see the same thing we are seeing with EIP-7702.

To be fair, EIP-8141 is much better than 7702 in one aspect - the actions to be executed are now standardized, rather an unspecified something to be extracted out of calldata by various smart contracts. This is definitely an improvement, and we need to look for other opportunities like this.

---

Enshrining default code for EOAs to enable frame transactions to also operate in the traditional account centric way is a good thing for this spec. It adds batching capabilities to all current EOA accounts. It gives wallets a reason to implement the minimum required to be able to send an EOA based frame transaction.

However, as soon as we move beyond enhancing EOA functionality, we are right back into the same adoption killers discussed before. In the real world, I would expect that 99+% of frames transactions would be to ecrecover EOA’s.

And if that is the case, then instead of adding all the complexity and cost of frame transactions, we can achieve the same gain in capabilities for drastically less long term cost by just making a simple transaction type that does not deeply constrain the future.

[derek]

@DanielVF Thanks for the very thoughtful analysis. I largely agree with what you are saying – I’ve been working on commercial AA solutions for the past 3 years and the pain points you’ve listed for smart contract accounts are very real, and I agree with your main point that the average user (and the average wallet) may prefer EOAs over contract accounts, for security, lock-in, and portability reasons.

As you noted, the fact that we are adding EOA support to 8141 is a step in the right direction. However, you ask a good question which is: if we anticipate most of 8141’s usage to come from EOAs, why not just implement a much simpler transaction type (i.e. a Tempo-style transaction type) that’s optimized for EOAs?

Here’s is my answer: I think there’s real value in enabling native AA for contract accounts, because even though they may not be better than EOAs for the average user, they can enable really powerful use cases that bring a lot of value to the ecosystem, such as multisig accounts and private accounts. What makes Ethereum great is that it’s a general-purpose computing platform not biased towards any specific use case, so I wouldn’t want Ethereum to be locked into an AA design that’s friendly to EOAs but unfriendly to contract accounts.

Therefore, I think it’s worth striving for a proposal that satisfies both goals:

• Improve UX for EOAs
• Enable native transaction capabilities for contract accounts

And I think with some additional improvements to 8141, we can do just that. Here’s what I have in mind:

• Allowing VERIFY frames to call into signature precompiles directly, including ecRecover and P256VERIFY today but may include other precompiles in the future such as QR precompiles.

• When using a precompile, the sender becomes a EOA derived from that precompile. This means that we will actually have more types of EOAs – not just k1 EOAs like today but also r1 EOAs, and even QR EOAs in the future.

  • Either in this EIP or a future EIP define a signature-agnostic way for EOAs to migrate their signature schemes or migrate to a contract account, so that k1/r1 EOAs today can migrate to a QR EOA or contract account in the future.

• Enrich the execution capability of frame transactions, so that it can perform more powerful executions such as atomic batching and transacting with value (neither of which is supported by the spec as of today).

  • This is important because if we are going to make EOAs a first-class citizen for frame transactions, we need to ensure that EOAs can perform these execution patterns even without any code.

Note that none of what I listed above conflicts with the goal that frame txns should also support contract accounts. So someone with an advanced use case like private accounts will still be able to do so with frame txns, but the majority of average users can happily send frame txns with EOAs.

Also note that while the sender may be an EOA for the average user, I fully expect even the average user to leverage contract payers in a routine basis. As my experience with commercializing ERC-4337 suggests, while users and wallets have qualms with entrusting complex smart account implementations, they have no problem using complex paymaster setups, because the security risks of paymasters are fully isolated from that of the account. Since 8141 is also designed such that payers are isolated from senders, I fully expect that EOA senders will happily reap the benefits of gas abstraction (e.g. paying gas in ERC20s and getting sponsored by DApps) by leveraging contract payers.

[matt]

I get that EIP-8141 is disruptive to Monad and that is probably why you are very involved in this thread, but I don’t think Monad’s choice of execution model should hinder our ability to deliver a great experience to Ethereum users.

We believe that EIP-8141 will actually provide a better experience for Ethereum users in the areas we care about: UX, security, and privacy.

–

Since you are trying to extrapolate on 7702 to understand 8141, it’s important to point out that you have several misconceptions about 7702:

• The number 7702 authorization transactions does not equal usage. Vast majority of accounts only delegates once. From then on, they send standard 1559 txs.
• We are seeing 7702-enabled accounts sending over 4m operations per week now. That’s not a trivial number.
• Not all transactions are consumer wallet transactions. Many are bots transacting programmatically. They have little use for 7702.
• There is no need for a single sender to send multiple times per block if they have a 7702 account, because they can bundle all of their operations in one transaction. Multiple sends per block would typically be bots.

Your image is provocative but meaningless. You can see the number of weekly ops by 7702-enabled accounts is not trivial:

Source: BundleBear EIP-7702 Metrics - Smart Wallet Data

Users have clearly not voted “hard” against EIP-7702. Almost every major wallet supports 7702. Maybe in Monad things are different? I think with we have a clear path to even better adoption of 8141 vs. 7702 with the default account for EOAs.

–

Re: your other questions and comments on 8141:

Needs for changes over time in authentication smart contracts aren’t theoretical. How many EIP-4337 entrypoint contract upgrades have there been? We’re up to v0.9.0, between bug fixes and new features.

The entrypoint is equivalent to the protocol in 4337 world. Of course the protocol changes over time. That doesn’t mean there is a backwards compatibility issue with users.

What are the bytes that a wallet sends over a transaction to authorize moving 1 Eth from one address to another?

They would encode it based on their smart account implementation. For 4337-compatible wallets, that means it is encoded as a user op.

How much gas can an authorization use?

The protocol does not put a constraint on it. This allows for features like transaction constraints to be offered, allowing much better security for users. It is mentioned a couple times that the mempool will follow similar rules to ERC-7562, which states transactions have 500k for validation gas. This number may change as client implement the feature. This is pretty standard practice for an EIP that is still ~1 year from goingn live.

In the real world, I would expect that 99+% of frames transactions would be to ecrecover EOA’s.

The point is that it allows users to freely choose more secure account systems without being penalized by the protocol. Ethereum was built on concept of permissionless innovation and we have for a long time wanted to bring this concept to account definitions. Clearly there is much more than 1% of accounts today using EIP-7702, so I don’t think your 99+% estimate will be accurate.

[DanielVF]

@matt I’d love for you to check my exact data, since the number of transactions where EIP-7702 was used in a transaction surprised even me. I rechecked my calculations this morning, as well as spot checked some of the raw data.

• Blocks 24598000-24598999 inclusive.
• 288,508 transactions
• 51,638 unique to address
• 13 of those to addresses start with 0xef0100
• 14 transactions to EIP-7702 addresses (one address had two txs)

I’m not counting EIP-7702 authorizations - I know those can be one time and would not be a good metric. I’m counting any transaction to an account with EIP-7702 code prefix and length (which would then execute the delegated code)

Capability to use a feature is interesting but not a measure of the impact of a feature. In fact, widespread capability with negligible use would be an even stronger argument against something than limited capability with negligible use. For informing future protocol design, the most useful metric is actual counts of transactions that use EIP-7022.

[frangio]

@DanielVF

14 transactions to EIP-7702 addresses (one address had two txs)

If EIP-7702 is used with ERC-4337 infrastructure, transactions would not be directly sent to delegated accounts but will go through the Entrypoint contract instead. The same about any other setup that uses a contract to batch multiple operations. To count these we need to look at traces.

BundleBear reports the following breakdown for EIP-7702 for March 6th 2026:

relayed actions: Actions initiated by a third-party wallet that calls the smart account’s code (without using 4337)
erc-4337 userops: Actions done using ERC-4337 UserOperations
self-initiated txns: Transactions where the smart account runs its own code
eoa txns: Regular transactions where the smart account didn’t use its code

[DanielVF]

Thanks, makes sense. I’ll dig up that data over the same time period.

[DanielVF]

Thanks again. Looks like 800 user ops to accounts with EIP-7702 code submitted through entry points contracts during the blocks I was looking at. I updated the chart and numbers in the original post. This now lines up into the range I was expecting, and I think we can approximate as less than 1% of transactions.

Usage does appear to be trending up over time.

[matt]

You’re recreating the two smallest categories of use though – about ~5% of total 7702-related activity. Just check bundlebear: relayed actions and EOA tx from 7702-enabled account are far more common.

[DanielVF]

@Derek, I basically agree with everything in your post. It’s great to see that a lot of this is now in the main spec.

Enabling better payments is a key thing that old transactions don’t have.

I would definitely naively expect all frames to revert if one failed.

[frangio]

It’s very hard to understand who pays for gas from the spec. I could only find it in parentheses in the part about refunds. I think it should be made explicit in the behavior section where the gas payer is mentioned.

I don’t think DEFAULT is a good mode name, especially with the new unrelated notion of default code, but also because historically the default execution mode has been SENDER.

RLP is not great for decoding in the EVM. This would be an issue if calls needs to be decoded on chain by another account in another frame, e.g. payer, but I’m not sure that would ever be necessary.

Default code is currently used for any EOA that is a frame target. I’d expect it to only apply when frame.target is tx.sender.

What is the behavior of APPROVE in non-VERIFY frames?

[matt]

• Will update to make it more clear about the payer.
• Open to another name for DEFAULT mode.
• This I was also on the fence a bit about, but yeah, I think ABI encoding is probably best here after all.
• I think it could be useful to have multiple frames using differ EOA default accounts in some batching systems. But my preference here is weak.
• It behaves normally outside VERIFY frames and can set the approval scope when needed.

[derek]

RLP is not great for decoding in the EVM. This would be an issue if calls needs to be decoded on chain by another account in another frame, e.g. payer, but I’m not sure that would ever be necessary.

We are planning to remove that from the default code and support atomic batching in frames directly. Just created this PR: Update EIP-8141: add support for atomic batching via SENDER_ATOMIC by derekchiang · Pull Request #11395 · ethereum/EIPs · GitHub

What is the behavior of APPROVE in non-VERIFY frames?

Per discussion with the coauthors, we feel it’s fine to disallow APPROVE in SENDER frames which is clarified in the PR above as well. We may still keep APPROVE in DEFAULT frames to allow for stateful approvals, which would not be able to propagate in the public mempool but may enable valid use cases in private pools.

[0xrcinus]

• I think ENTRY_POINT could work as a name instead of DEFAULT (it is clear what it is)
• The default execution for EOAs is a very positive development. I think referring to it as “code” is leading to some confusion about how it works (it implies some kind of deployed code, instead of standard handling of VERIFY frames)
• Default execution currently only applies where frame.target != tx.sender. I think that it could also be interesting for an offchain paymaster, so if frame.target != tx.sender, only APPROVE 0x1 would be allowed. This could allow fee sponsorship equivalent to the Tempo Fee Sponsorship model
• The open PR by @derek has some good additions, and makes the current non-atomicity default clearer. I think lots of developers would expect atomicity by default for SENDER frames. Are there specific use-cases in mind for multiple separate atomic blocks? I wonder if a PRE / POST hook-type model might be interesting

[frangio]

The introduction of default code for EOAs has also added support for native P256 accounts. I think this is potentially very controversial and deserves more discussion. These acccounts do not support key rotation, which is one of the motivations for account abstraction and thus this EIP. This is particularly bad for passkey-based accounts because passkeys are bound to the domain that creates it.

[DanielVF]

The EIP-8141 spec has payer approval being checked after all frames have run. This mean that the potential cost to check a single inclusion of a transaction can be the entire gas cost of the transaction, which in turn could be up to the maximum possible transaction gas cost for the chain. (16.7 million on ethereum)

Limiting the gas allowed to be used in a VERIFY frame doesn’t help here, since the payment VERIFY could be running at the end of the frames, after everything else has executed.

As a consequence, every system involved in mempools is now involuntarily a part of a computationally expensive MEV searcher network.

Basic EIP-1559 transactions that make up almost all current transactions, require just three account state reads (balance, nonce, code present) to be able to approve a transaction’s inclusion. Any further filtering from there is optional and based the economics of being able to order a block better or meet off-chain commitments. The floor stays low and simple, and complexity is optional and paid for. This is good.

For blockchains to be able to continue to function well with EIP-8141, it will require both designing and building the ability to defend the mempool on client implementations, which would probably exceed the work required to implement the EIP-8141 spec itself.

Secondly, the speed of transaction inclusion for block building is on the critical path for Ethereum performance, and becomes increasingly important as the chain wants to scale up. Ethereum’s strawmap has a 3x increase in gas limits and 2x+ faster blocks. Other EVM chains already have experience going faster than Ethereum does today, and are concerned about the performance impacts of Frame Transactions:

• Tempo has already rejected frame transactions and shipped their own transaction type.
• Base has drafted EIP-8130, specifically as an alternative to EVM driven inclusion in transactions. From the motivation section: “Account abstraction proposals that delegate validation to wallet code force nodes to simulate arbitrary EVM before accepting a transaction. This requires full state access, tracing infrastructure, and reputation systems to bound the cost of invalid submissions.”.
• Monad and frame transactions are mutually incompatible due to asynchronous execution, plus all the reasons from Base.

While it’s no requirement for Ethereum build with other EVM chains in mind, it should be worth some thinking if there is uniform pushback on a feature from chains that are farther along the performance road.

And these concerns are there even though both Tempo and Base run centralized(ish) sequencing, and so face much reduced complexity and cost when compared to ethereum at the same performance levels, and they have ability to run megabeast hardware for this role. In contrast Ethereum’s has a goal of many client implementations, and low hardware requirements so that anyone can be a validator and build a block, all of which make performance more important.

---

However, in spite of everything I’ve said so far, beyond the effort to safely implement it from different groups I do not think frame transactions will cause major problems for Ethereum as specced today. It’s just hard work. But I do think frame transactions will constrain Ethereum’s future, by soft capping speedups, and making future EIP’s more difficult.

[DanielVF]

Okay, I’m done being negative for now. Over the past two weeks of my looking at EIP-8141, the spec has gotten much better.

The EOA account changes mean that Frame Transactions will be able to deliver a better experience to almost all users, right out of the box. This is fantastic. I think this spec will be used.

I’ve also learned that my priors around EIP-7702 adoption being stalled were wrong - usage has started sharply increasing around the start of the year.

So what’s the way forward here? EIP-8141 now provides real benefits, to everyone not just smart contract account holders, but it still has unpleasant side effects on faster chains.

One option is to make followup EIP that specs out a subset of EIP-8141 that forbids the deep computation and state access, as well as enforces some structure on how this subset of frame transactions should be built.

In this way:

• Wallet software can use a simple, ultra well-defined spec that they can implement to immediately, so they can start getting benefits from frame transactions over old style transactions. This speeds up initial adoption of frame transactions and does not require wallets to build and secure new smart contracts before benefiting from Frame Transactions.
• Ethereum can implement the full EIP-8141, which achieves the Ethereum objectives of “one final transaction type” and provide the smart contract based identities that you want.
• Other performance EVM chains can start by implementing the subset. They get the benefits of a better transaction type without having a cost multiplier on computation and wide state access.

[derek]

Yes for the reasons you listed we are likely going to remove it, and potentially replace that with defining a minimal, audited P256 contract account in the spec but not enshrining a native P256 account.

[alex-forshtat-tbk]

@DanielVF

This mean that the potential cost to check a single inclusion of a transaction can be the entire gas cost of the transaction, which in turn could be up to the maximum possible transaction gas cost for the chain. (16.7 million on ethereum)

Limiting the gas allowed to be used in a VERIFY frame doesn’t help here, since the payment VERIFY could be running at the end of the frames, after everything else has executed.

You would be limiting “gas allowed to be used by all frames before final APPROVE" though, not “gas allowed to be used in a VERIFY frame”.
This seems like reasonable thing to do in general, isn’t it?

[0xrcinus]

I am probably missing something obvious, but why isn’t it required that the VERIFY frames come first (perhaps allowing for one constrained deployment frame), rather than allowing a VERIFY frame at the end of of all the SENDER frames? Is there a specific use-case in mind for this kind of flexibility?

[Note that the currently open PR actually makes this change, as it requires payer_approved = true for SENDER frames (the rationale in the PR description mentions disallowing calling APPROVE in SENDER_ATOMIC frames, but it has this additional effect)]

[matt]

You could have a transaction that only decides to pay after the execution, which may occur with SENDER frames.