In April of 2016, issue #86 was opened in Ethereum's EIPs repository. Entitled Proposed initial abstraction changes for Metropolis, this was the first major proposal trying to solve the problem of account abstraction (AA). Ten years and more than eight thousand EIPs later, EIP-8141 (Frame Transactions) was proposed as the headliner for the Hegota upgrade. This article tells the story of how we went from EIP-86 to EIP-8141 and what it took to get there.

My goal here isn't to enumerate and briefly explain each proposal. Instead, I want to give a better sense of the problem itself: what trade-offs are involved, how the thinking evolved over time, and why we are still talking about it. While I'm not assuming any familiarity with AA, I do expect the reader to have some basic Ethereum knowledge, such as the difference between EOAs and contracts, the CREATE2 opcode, and how nonces work. There are other concepts we'll need, but we'll cover them before we start.

Basics

This section introduces some basic concepts that are important to understand the rest of the article. We'll also start building a mental framework that will help us think about the different account abstraction proposals we'll explore.

What's not abstract about accounts?

Let's start with a simple example to explain how Ethereum accounts work and what their limitations are. We'll come back to this example many times throughout the article to explain different AA mechanisms.

Alice wants to send 1 ETH to Bob, who has never interacted with Ethereum before. Bob wants to receive that ETH and then transfer 0.1 of it to Charlie. Assuming Bob wants to use an EOA (the default path for most new users), this is what will happen next:

1. Bob generates an ECDSA pair and derives a public address from it. He shares the address with Alice, and she sends the ETH.

2. Once Bob receives the ETH from Alice, he builds a transaction that looks like this: { to: charlie, value: 0.1 ETH, nonce: 0, gasLimit: 21000, gasPrice: X }. He signs that transaction with the private key from the first step, and then sends the signed transaction to some node. The transaction is propagated through the network.

3. Nodes that see Bob's transaction perform some checks to verify that it's valid. For example, they:

   • Check that the signature is valid and use it to recover the address of the sender (Bob, in this example).

   • Check that Bob's balance is at least gasLimit * gasPrice, since that's the maximum amount of ETH he could end up spending from the transaction.

   • Check that the nonce of the transaction matches the nonce of Bob's account.

   If any of these checks fail, the transaction is dropped. Otherwise, the nodes add it to their mempool.¹

4. Eventually, a block builder creates a block that includes Bob's transaction. Once that happens, Bob and Charlie can see that the 0.1 ETH was transferred.

There are many things in this example that are "hardcoded" at the protocol level:

• An EOA is managed by a single, unchanging ECDSA key.

• Access is all-or-nothing: if you have the private key, you can do anything you want with the account; if you don't have it, you can do nothing at all.

• The account sending a transaction and the account paying for its gas are always the same.

• The block builder is always paid in ETH.

• Replay protection is handled by a single, monotonically increasing nonce.

These aspects rule out several use cases: you can't rotate the key of an EOA, allow other people to use it within some limits, or have some social recovery mechanism in case you lose your key. Applications can't sponsor the gas cost of transactions for users. UX mechanisms like batching are not possible. The list goes on.

There's also another big problem: it's widely assumed that ECDSA will be broken by quantum computers at some point in the future. This means that all EOAs, as they exist today, will eventually be compromised. This is an existential risk that needs to be fixed sooner or later (and sooner would be nice).

What about smart wallets?

Instead of an EOA, it's always been possible to use a contract that acts as a wallet. These "smart wallets" fix every problem we mentioned above: you can have multisig schemes, use complex authorization mechanisms, rely on cryptographic primitives other than ECDSA, etc.

The problem is... who calls the smart wallet? That call, wherever it comes from, is ultimately part of a transaction, and transactions can only be initiated by EOAs.

Smart wallets are the best solution, because the most powerful way to abstract something is to let it be arbitrary code. But they aren't a complete solution as long as they need EOAs. In that sense, the problem of account abstraction can be reframed as: how do we initiate actions from smart wallets without using EOAs?

Now that we have the basics in place, let's start with our story, which takes us back to the beginning of Ethereum itself.

Part 1: Early attempts (2015–2020)

One of Ethereum's goals from the start, and arguably its entire raison d'être, is the high degree of abstraction that the platform offers.

— Vitalik Buterin, July 2015

The fact that EOAs were too rigid and quantum-unsafe was known even before Ethereum's first block was mined. At the time, though, the separation between EOAs and contracts was deemed a reasonable trade-off to ship the chain sooner. But less than a year after the launch, there was already one proposal addressing the problem.

EIP-86: Unsigned transactions

In the Basics section, we said that smart wallets fix every account abstraction issue, since they can be used as accounts and implemented in any desired way. The problem would end here if it weren't for the fact that smart wallets still need those pesky EOAs to call them.

With this in mind, the solution proposed by EIP-86 is laughably simple: just allow unsigned transactions to be mined. The EIP adds a new kind of transaction that doesn't include a signature (and therefore doesn't have a sender), and that builders can include in new blocks. To use a smart wallet, you simply call it with one of these EIP-86 transactions. The data includes everything the wallet needs to verify it's a valid call and to execute the intended action.

The main question is: why would block builders include these transactions? If they don't have a sender, then there's no one to pay for their inclusion. EIP-86's answer is that wallets themselves can pay the block builder after verifying that the transaction is valid. This is possible because the address of the block builder can be obtained through the COINBASE opcode.

The following pseudocode shows what an EIP-86 smart wallet would look like. For simplicity, the wallet in this example uses a single ECDSA key, so its functionality is not really different from that of an EOA. But since this is code, the validation could do anything else, like requiring 2 out of 3 signatures from a list of approved addresses, or allowing key rotation.

# get the destination, value, gas price, and signature from the transaction data
to = tx.data[0:32]
value = tx.data[32:64]
gasPrice = tx.data[64:96]
sig = tx.data[96:128]

# check the signature is correct
verify(tx.data[0:96], sig)

# figure out how much to pay the block builder and transfer it
gasPayment = tx.gasLimit * gasPrice
transfer(block.coinbase, gasPayment)

# do whatever you want in the rest of the execution; here
# we just make an ETH transfer to some destination
transfer(to, value)

To check if a given EIP-86 transaction is valid, a node simply executes it and checks at the end that there was a payment. If there wasn't, it drops the transaction.

Alice, Bob, and EIP-86

Let's go through our Alice and Bob example to understand how EIP-86 would work in practice. Bob starts by sharing the address of his EIP-86 wallet with Alice, who then sends it 1 ETH (she doesn't care whether Bob's address is an EOA or a contract). Once he receives the transfer, Bob builds a piece of transaction data that looks like this:

txData = [charlieAddress, 0.1 ETH, gasPrice, sign([charlieAddress, 0.1 ETH, gasPrice])]

where the signature is computed over all the other fields. He then sends this data in an EIP-86 transaction, with his own wallet as the target and some reasonable gas limit:

{
  "to": bobAddress,
  "gasLimit": 100000,
  "data": txData
}

When nodes receive Bob's transaction, they execute it to check if it's valid (that is, if it pays the coinbase address). The transaction then stays in the mempool until eventually a block builder includes it in a block.

Deployments with EIP-86

Did you notice how I cheated? When we introduced the Alice and Bob example, we explicitly said that Bob had never interacted with Ethereum before. But in the previous section I assumed that he already had a smart wallet whose address he could share with Alice. So let's fix that.

In principle we seem to have a circular problem: Bob wants to receive some ETH using an EIP-86 wallet but he can't deploy such a wallet if he doesn't have ETH. To make things harder, we are trying to accomplish this without involving an EOA; we want our AA solution to be complete. This seems unsolvable, but we'll actually see a few approaches that work.

In the case of EIP-86, one solution arises from the following fact about the EVM: when the initialization of a contract (its constructor, in Solidity terms) is executed, it can use whatever ETH is already present in the address where it will be deployed. This means that the wallet can pay the block builder for its own deployment, just as it does for normal transactions.

With that in mind, Bob can share with Alice the address where he knows his contract will eventually be deployed. Once the address has the ETH that Alice sent, Bob can use an EIP-86 transaction to deploy the wallet. Our problem reduces to how Bob knows where his smart wallet will be deployed.

Nowadays the answer is obvious: we use some CREATE2 factory to predict the deployment address. But the CREATE2 opcode wouldn't be added to Ethereum until 2019, three years after EIP-86 was proposed. Instead, the EIP itself introduces a CREATE2-like behavior for deployment transactions. This also makes sense if you remember that in normal transactions the deployment address is derived from the sender and its nonce, but in an EIP-86 transaction we don't have either of those! Deriving the address from the init code and some salt is then a natural idea.

To recap: Bob builds an EIP-86 deployment transaction for his smart wallet but doesn't propagate it yet; he only uses it to know the address where it will eventually be deployed. He shares that address with Alice and, once she sends the ETH, Bob propagates the deployment transaction, whose init code at some point pays the block builder. After all this, Bob can use a normal EIP-86 transaction to send some ETH to Charlie from the just deployed wallet, as we explained in the previous section.

EIP-86 problems

Believe it or not, EIP-86 satisfies all of our AA requirements: you can deploy and interact with smart wallets without needing an EOA, and there's no constraint on what those wallets can do. Problem solved? Well, no, because EIP-86 introduces as many issues as it solves.

A major issue with EIP-86 is that the block builder must execute the whole transaction to figure out if they are going to get paid. One could suggest running it only until a transfer to the coinbase happens, but this wouldn't work: the transaction could fail right at the end and revert its state changes, including the payment. Compare this with a normal EOA transaction, where the validation has a fixed, upfront computational cost and the block builder is paid regardless of whether the transaction reverts.

Having a fixed, reasonable validation cost is important to prevent certain Denial of Service (DoS) attacks against the network. You can try to clog nodes today by sending a large number of invalid transactions, but the fact that the validation cost is constant means that the problem is manageable. Things change if you allow invalid transactions that can force the node to do unbounded work. With EIP-86 you could send thousands of unsigned transactions that use as much gas as possible and revert right at the end. The node would get overwhelmed by having to run them all. And even if it can take measures against the person doing the DoS, the balance of power shifts in favor of the attacker.

Another issue is related to refunds. If you send a normal transaction with a gas limit of 100,000 and the execution cost is less than that, the unused gas is "returned" to you at the end. With EIP-86 that's not really possible, because the block builder has no obligation to say "hey, you didn't need to pay that much, here's your change" and forcing this at the protocol level is difficult.

A third issue has to do with the uniqueness of transaction hashes. In normal transactions, the nonce is unique for each sender, and so the combination of nonce and signature is unique for each transaction. Since a transaction hash is computed over the whole signed transaction, the hashes themselves are therefore unique. That's not the case with EIP-86 because there are no nonces.

This is, in theory, a solvable problem, because there's nothing at the protocol-level that requires hashes to be unique. In practice, though, many things would break in the upper layers. To give just one example: an API that receives a transaction hash and returns a transaction object would have to be updated to return a list instead. And since that would be a breaking change in itself, every consumer of that API would have to be updated too.

The idea of breaking hash uniqueness was already considered disruptive in 2016, when Ethereum had just launched. In 2026, the idea of breaking absolutely everything for the niche benefits of nonce abstraction is unthinkable. For this and other reasons, nonce abstraction was eventually dropped as a goal. In the rest of the article, we'll ignore anything related to this, even if in reality many subsequent proposals kept attempting to abstract nonce management.

EIP-859: PAYGAS

The two main problems of EIP-86 are that the cost of validating a transaction is not constant, and that you can't refund unused gas. EIP-859, proposed in 2018, solves both of those problems by adding a new opcode: PAYGAS. This opcode takes a gas price as its input, multiplies it by the transaction gas limit, and pays this value to the block builder from the contract's balance (halting if this balance is not enough). In a sense, this is a shortcut to what we were already doing manually when we obtained the coinbase address and made a transfer to it. But having an opcode gives us two properties we can't get without changing the EVM:

• PAYGAS works as a checkpoint. If the transaction fails after PAYGAS was used, the state is reverted to the point when the opcode was executed. The payment to the block builder and any state changes that happened before it are kept.

• At the end of the transaction, any unused gas is refunded to the account using the same gas price that PAYGAS had as its input.

The smart wallet we used for EIP-86 doesn't need to change that much to work with EIP-859:

# get the destination, value, and signature from the transaction data
to = tx.data[0:32]
value = tx.data[32:64]
gasPrice = tx.data[64:96]
sig = tx.data[96:128]

# check the signature is correct
verify(tx.data[0:96], sig)

# use the PAYGAS opcode to pay the block builder
paygas(gasPrice)

# do whatever you want in the rest of the execution; here
# we just make an ETH transfer to some target
transfer(to, value)

This opcode clearly solves our refunds problem. What about the validation time?

For EIP-86, we suggested that nodes could expect the payment to happen near the start of the execution, and reject transactions that don't pay "soon enough". The problem with this idea was that a transaction could indeed pay close to the beginning and revert later. If we have a checkpointing opcode like PAYGAS, though, that same idea works: the node can ignore anything that happens after it because the rules of the protocol dictate that the payment is irreversible.

In more concrete terms, nodes can agree on a gas threshold (say, 200,000 gas) within which they expect PAYGAS to happen. If the opcode is not executed within that limit, the transaction is considered invalid and dropped. Crucially, this is a rule about the mempool, not the protocol. This distinction matters in the context of AA, so let's dive deeper into it.

Mempool rules

It will soon become clear that issues arising from transaction validation and the mempool are the main source of complexity in account abstraction. To better understand why, let's see how the mempool works in practice.

If you've been in Ethereum long enough, you're likely familiar with the concept of bumping a transaction: you send something with a gas price that happens to be too low, your transaction takes too long to be included, and you send another transaction with the same fields but a higher gas price. The latter transaction "replaces" the previous one in the mempool and the new one is included in a block faster.²

Did you know, though, that some nodes will only accept the new transaction if the new gas price is at least 10% higher than the previous one? There is a reason for this³, but the important part for us is that there's nothing in the protocol rules that says things should work that way. To illustrate this idea, imagine that a node has a pending transaction T with gas price X and then it receives a newly built block with a transaction that replaces T and has gas price Y, where Y is only 1% greater than X. The node can't say "that gas bump was under 10%, rejected!" There's nothing invalid in the block.

The same distinction applies to EIP-859 and the gas threshold within which PAYGAS should be used. Each node can decide how to set that threshold, but that doesn't mean they would reject blocks that execute PAYGAS after it; this only matters when deciding which pending transactions are valid.

In summary, we have two kinds of rules: "hard" protocol rules, which all nodes must follow if they want to participate in the network, and "soft" mempool rules where each node can do what they want but where EIPs might suggest useful guidelines.⁴

The multi-invalidation problem

EIP-859 seems like a keeper: it adds support for account abstraction and it doesn't seem to have DoS vectors related to transaction validation. But it has a huge DoS vector related to transaction invalidation, something it took the community a while to realize.

To understand this, imagine an EIP-859 wallet with a function that sends ETH to some address only if the balance of that address is zero:

function transferIfNoBalance(address to, uint value, uint gasPrice, bytes memory sig) public {
  // ...check that signature is valid...
 
  // check that the address's balance is zero
  require(to.balance == 0);

  // pay the block builder
  paygas(gasPrice);

  // make the transfer
  (bool success, ) = to.call{value: value}("");
  require(success);
}

There's nothing inherently wrong with this functionality, and one can even imagine a scenario where this could be useful. The problem is this: what happens if you build 100 transactions that use this functionality targeting the same address? If the balance of the address is 0, then all of those transactions will be valid on their own. But the moment one of them is included in a block, the other 99 become invalid and have to be dropped. The same idea applies to 200 or 1000 transactions. This means we can spam the mempool with as many of those transactions as we want but the cost of doing so (the cost of the only transaction that will be included) is always the same.

This problem, known as "the multi-invalidation problem", is a big headache for any account abstraction proposal, as we'll see many times in the rest of the article.

EIP-2938: PAYGAS revisited

We can think of EIP-859 as essentially being EIP-86 with a new opcode and a basic mempool guideline: don't use too much gas during the validation phase. EIP-2938, the last proposal we'll see in this first part, is in turn essentially the same as EIP-859 but with more mempool guidelines.⁵ The reason for this is the multi-invalidation problem.

To understand why new mempool guidelines are needed, let's look at transaction invalidation from scratch. Suppose a node has a pending transaction from an EOA in its mempool, and a new block arrives. What can happen in this block that invalidates that pending transaction? There are only two possibilities: the nonce of the sender changes, or its balance drops below the upfront cost of the transaction. In both cases, the culprit has to be a transaction from the same sender.

This is a good property to have: when a transaction gets included in a block it can only invalidate up to one pending transaction in the mempool. As we saw with the multi-invalidation problem, EIP-859 doesn't have that property. And at the root of this issue is the fact that the validity of an EIP-859 transaction can depend on anything that is observable from the EVM: the balance or code of any account, storage slots, the block timestamp, etc.

EIP-2938 attempts to fix this by adding more mempool guidelines, specifying what can happen before PAYGAS is executed. Here's the relevant section of the EIP:

As you can see, these guidelines are more arcane than EIP-859's simple "don't use too much gas before calling PAYGAS", because they have to make sure that the validity of a transaction can only be affected by a different transaction from the same wallet. Here I have to stress that these are not protocol rules. A block can have a transaction that uses any of these opcodes before PAYGAS is executed and it will be valid. It's just that most nodes would reject that transaction in the first place.

When EIP-2938 was introduced in 2020, it was considered a solid proposal, but it didn't end up being adopted. The reason was less about technical concerns than about engineering bandwidth: core devs were completely focused on the Merge. In that context, it was hard to prioritize an EIP that added a new transaction type, a new opcode with deep changes to the EVM, and a set of complex mempool rules. And so the goal of native account abstraction was put on hold, leaving the ecosystem to explore its own solutions.

Part 2: Outside the protocol

The greatest victory is that which requires no battle.

— Sun Tzu, as quoted by Yoav Weiss, January 2019

In Part 1 we explored a few proposals aiming for the moon: to get all the benefits of account abstraction from a single EIP. But not every AA-related issue is equally important. As Ethereum gained popularity, a frequent source of friction was the need for ETH to do almost anything. Try some app? You need ETH. Received some tokens and want to swap them? You need ETH.

From the beginning, this problem was recognized and people experimented with workarounds that didn't require waiting for protocol upgrades. The experience from these efforts, combined with the shelving of native AA efforts, eventually converged into ERC-4337, a project with the ambitious goal of getting as close to account abstraction as possible without changing the protocol.

Meta-transactions

To send a transaction in Ethereum you use your private key to sign a transaction object, proving you own the account and want a specific action performed from it. When a block builder receives this object, it validates its signature and executes the corresponding action from the signer's account.

This idea—signing data to prove to someone that you want something done on your behalf—can be used at the contract level too. An ERC20 contract can have a special function that receives signed data to perform a transfer. If that function is called with the proper arguments, the contract can do something analogous to what block builders do: recover the address from the signature, verify it has enough balance, and move the specified amount of tokens to the target address. And crucially, anyone can call that function, even if they weren't the ones who signed the data.

This is in essence the idea of meta-transactions: separating the actor that signs from the one that wraps that signed data in a transaction, the so-called relayer. The question is, why would anyone act as a relayer? Whoever does it has to spend ETH to send the transaction, and therefore must have an incentive to do it. In the token example, the recipient might be relaying the meta-transaction because they benefit from the underlying action (the token transfer). An application might also decide to sponsor the first interactions from verified users, letting them use the app without having to pay gas; in this case, the incentive is user acquisition.

Meta-transactions work and have been used in production to let users interact with apps without needing ETH.⁶ But they have several issues:

• Meta-transactions depend on a relayer wrapping your signed data and sending it in a transaction. But how do you find and use a relayer? Depending on the design, there is a risk of ending up with a centralized system where only a couple of relayers are realistically available.⁷

• A meta-transaction has a considerable gas overhead compared with a normal transaction.

• Meta-transactions are app-centric, meaning that every token or app needs to individually implement support for them.

The last item is the worst one, because it means this approach simply won't scale. While some projects might do it if it makes sense for their goals, it's unreasonable to expect every single application out there to have support for meta-transactions.

ERC-4337

While the attempts to have native support for account abstraction were put on hold, the dream didn't really go away. Instead, most of the energy went to try to accomplish as much as possible without needing any protocol upgrades. These efforts resulted in ERC-4337⁸, perhaps the most well-known of all AA proposals.

ERC-4337 is quite complex, so I won't go into detail on it (check the resources at the end for a great explainer). At the same time, it's impossible to properly understand the rest of the history of AA without at least some idea of how ERC-4337 works and some of the concepts it introduced, so let's do a quick overview.

The way I like to think about ERC-4337 is the following. We saw in the previous section that meta-transactions are cool, but they need every app to implement support for them. But what if smart wallets support meta-transactions? If you can sign data to execute arbitrary actions with your wallet, and if you can find a relayer that will wrap it in a transaction for you, then you get many of the benefits of account abstraction without having to change anything in the protocol.

This is, of course, easier said than done. There are several problems raised by this approach, and most of the complexity around ERC-4337 stems from those issues. For now, let's only mention two.

The first problem is that relayers need to know that the result of relaying an action will benefit them somehow. They can do this by auditing the code of every wallet they support, but this results in an "M x N" problem: each new relayer needs to support multiple wallets, and every new wallet generates work for every existing relayer. For this and other reasons, ERC-4337 uses a well-audited singleton contract called EntryPoint that coordinates relayers with wallets. This turns things into an "M + N" problem, because each new relayer or wallet only needs to implement compatibility with that contract.

The other problem is gas overhead. So far we've talked as if each meta-transaction corresponds to a single contract action, but it's more efficient to gather multiple actions and send them all together in a single transaction. That's what relayers do in ERC-4337, and that's the reason why they are called bundlers, which is the term we'll use from now on.

Alice, Bob, and ERC-4337

What would our Alice and Bob example look like if Bob used ERC-4337?

As with the EIP-86 example, Bob doesn't have a smart wallet or any ETH to deploy one. But just like before, this is not a problem as long as he can predict the address where his wallet will be, and by this point CREATE2 was already part of the protocol. We won't dive into how deployments work in ERC-4337, but the short version is that they can happen "on the fly" and are handled by the EntryPoint contract.

Bob figures out where his wallet will be deployed and shares this address with Alice. Once she transfers the ETH, Bob signs a user operation: a structured piece of data defined by ERC-4337 specifying the action that the wallet should perform. In our case, this user operation will indicate that 0.1 ETH should be transferred to Charlie, plus some fields specifying that the wallet should be deployed. This user operation is received by a bundler who sends it along with other user operations to the EntryPoint contract. When Bob's user operation is executed, the wallet is deployed and called, Charlie receives his 0.1 ETH, and the wallet pays the bundler.

Paymasters

There's one final concept introduced by ERC-4337 which deserves mention. In the previous example, we said that Bob's wallet pays the bundler for including his user operation in a transaction. If things always worked that way, then this aspect wouldn't be fundamentally different from how EOAs work: the entity initiating some action (the wallet in this case) is always the one that pays for its cost. ERC-4337 uncouples these two responsibilities with the concept of paymasters. A paymaster is an optional part of a user operation, and it represents an entity that is willing to pay for it.

To understand how a paymaster could be useful, imagine that Alice sends USDC to Bob instead of ETH. The wallet can't use it to pay the bundler for sending the user operation; only ETH can be used for that. But Bob can modify his user operation to include a paymaster that accepts tokens.

ERC-4337 also defines a "paymaster post op" callback, which is executed at the end to let paymasters perform final checks or do some cleanup work. The details don't matter, but the concept will be important later when we try to generalize the whole mechanism.

ERC-7562: Standardizing mempool rules

Everything we've explained about ERC-4337 shows that you can get many of the benefits of native account abstraction without having to change the protocol. The mechanism is in fact quite similar to the EIPs we explored in the first part. In those proposals, the smart wallet executes some validation logic and then pays the block builder; in ERC-4337, the wallet validates a user operation and pays a bundler. But this is the exact same setup that led to the multi-invalidation problem. Imagine the same example we saw before but in an ERC-4337 context: someone creates hundreds of user operations that transfer ETH to some account but that are only valid if the target's balance is zero. If a bundler includes multiple of those user operations, it will only be paid for the first of them to be executed.

ERC-4337 largely follows EIP-2938's approach here: add guidelines about which opcodes can be used during validation. These guidelines evolved over time, reflecting a more detailed understanding of the multi-invalidation problem and the trade-offs between preventing it and letting wallets do as much as they want during validation. In fact, the rules became so complex that they were moved to a different spec, ERC-7562.

But there is a big difference between mempool guidelines in a native AA proposal like EIP-2938 and an out-of-protocol one like ERC-4337. A node can know in detail what's happening in the EVM during the execution of a transaction, but a bundler is just a regular user for whom the execution is by default a black box. This is not an unsolvable problem: there are alternative JSON-RPC methods that can be used to simulate a transaction and get a detailed trace of its execution, which can then be used to check that guidelines are respected. But this adds to the overall complexity of the proposal.

ERC-4337 in the wild

ERC-4337 was deployed to production in 2023, and it has been maintained and upgraded since then. To be honest, it's unclear to me how much adoption it has had. The BundleBear website has some interesting usage stats, but it's hard to evaluate them because they are in absolute terms instead of, say, showing which percentage of the overall onchain activity goes through bundlers.

Still, what matters is that ERC-4337 worked and contributed to a much deeper understanding of the account abstraction problem. And its technical achievements are impressive: smart wallets that can be used with relative gas efficiency without needing an EOA, that can be deployed on the fly, and whose operations can be funded by third parties; all without needing changes to the protocol.

But ERC-4337 still has downsides:

• Since EOAs are still needed for bundling, it can't be a long-term solution (nor does it claim to be one).

• While bundling helps with gas efficiency, there's some unavoidable overhead that can only be eliminated through a native AA mechanism.

• Because user operations are not first-class citizens like transactions, they won't benefit from future protocol features. For example, inclusion lists wouldn't prevent user operations from being censored.

For all these reasons, there continued to be a need for protocol changes, resulting in a second wave of native account abstraction proposals. We'll discuss them in the fourth and final part, but first we need to rewind once more and talk about a parallel attempt at dealing with the limitations of Ethereum accounts.

Part 3: Empowering EOAs

I am once again asking for your support of EIP-3074.

— lightclient, September 2022

At the beginning of this article, we listed some pain points caused by the lack of account abstraction. And in the previous part, we saw how some of these pain points could be addressed with two out-of-protocol approaches: app-centric support for meta-transactions, or smart wallets that can be used through ERC-4337. In both cases we are avoiding a direct use of EOAs due to their limitations. But what if we tried to fix the worst of those shortcomings instead? Why not empower EOAs to make Ethereum better now, even if they are going to go away in the long term?

There have been many proposals aiming to make EOAs more powerful, but here we'll only focus on two of them: EIP-3074 and its successor, EIP-7702.

EIP-3074: The proposal

By 2020, Ethereum usage had grown significantly. New tokens and protocols were constantly emerging and the legendary DeFi summer was around the corner. This surge in interest only made it more frustrating to need ETH for everything.

At the core of this problem was the fact that one could only initiate an action from an EOA by sending a transaction from it, and this always requires ETH. The proposals we've seen so far tried to circumvent EOAs entirely and rely on smart wallets instead. But an alternative solution is to add some other mechanism to make calls from EOAs.

To understand the mechanism that EIP-3074 proposes, let's recap the relationship between transactions and calls. A transaction is made of at least one top-level call, the one that comes from the EOA sending the transaction (even a plain ETH transfer is considered a call in this context). If the recipient is a contract, then this contract in turn could make multiple calls, which in turn could execute other contracts that make more calls, and so on. But notice that there is one and only one call coming from an EOA: the one at the beginning.

The essence of EIP-3074 is in allowing a contract to "impersonate" an EOA and make a call from it. Of course, the EOA has to authorize this somehow, and the way to do it is not that different from how meta-transactions work: the user signs some structured data with their private key to let some contract make calls from their address.

To be more specific: EIP-3074 adds two new opcodes, AUTH and AUTHCALL. The first one verifies a signature over some data specific to the EIP. If that signature is correct, then for the rest of the execution the contract is allowed to use AUTHCALL, which works pretty much as a normal call but where the sender is the EOA that signed the data.

Alice, Bob, and EIP-3074

EIP-3074 is about making EOAs more powerful, not about smart wallets, so we'll use a different scenario for our Alice and Bob example. Alice sends 100 USDC to an EOA that Bob generated, and he wants to send 10 of those USDC to Charlie. Bob's EOA is fresh and doesn't have any ETH. Normally this would mean that he can't do anything with it, but with EIP-3074 he can sign an authorization for a contract compatible with EIP-3074 (called an invoker in the EIP) that can transfer the tokens on his behalf.

As with meta-transactions, though, Bob still needs to find a relayer⁹ that will call the invoker with the data he signed. And, as always, the relayer needs an incentive to perform this work. In this example, the invoker might be written so that it sends part of the USDC to the relayer in addition to the 10 USDC it sends to Charlie.

EIP-3074 questions

While EIP-3074 is a conceptually simple proposal, there are details that need to be clarified that can have a substantial impact on the end result. For example:

• Can the authorization be used multiple times? One possible answer is to forbid it at the protocol level, for example by adding a nonce mechanism to authorizations. Alternatively, re-use could be allowed for maximal flexibility, in which case it is the invoker's responsibility to implement replay protection at the application layer.

• Can authorizations be revoked? Suppose Bob signs and propagates an authorization but then regrets it. Can he invalidate it? How?

• How can users know what the impact of signing a certain authorization will be? This is a UX problem for every scenario where users sign something, but it's especially important in EIP-3074 because a single bad signature could be used to completely drain an account.

These and many other questions meant that EIP-3074 was proposed and delayed many times. But in 2024, the proposal was finally accepted for inclusion in the Pectra upgrade.

Pushback

Maybe you remember there was some drama around EIP-3074. And as with any controversy, the account of what happened depends on who you ask. I'll briefly explain one version of the story (perhaps the most often repeated one) which I believe is broadly correct. But keep in mind that it might be missing a good deal of nuance.

After EIP-3074 was accepted as part of the Pectra upgrade, it started to receive some serious pushback, especially from the team working on ERC-4337. As we explained in Part 2, ERC-4337 went live in 2023 and there was already some talk of making it more useful by enshrining it into the protocol (of which more in the next part). A major complaint about EIP-3074 was that it wasn't aligned with that roadmap. For example:

• EIP-3074 needs relayers to send authorizations. The work on decentralized bundlers by the ERC-4337 team couldn't be reused for this, so a new relayer system would be needed.

• As in any meta-transaction scheme, relayers need an incentive to do their job: the resulting on-chain action has to benefit them somehow. Here we have the same problem we've seen a couple of times: as a relayer, you can run a simulation to check that you'll be paid, but there's no guarantee that this is what will actually happen when the transaction is finally included in a block. ERC-4337 solved this with the EntryPoint contract but, again, this solution couldn't be leveraged by EIP-3074.

• By making EOAs more powerful, the EIP was going against the long-term goal of users migrating to smart wallets.¹⁰ And by adding opcodes that explicitly relied on ECDSA, the EIP was going against the long-term goal of deprecating non-quantum-resistant cryptography.

But the UX problems EIP-3074 was trying to address were real, and waiting for full AA (migration to smart wallets included) seemed unrealistic to many. The bottom line is that there were two groups of people in the community honestly trying to make the protocol better, but with different philosophies about what the best next move was.

EIP-7702

Things seemed to be at a stalemate, with an EIP that had technically been approved for inclusion receiving pushback that couldn't be ignored. But then, right before a crucial meeting to discuss the topic, Vitalik famously drafted a new, alternative EIP in 22 minutes. This was EIP-7702, and it covered most of the use cases the EIP-3074 authors cared about while being compatible with the long-term vision of the ERC-4337 team.

To understand how EIP-7702 works, remember that EOAs can be the targets of calls from other EOAs or contracts, but the only thing these calls can do is transfer ETH. If they have some data, it is ignored.

EIP-7702 lets EOAs optionally change that behavior by delegating to a contract the handling of incoming calls. To do that, they have to sign an authorization specifying the address to which they want to delegate. These authorizations can be enabled on-chain by including them as a field of a new type of transaction.

Alice, Bob, and EIP-7702

In the USDC version of our Alice and Bob example, Bob has received 100 USDC in his EOA but he can't do anything with them because he has no ETH. With EIP-7702 he has a way out: he can sign an authorization to delegate how the EOA handles incoming calls. The target of the delegation can be any contract, but the most logical choice is a smart wallet implementation.

Once this happens, Bob's EOA is practically indistinguishable from a smart wallet. He still needs someone to call it on his behalf, but that's exactly the kind of problem that ERC-4337 is meant to help with, and what any native AA scheme will try to solve. This is one of the main reasons why EIP-7702 is considered more aligned with the AA roadmap than EIP-3074 was.

EIP-7702 was good enough to satisfy both sides of the debate. It was included in the Pectra upgrade as a replacement for EIP-3074 and is now live on mainnet and several L2 chains.

Part 4: The dream of native account abstraction

Even enshrined in-protocol account abstraction is still a massive "de-enshrinement" compared to the status quo.

— Vitalik Buterin, September 2023

As we discussed in Part 2, ERC-4337 has limitations that can only be solved by enshrining some of its features at the protocol level. In fact, in 2023, the very same year that ERC-4337 went live, a proposal was drafted with this goal. Since then, the conversation has evolved and culminated in EIP-8141 (Frame Transactions), a proposal that attempts to take all the lessons from this story and wrap them into a single AA proposal.

Enshrining ERC-4337

Remember how ERC-4337 works: a user signs a "user operation" which is later included in a transaction by a bundler and processed by the EntryPoint. This contract handles the logic related to checking that the operation is correct, executing the call, paying the bundler, etc. What we would like is a similar mechanism that's handled directly by the protocol. That is: user operations become transactions, the work of bundlers is done by block builders, and the logic coded in the EntryPoint contract becomes part of the rules of the chain.

The first two attempts at this were RIP-7560¹¹ (proposed in 2023) and EIP-7701 (proposed a year later and, yes, the EIP immediately before EIP-7702). There are many cosmetic differences between these two proposals, but they boil down to the same idea, so I'll just focus on EIP-7701 here.

EIP-7701 proposes adding a new transaction type with these fields:

[
  chain_id,
  nonce,
  sender, sender_validation_data,
  deployer, deployer_data,
  paymaster, paymaster_data,
  sender_execution_data,
  max_priority_fee_per_gas, max_fee_per_gas,
  sender_validation_gas, paymaster_validation_gas,
  sender_execution_gas, paymaster_post_op_gas,
  access_list,
  authorization_list
]

As you can see, most of these concepts come directly from ERC-4337. The idea is that the protocol itself does the work of the EntryPoint: it calls sender (presumably a smart wallet) with sender_validation_data to check if they indeed want to make that call, it validates the paymaster if present using paymaster_data, and so on.

How does a wallet or paymaster communicate whether they accept the transaction? In ERC-4337, this is done by implementing a certain interface that is called by the EntryPoint contract, but in EIP-7701 they have to communicate with the protocol itself. For this reason, the EIP adds two new opcodes, CURRENT_ROLE and ACCEPT_ROLE, which let contracts say "yes, I want to send this call" or "no, I don't want to pay for this transaction."

To be able to decide how to respond, wallets and paymasters need visibility into the whole transaction. In ERC-4337 the whole user operation object is always passed around, but in EIP-7701 the data in each call is only what is relevant to that phase of execution. To make up for this, the proposal also adds a new group of TXPARAM* opcodes that let a contract inspect other fields of the transaction. For example, a paymaster can use these opcodes to check who the sender is and the data with which it's called.

EIP-7701 fixes the main issues with ERC-4337: it doesn't need EOAs to work, it's more gas-efficient, and it benefits from any improvements to transactions. What it doesn't do, nor does it try to, is to fix the problems inherent to account abstraction, like the multi-invalidation problem. Mempool guidelines are still needed and, while the draft doesn't really mention them (perhaps because the EIP didn't make that much progress), they are clearly necessary.

In summary, EIP-7701 takes ERC-4337 and transforms each of its parts into a native equivalent. I don't know about you, but this feels wrong to me. ERC-4337 had to deal with the constraint of not being able to modify the protocol, and this limitation certainly influenced its design. Using its ideas verbatim seems like taking the shortest path to enshrinement. A better way to approach the problem is to ask: what is the minimal set of native features that enable the capabilities we want?

EIP-8141: Frame Transactions

The core problem of account abstraction is how to allow users to interact with smart wallets without needing an EOA. What's involved in those interactions? Here are the key steps, according to what we've learned so far:

1. A smart wallet is created on the fly if needed.

2. A smart wallet is asked if it wants to perform a certain action.

3. A paymaster is asked if it wants to pay for the interaction.

4. The action from the smart wallet is performed.

5. The paymaster is allowed to do some work at the end.

These steps can be grouped into two categories. Items 2 and 3 are about querying a contract to check if it wants to play a certain role in the interaction (making a call in the case of the wallet, paying for it in the case of the paymaster). The rest of the items are about making a call: to a factory to deploy the wallet, to a paymaster for its post-op, and of course to the wallet itself to perform the main action.

But notice that this second category (making calls) can in turn be divided: when we perform the main action, we are interested in the wallet being the sender; when we deploy the contract or execute the paymaster post-op, on the other hand, we don't care who makes the call. Putting it all together, we can define three categories of steps in an AA interaction:

• Asking a contract if it's willing to play a certain role

• Making a call from a specific address

• Making a call without caring about the sender

EIP-8141 proposes a new transaction type composed of frames, each belonging to one of those three categories. The EIP calls these categories "modes" and gives them the names VERIFY, SENDER, and DEFAULT.

And that's it, that's the core idea of frame transactions. There's a fair amount of extra detail, like new opcodes similar to the ones we saw for EIP-7701, but all that complexity is just a means to an end. And, of course, our old friend, the multi-invalidation problem, is alive and well. The answer here hasn't changed much: you need mempool guidelines, and EIP-8141 simply defers to the ERC-7562 rules originally defined by ERC-4337.

Alice, Bob, and EIP-8141

Let's revisit our Alice and Bob example one final time. As always, Bob hasn't interacted with Ethereum before, so the first thing he'll do is predict where his smart wallet will be deployed. Alice transfers ETH to that address and then Bob builds an EIP-8141 transaction with three frames:

• One DEFAULT frame to deploy the wallet.

• One VERIFY frame asking the newly created wallet to confirm whether it wants to perform the desired action (send ETH to Charlie) and pay for the whole transaction.

• One SENDER frame corresponding to the actual call.

The relationship between the VERIFY and SENDER frames might need some clarification. The VERIFY frame receives some data, and it can also use the new opcodes to inspect the rest of the transaction. A simple wallet that just checks a signature could get it from the VERIFY data and assert that it indeed corresponds to the SENDER data, but more complex schemes are of course possible.

When a node receives this transaction, it will check that it's valid. In the context of EIP-8141, that means executing the VERIFY frames and checking both that they succeed and that they don't use any opcodes forbidden by ERC-7562.

I'm glossing over many details here; check the EIP for the full picture. Hopefully knowing why the proposal looks the way it does will help you navigate the spec.

Issues with frame transactions

If you've read this far and I've done a good enough job, then it should be easy to sympathize with the idea that frame transactions are the "endgame" for AA, given how simple the core concepts are. And yet, EIP-8141 was rejected as the headliner for the Hegota upgrade. It now lives in a weird limbo: it's a headliner-sized EIP that is "considered for inclusion" as a non-headliner. Whatever that means.

There are many reasons for this rejection. Here are some:

• "It adds a lot of complexity to the mempool." People against frame transactions would prefer something less abstract but more mempool-friendly, like a hardcoded set of transaction sub-types. EIP-8141 proponents favor maximum power combined with "soft" mempool guidelines that can evolve over time.

• "There's no need for so much generalization." Opponents say that there are 80/20 solutions that cover the most important use cases related to AA. Proponents argue that the protocol shouldn't be in charge of making these decisions and should let higher-level layers figure it out.

• "It's not really quantum safe." Opponents say that frame transactions don't really solve the quantum issue because more things are needed, like new precompiles. EIP-8141 proponents agree but argue it's a necessary first step in the right direction.

In my opinion, some of these criticisms are more valid than others. The mempool complexity is real but, as we've seen time and again in this article, this problem seems inherent to having full account abstraction. Dealing with it by using hand-picked 80/20 solutions seems short-sighted to me and completely against Ethereum's philosophy. On the other hand, the fact that this is not a complete solution to the quantum threat is absolutely true. The problem here is that the EIP-8141 authors shot themselves in the foot by originally putting the post-quantum (PQ) motivation up front in the spec without any nuance (though this has been fixed since then).

That last point illustrates something I believe is not taken into account often enough. The AA or PQ problems don't need to be solved with the stroke of a single EIP, as much as that would help with the walkaway test. But, someone asks, what if Ethereum suddenly stops having upgrades after Hegota? Well... if that happens it's because we have much bigger issues than the lack of full account abstraction or quantum resistance. In this sense, I agree with the 80/20 proponents but from a different angle: we should add enough basic, neutral functionality (plus mempool guidelines) to help with the biggest current UX issues and pave the way for PQ, but nothing much beyond that. At the time of writing, though, the EIP is only growing bigger, adding new capabilities that feel like feature creep to me.

Still, at the end of the day these are details that can be worked out. There's no target date for the Hegota upgrade, but it will probably happen in early 2027, giving us plenty of time to iron out the spec. The debate today shouldn't be about those details; the question is whether the core of EIP-8141 is the right path to AA and whether it's urgent enough to be included as soon as possible. I think the answer to both questions is yes.

Epilogue: What's next?

At the time of writing, EIP-8141 is "considered for inclusion" for Hegota, meaning that it might be part of the upgrade but it's not guaranteed. So what's in store for account abstraction? Short term, I think there are three possible scenarios:

• Frame transactions are included in Hegota in some form.

• Frame transactions are not included, but some alternative AA mechanism is.

• No AA features are added to Hegota.

I'm fairly sure the second option won't happen. While EIP-8141 didn't have the consensus needed to become a headliner, it has more than enough support to block any alternative. Unless, that is, someone pulls an EIP-7702 at the last minute. But I think this is unlikely: the underlying problem here is way more complex than the one EIP-3074 was trying to solve.

This leaves us with two possibilities: frame transactions are scheduled for Hegota, or account abstraction is postponed to the next upgrade. Personally, I don't think that postponing AA six months would be catastrophic; after all, it has been postponed for ten years. The problem is less about the delay than about what it signals: if EIP-8141 can't get consensus due to core philosophical issues rather than workable details, will six months change anything? Does the problem's wickedness, combined with the different priorities and philosophies of the community, mean that the dream of native account abstraction cannot be realized? Let's hope that's not the case.

Resources

• General

  • A history of account abstraction. A talk by Vitalik, from the beginning up until ERC-4337.

  • Account Abstraction Link Tree. A “rough outline of the major contributions to the topic of Account Abstraction over the years”, maintained by lightclient. The best meta-resource if you want to go much deeper into the topic.

• Part 1: Early attempts

  • EIP-86: Abstraction of transaction origin and signature

  • EIP-859: Account abstraction for main chain

  • EIP-2938: Account Abstraction

  • Tradeoffs in Account Abstraction Proposals. 2017 Vitalik post in Ethereum Magicians analyzing approaches with different trade-offs between complexity and capabilities.

  • A recap of where we are at on account abstraction. 2018 Vitalik post in Ethereum Magicians, focused mostly on how to deal with invalidation issues.

• Part 2: Outside the protocol

  • ERC-4337: Account Abstraction Using Alt Mempool

  • ERC-4337 website

  • You Could Have Invented Account Abstraction. 4-part series on ERC-4337. If you are going to read only one thing from this list, choose this one. I’m linking a Wayback Machine version because the code snippets don’t show up in the original blog.

• Part 3: Empowering EOAs

  • EIP-3074: AUTH and AUTHCALL opcodes

  • EIP-7702: Set Code for EOAs

  • EIP-3074 proposals history

    • London proposal (Mar 2021)

    • Shanghai proposal (Sep 2022)

    • Pectra proposal (Dec 2023)

    • EIP-3074 included in Pectra (Apr 2024)

    • EIP-3074 replaced by EIP-7702 in Pectra (May 2024)

  • ERC-4337 vs EIP-3074: False dichotomy. There are dozens of texts arguing in favor or against EIP-3074. I'm only linking this one because it gives some good insights into the problem of AA

  • Why 4337 and 3074 authors are disagreeing, and who got it right. Great summary by Derek Chiang about the 3074/4337 debates. Derek also wrote a follow-up, Reflections on Ethereum Governance Following the 3074 Saga, which is not exactly about account abstraction but it’s worth reading anyway.

• Part 4: The dream of native account abstraction

  • RIP-7560: Native Account Abstraction

  • EIP-7701: Native Account Abstraction

  • EIP-8141: Frame Transactions

  • Full account abstraction. An article by Vitalik analyzing the problem from first principles, written when EIP-7701 was the latest proposal.

  • The case for Frame Transactions. An article in defense of EIP-8141 by Derek Chiang.

1. The mempool of a node is the set of transactions that could be mined at some point in the future. While each node technically has its own mempool, people often use “the mempool” to refer to the group of pending transactions in the network irrespective of a particular node.

2. This is almost never necessary nowadays, thanks to EIP-1559.

3. Suppose a node accepts replacement transactions without a minimum gas price difference. An attacker can send a transaction with gas price X, then a bumped one with gas price 1.001*X, then another one with 1.002*X, and so on. This makes the node validate thousands of transactions when only one of them is finally mined. Enforcing a minimum bump of 10% means that the gas price grows exponentially, making this kind of denial of service extremely expensive. For example, if an attacker sent 100 bumped transactions, the last of those would have to use a gas price 13,780 times higher than the first one.

   
   

4. There is even more nuance about mempool guidelines. There are some rules at the network-level (not protocol-level) that are necessary to let nodes know which transactions they can propagate without being penalized in the p2p network. But explaining that in more detail would make this article even longer than it already is, so we’ll simplify and think about mempool rules as being up to each node.

5. There are several other differences between EIP-859 and EIP-2938, but they aren’t very relevant. For example, EIP-2938 uses a new EIP-2718 transaction type, while EIP-859 and EIP-86, as you can guess by their numbers, don’t.

6. A good example of how meta-transactions have been used is ERC-2612, an extension to the ERC20 spec. It adds a permit function that receives some signed data and sets an allowance from the signing account to some address. This is different from my simplified example, which transferred tokens directly, but the core idea is the same.

7. For a noble but ultimately abandoned effort to solve the problem of centralization in the context of meta-transactions, you can read about Gas Stations Network. This article has a good explanation of how it worked.

8. EIP means Ethereum Improvement Proposal. EIPs usually involve changes to the protocol itself. ERC means Ethereum Request for Comments and it's used for standards at the application layer, like the ERC20 token standard. Technically ERCs are a subset of EIPs, but I’m not sure anyone cares.

9. EIP-3074 uses the word “sponsor” instead of relayer. We’ll keep calling them relayers anyway, to avoid introducing even more terminology.

10. I strongly dislike the idea that EOAs shouldn't be improved just to protect the AA roadmap. Ethereum too often falls into the trap of only thinking long-term. As laudable as that might be, sometimes you need to balance it with short/medium term improvements.

    
    

11. RIP means Rollup Improvement Proposal. RIPs are like EIPs, but aimed at L2s instead of the main chain.

In this article we'll go in depth (no pun intended) into the "stack too deep" problem, how EIP-8024 addresses the underlying issue, and why the solution is not as simple as it appears at first. Along the way, we'll explore some interesting and lesser-known aspects of the EVM.

Stack too deep

The “stack too deep” error shows up in many scenarios, but they mostly boil down to using too many local variables at the same time. To illustrate this, take the following code:

contract Example {
    uint public x;

    function myFunction() public {
        uint x1 = 1;
        uint x2 = 2;
        uint x3 = 3;
        uint x4 = 4;
        uint x5 = 5;
        uint x6 = 6;
        uint x7 = 7;
        uint x8 = 8;

        x += x1 + x2 + x3 + x4 + x5 + x6 + x7 + x8;
    }
}

This compiles fine, but if we add one variable more…

contract Example {
    uint public x;

    function myFunction() public {
        uint x1 = 1;
        uint x2 = 2;
        uint x3 = 3;
        uint x4 = 4;
        uint x5 = 5;
        uint x6 = 6;
        uint x7 = 7;
        uint x8 = 8;
        uint x9 = 9;

        x += x1 + x2 + x3 + x4 + x5 + x6 + x7 + x8 + x9;
    }
}

Then solc (the official Solidity compiler) gives us an error:

There are many workarounds for this problem. Perhaps the most popular today, and the one the error message itself suggests, is to use the IR pipeline. This is an alternative compilation mode in solc which does fix the problem, but which has its own issues:

• It's slow (although getting better over time)

• It can result in a worse debugging experience

• It still has some expressiveness limitations¹

At this point, it’s likely a Vyper guy will jump out from behind you and, before you have time to ask him how he got into your house, yell “Vyper doesn’t have stack too deep errors!”. Which is true. But this comes at the cost of not being able to do cyclic calls (including recursive functions) and, in any case, rewriting your contract in another language is hardly a practical solution.

From Solidity to EVM bytecode

To understand why the "stack too deep" error happens, we need to look at how Solidity handles variables. The EVM has three main areas² where values can be stored: stack, memory and storage. The stack and memory start empty in each execution. The storage, on the other hand, persists between calls.

Solidity uses these three areas differently depending on the language feature. Storage variables use the permanent storage area. Local variables, on the other hand, are ephemeral, and so they have to use either the stack or memory areas.

Using the stack

In the previous section, we saw how a contract with eight local variables worked fine with solc's default compilation mode (normally called the "legacy pipeline"), but adding one extra variable results in a "stack too deep" error. To better understand why this happens, let's look at what goes on at the EVM level when we have seven variables. Executing that bytecode will eventually result in the stack looking like this:

And if we have eight variables (the limit before getting the error), the contents of the stack will be:

In both examples we can see all our variables at the top of the stack, ready to be used. But if we add one variable more, the code won't compile. Why? The stack can have up to 1024 elements, surely we can keep adding values there?

Take a look at the previous images again, but this time pay attention to the instructions that were executed immediately before. With seven variables, we have a sequence of instructions that looks like DUP1 | DUP3 | ... | DUP13. With eight variables, we have a slightly longer sequence with a DUP15 at the end. You don't have to be a math genius to guess that a ninth variable would then add a DUP17 instruction. But if you check the list of EVM instructions, you’ll see that there are only 16 DUP* instructions, from DUP1 to DUP16. The same happens with SWAP* instructions. In other words, we can only access the top 16 elements³ of the stack. Anything beyond that is "too deep".

Why this particular code was generated doesn't really matter. This is a contrived example, and in a more realistic scenario the stack might be used more efficiently. But there will always be a limit to the number of elements from the stack that you can use together at a given time.

Using memory

Given this limitation of the EVM stack, why not use the memory area instead? This is actually what the IR pipeline and Vyper do, but the EVM memory has a couple of peculiarities of its own that make it less than ideal for storing local variables. The details are complex (check the aside below if you want to learn more), but the bottom line is that putting variables in memory comes with a significant cost in complexity and gas usage.

Fixing the EVM

In summary, the compiler has to put local variables somewhere, and the two areas where it can do it are the stack and memory. Both have limitations: memory comes with its own trade-offs, and the stack only lets you access its top 16 elements. If we want to fix this at the EVM level, we have two possibilities:

• Make memory less weird, as in EIP-7923.

• Make more items in the stack accessible, as in EIP-8024, the subject of this article.

New instructions

As we saw, the fact that only the top 16 items of the stack can be accessed is the underlying issue that causes "stack too deep" errors. If we raised that limit high enough, the error would go away. The most straightforward way to make that happen is by adding new instructions.

One possibility is to add new variants of the existing instructions. That is, to add new instructions like DUP17, SWAP17, DUP18, etc. This doesn't seem like a great idea. If we wanted to allow access to the top 100 elements of the stack, we would have to add 168 new instructions. Leaving aside the fact that there aren't that many available opcodes, this would be ugly and wasteful.

A better idea is to add only two new instructions, DUPN and SWAPN, that take an arbitrary N as input. Where does that input come from? There are many options, but the two most obvious are:

• Take N from the stack. To duplicate the 20th element, you'd execute a PUSH1 20 instruction followed by DUPN.

• Use the next byte after the instruction, like PUSH1 does. With this option, a single DUPN 20 instruction would duplicate the 20th element.

It's easy to argue that the second approach is much better: the resulting bytecode is smaller (two bytes vs three), it consumes less gas (one instruction vs two), and it's more friendly to static analysis.

Arguments encoded directly in the bytecode like that are called immediates. Right now, only the PUSH* instructions use them; every other instruction that has an input takes it from the stack. These PUSH* immediates have different lengths depending on the instruction: one byte for PUSH1 (e.g., PUSH1 0x14), two bytes for PUSH2 (e.g., PUSH2 0x1234), etc. For our two new instructions, a one-byte immediate would be enough to let us access the top 256 elements of the stack, a significant improvement over the current 16 limit.

In fact, we could even do a little better. Using DUPN with a value like 5 wouldn't make sense given that DUP5 already exists (DUPN 5 would have the same behavior). But we could define our new instructions so that the value of the immediate is not interpreted verbatim. Instead of saying that DUPN X duplicates the Xth element of the stack, we could say that it refers to the item at position X + 17: DUPN 0 would duplicate the 17th element, DUPN 1 the 18th, and so on. This way, the combination of existing DUP* instructions plus the new DUPN would let us access the top 272 elements.

This all sounds great. Sadly, things aren't that simple. To explain why, we need to take a detour and talk about jumps.

JUMPDEST analysis

The EVM works in a simple, sequential way: it executes an instruction, moves to the next one, executes it, advances again. The only exception to this behavior is the JUMP instruction⁴, which takes an item from the stack and continues the execution at that position. But it can't just jump anywhere in the bytecode: the destination has to be JUMPDEST (0x5b), a special instruction that serves only as a marker for valid jump destinations.

You'd be excused for thinking that this is a simple check: read the byte at the jump position and verify that its value is 0x5b, the JUMPDEST opcode. But that doesn't work. Imagine there's a PUSH1 0x5b instruction in the code. Is its second byte a valid jump destination?

For the EVM, it's not: you get an exceptional halt and the transaction reverts.

This is where JUMPDEST analysis comes in. Before executing any code, you need to process the whole bytecode to find out which positions are valid jump destinations. This, incidentally, has to start from the beginning; you can't just look at the bytes before a 0x5b and figure out if it's a valid JUMPDEST or not.

▼Why not?

Why can’t you figure out locally if a 0x5b byte is a JUMPDEST instruction?

You could make the following argument: since the “biggest” push instruction is PUSH32, it’s possible to determine whether some 0x5b is a valid jump destination by looking at the previous 32 bytes: check if the one immediately before is a PUSH1, or if the one before that is a PUSH2, or if the one 32 positions away is a PUSH32. If none of those is true, then it’s a valid JUMPDEST.

It’s easy to prove that this approach doesn’t work. Imagine that the last byte you check is 0x7f, which corresponds to the PUSH32 opcode.

Does that tell you that the 0x5b at i is part of a PUSH32 immediate, and therefore an invalid jump destination? Well, no! That 0x7f byte could in turn be the immediate argument of a PUSH1 just beyond the range you checked:

And, of course, you can't even be sure whether that's actually a PUSH1 or if it's part of the immediate of an instruction before it. There’s no way around it: you have to start from the beginning.

The reason JUMPDEST analysis is relevant to this discussion is that our new instructions take immediates. Why is that a big deal? We could just include them as part of the analysis and forbid a jump to the second byte of SWAPN 0x5b. Except we can't. To understand this, let's assume that the opcode of SWAPN is going to be 0xaa and that the following bytecode is already deployed onchain:

This is a perfectly valid bytecode. There is no instruction for opcode 0xaa yet, but that doesn’t matter because we are jumping over it to a valid destination.⁵ But what happens if we upgrade the EVM and 0xaa becomes the opcode for SWAPN? The disassembled code now looks like this:

Oops, now we are jumping to an invalid destination, even when the underlying bytecode is the same! This is a breaking change.

Conversely, an invalid destination can become valid. In the following example, we are trying to jump to a 0x5b which is the immediate of a PUSH1 instruction:

This will result in an "invalid jump" exception today. But if we upgrade the EVM with our new instruction...

The opcode of PUSH1 becomes the immediate of SWAPN and the 0x5b becomes a valid destination.

At this point you might be wondering why there would be an invalid instruction in the middle of some code. One reason is that the EVM doesn't have separate sections of a "program" for code and data. Any arbitrary data included in the contract to be used in runtime (through an instruction like CODECOPY) has to be part of the bytecode. Since this is just data, it can easily have bytes that correspond to nonexistent instructions.

In practice, this kind of data is always placed at the end of the bytecode, not in the middle of it. But that doesn't matter. A breaking change in something like the EVM is serious, even if we speculate that the impact will be low.

EIP-8024

And now, at last, we have all the context we need to talk about the EIP-8024 proposal.

To recap: we'd like to be able to access deeper parts of the stack to allow high-level languages like Solidity to use it more freely for local variables. To do that, we want to add two new instructions, DUPN and SWAPN, that take as their input a one-byte immediate, letting us access way more than 16 stack elements. But we need to avoid introducing breaking changes related to JUMPDEST analysis.

One possible solution is to forbid the problematic bytes: 0x5b (JUMPDEST) and the 0x60–0x7f range (PUSH1–PUSH32). We can also simplify and disallow the complete 0x5b–0x7f range, even if that includes four instructions that aren't problematic. Restricting the input range like this doesn't feel right though. A compiler would have access to more parts of the stack, but it won't be able to emit instructions like DUPN 91 and it will have to work its way around it.

This is far from ideal. We can do better. And, in fact, we've already hinted at a solution when we suggested interpreting a 0 value as 17.

Let's reframe the problem. We have a restricted range we can use for the immediate values: from 0x0 to 0x5a (0 to 90) and from 0x80 to 0xff (128 to 255). We want to map that range to a continuous range starting from 17.

One option is to define our decode function like this:

def decode(n):
    assert 0 <= n <= 90 or 128 <= n <= 255
  
    if n <= 90:
        return n + 17

    return n - 20

Which maps our ranges this way:

But we can use an even tighter definition through modular arithmetic:

def decode(n):
    assert 0 <= n <= 90 or 128 <= n <= 255
    
    return (n + 145) % 256

Which results in the following mapping:

In other words, a bytecode that includes the DUPN 128 instruction will duplicate the 17th element, and DUPN 0 will duplicate the 145th one. This second approach is the one that the EIP proposes.

The EIP also adds a new EXCHANGE instruction that lets you swap two elements deeper in the stack, instead of always involving the top element like SWAPN does.⁶ Similar to the other two new instructions, EXCHANGE takes as input a one-byte immediate which is only allowed to have values that don’t break JUMPDEST analysis. This single byte is used to encode two operands, M and N. The instruction then swaps the M+1 and N+1 stack items. The exact details are interesting, but this article is long enough as it is; check the resources at the end if you want to learn more.

Closing words

While EIP-8024 hasn’t been officially confirmed as part of Glamsterdam, it has already been implemented by clients and tested in devnets⁷, meaning it has a very high chance of being included in the upgrade. If that happens, solc’s legacy pipeline will finally be able to get rid of the “stack too deep” error for good without incurring any loss of expressiveness in the language. And that’s not all: the alternative IR-pipeline, vyper, and any other compilers will also benefit from these new capabilities.

Resources

Check the EIP and the Ethereum Magicians discussion for more details about the EXCHANGE instruction and how it encodes the input in a single byte.

The EIP author has written some great explainers about adjacent topics that are completely worth reading:

• Compiling for the EVM: Codegen for Stack Machines, about why other stack-based virtual machines (JVM, Wasm, CLR) don’t have the “stack too deep” error.

• Spilling in the EVM, which continues the previous post, discussing the technique of moving values from stack to memory.

• EVM Immediates, an Ethereum magicians post that explores the solution space for the problem of adding new instructions with immediates.

1. To elaborate: you can still have code that won't compile if, for example, you have a lot of local variables and they are used in a recursive function. Admittedly this is not an everyday scenario, but it shows that the solution is not perfect.

2. There are other areas, like transient storage or the return data region, but those don't really matter for this discussion.

3. Technically, the DUP* instructions access the top 16 elements while the SWAP* instructions use the top 17 items, because SWAPX swaps the 1st and X+1th elements (otherwise SWAP1 would be a no-op).

4. There's also JUMPI, which also jumps to some destination but only if some condition is true.

5. Bytes that don't correspond to opcodes of existing instructions can show up in the code, but executing them results in an exceptional halt and the transaction reverts consuming all remaining gas.

6. This is useful for compilers for reasons that go over my head.

7. Devnets are temporary, development-only testnets used by Ethereum core developers to test EIPs before they reach public testnets.

This will be a roundabout explanation: we’ll intentionally go through a false start to better understand the actual solution. If you only want a quick overview, I recommend watching this short video instead.

Block proposal and validation

In Ethereum, each new block is proposed by a randomly chosen validator and propagated to the rest of the network, where other nodes receive it and check that it’s valid. The most time-consuming part of this validation is re-executing all the transactions in the block to verify that the resulting state matches the expected one.

Transactions within a block have an order determined by the block builder. This order has to be respected when a block is verified; if it’s not, the resulting state could be different. For example, imagine a block with only two transactions, both calling the same contract:

Here we need to execute transactions in order to get the expected state. But this is not always the case. Take this other example:

In this case, the order in which we execute the transactions doesn’t matter because the resulting state is the same. Re-executing these transactions sequentially would be wasteful: we could run both of them at the same time without affecting the result.

These examples illustrate that sometimes transactions can be parallelized and sometimes not. Can we use this somehow to have a faster re-execution?

Dependency graphs

We can describe Example 1 in the previous section by saying that tx 2 depends on tx 1. But what do we mean exactly by “depends”? For now let’s use this definition:

Given two transactions A and B, we say that B depends on A if:

• A precedes B in the block.

• A writes some state that B reads.

In Example 1, tx 2 reads a storage slot (x) that was previously written by tx 1, causing a dependency. Keep in mind that "state" can mean a contract's storage, as in that example, but it can also mean other parts of the world state, like the balance of an account or the code at some address.

Now let’s ask, what would happen if we could know in advance all the dependencies in a block? Ignore for now how we would figure that out; just assume we do. If we had that information, we could use it to have some degree of parallelization during execution. For example, given a block with these transactions:

Then we could execute the first three transactions in parallel, and then² execute the last transaction:

At this point you might be wondering how realistic this is for real blocks. Here's an actual dependency graph, taken from dependency.pics:

In this case, the whole block could be re-executed in just four batches, which seems pretty good for a block with 161 transactions. But we might not always be that lucky:

Here we have a long dependency chain, significantly reducing the speedup we could get from parallelization.

In summary, if we (somehow) had the dependency graph of a set of transactions, we could re-execute them with some degree of parallelization, but how much benefit we'd obtain from that would depend on the structure of the graph. It's easy to imagine a pathological case where each transaction depends on the previous one, making sequential re-execution inevitable.

Building dependency graphs

So far we’ve assumed that we have a dependency graph we can work with, but where does that dependency graph come from? How can we know which transactions depend on which?

We said that there is a dependency between two transactions if one of them writes some state that the other one has to read later. But since the EVM is Turing complete, there’s no way to know this in advance without actually executing them. Maybe we could take a conservative approach and say something like “if two transactions call the same contract, they have a dependency”, but it’s easy to show that this doesn’t work. In Example 2 we saw two transactions that call the same contract but can be executed independently:

Worse still, we could have two transactions that call different contracts but still have a dependency between them:

We can’t escape the fact that we need to execute the transactions to build the dependency graph. But we want the dependency graph to speed up the execution of a block’s transactions…

This seems like an unsolvable problem, but let’s remember how block production works: a single validator proposes a block and the rest of the nodes in the network verify it. This means that the block proposer³ could execute the transactions sequentially, build the dependency graph in the process, and propagate the graph along with the block. The other validators then can use this data to parallelize re-execution.

To build the dependency graph, we just need to run the transactions sequentially and keep track of which state is read or written by which transactions.

In this example, tx i writes to state[x], which is later read by tx j, so we would add a dependency from j to i. If we did this for all transactions we'd get a list of dependencies for each one, representing the dependency graph of the block.

This approach seems to work. But we don't get full parallelization and the worst cases are still sequential. Can we do better?

Block-Level Access Lists

Let's change our strategy and ask instead: what would we need to be able to run all transactions in parallel, no matter what?

Let's look at the previous example again. Transaction j has a dependency because it reads state[x], which was modified by transaction i. But if j knew in advance what the value of state[x] would be when it needs it, then there's no reason why it couldn't be executed independently. And we are already keeping track of state changes to build the dependency graph. Why not propagate those instead?

In other words, for each transaction we can keep track of the state they write, and the final value of that state. For the example above, the resulting state diff would be:

{
  [i]: {
    [x]: 200
  }
}

With this information, we can execute all transactions in parallel using a simple algorithm for reading from the state:

def read(j, x):
    last = find_last_writer(j, x)  # last transaction before j that modified x
    if last:
        return state_diff[last][x]
    else:
        return state[x]

And that's it. That's what Block-Level Access Lists (BALs) do. Almost.

In reality, BALs include both the state changes and the list of reads. The previous example would be something like:

{
    [i]: {
        writes: {
            [x]: 200
        },
        reads: []
    },
    [j]: {
        writes: {},
        reads: [x]
    }
}

The reason for this is I/O. When we say "read state" we are talking about disk access, a relatively slow operation. If we know all the writes and reads in advance, then we know all the state that will be needed by all transactions, allowing us to prefetch the necessary data in one go before the start of the execution. This means we can execute all transactions in parallel and we don't need to perform any disk I/O while we do it.⁴

The actual BAL format is way more complex than what I shared. It looks more like this:

BlockAccessList = List[AccountChanges]

AccountChanges = [    Address,    List[SlotChanges],
    List[StorageKey],
    List[BalanceChange],
    List[NonceChange],
    List[CodeChange] 
]

SlotChanges = [StorageKey, List[StorageChange]]

# etc

This is because, as we mentioned before, "state" can mean several things: storage slots, balances, nonces, code, etc. You can see the full definition of a BAL in the EIP.

While the speedup we get from parallel execution + I/O prefetch seems great, there are downsides. We now have to share both the block and its BAL. This increases propagation times, which could, in principle, have a negative effect that is more significant than the performance wins we get from the BAL. The argument is that this trade-off is worth it. See for example Worse-case analysis for BALs.⁵

Loose ends

There are several other aspects of Block-Level Access Lists that are important (or at least interesting) but that weren’t essential to the explanation above.

User-facing changes

Outside the inner workings of the protocol, BALs don’t change things too much. As far as I know, the two main changes are in the block header and in the JSON-RPC layer.

• The block header gets a new field, blockAccessListHash, with the hash of the BAL. This lets you check that the BAL of a given block is correct without having to re-execute the block, which can be useful in contexts like execution-less validation.

• There is a new eth_getBlockAccessList method that can be used to get the BAL of a given block. BALs are not available forever though: clients are only required to keep them around for 3553 epochs (~2 weeks), after which they can be pruned. BAL hashes, being part of the block header, are of course kept forever.

Why faster re-execution?

During our discussion we have taken for granted that faster re-execution is good, so good that it's even worth using a headliner for it. But why is that the case? To be honest, this isn’t mentioned in the EIP. The only explanation I’ve seen is in the headliner proposal:

The community has expressed a clear desire: Ethereum L1 must scale to meet the needs of users and developers. BALs unlock performance gains critical for higher throughput and/or shorter slot times. They also pave the way for zkEVM-based light nodes (executionless + stateless), full nodes (executionless + stateful) and partially stateless execution.

Which seems fair enough.

BALs vs Optional Access Lists

The term “access list” already exists in Ethereum: transactions can include an optional access list⁶, which is a very different concept:

• They work at the transaction level, not at the whole block level.

• They are only about accesses and don’t include state diffs.

• They don’t have to be complete. A transaction could read some state and not include it in its access list.

• They don’t even have to be correct. A block is rejected if its BAL is not exactly the one it should be. A transaction’s access list could include items that are not actually accessed.

• And, as it says on the tin, they are optional. You can send transactions without access lists.

It’s unclear to me how transaction-level access lists will be affected once BALs are added. I’ve seen some people implying they will no longer make sense long-term, but I don’t fully understand why.

A historical note

I find it very interesting to look at the earliest proposal⁷:

As you can see, the original idea only included reads and it was all about I/O prefetching. Writes were added later to enable parallel execution. In that sense, the way BALs developed is the opposite to how I explained them here. But since the “marketing” of the feature has focused a lot on parallel execution, I thought it made sense to start there. I also think it’s a better way to understand them.

This early iteration also explains why BALs have that name, which seems like a misnomer to me. It’s not 100% wrong, since a write is also an access, but it feels slightly off. In any case, it’s way too late to change it now.

Thanks for reading! In the next article, we’ll explore EIP-8024 (Backward compatible SWAPN, DUPN, EXCHANGE), another EIP that will (probably) be included in Glamsterdam, and the one that, fingers crossed, will kill Solidity’s infamous “stack too deep” error for good.

If you'd like to be notified when new articles are published, you can subscribe to the blog.

1. Headliners are the flagship features included in a network upgrade. To learn more about how they are decided, check this Ethereum Magicians post.

2. We could also execute tx 4 immediately after tx 2 finishes. For simplicity we are using execution batches here.

   
   

3. I’m playing loose with the terminology here. The block builder and the block proposer could be different entities, as is in fact usually the case. I’m using them as synonyms here because it simplifies the explanation.

4. I don’t know which of these benefits has the bigger impact. It doesn’t seem obvious to me that parallel execution results in a bigger speedup than I/O prefetch. Hopefully we’ll have actual numbers on this at some point.

5. The first time I was learning about BALs I was surprised no one mentioned state bloat. Surely that was another downside? But BALs don’t become a permanent part of the blockchain state and, as explained in the User-facing changes section, they can be pruned after ~2 weeks.

6. Optional access lists were introduced in EIP-2930 mainly to allow “unbricking” contracts that could become unusable after certain gas repricings included in the same upgrade. The explanation is complex, but see this old (and outdated) article of mine if you are interested.

7. Or at least the earliest linked document in the EIP website. Apparently, the idea had been toyed with before, for example in this 2021 post.

Preinstalls

All the methods we've discussed so far are available to anyone who wants to use them. For completeness, though, we should mention another way to get a contract at a given address: include it at the protocol level. That is, the contract exists at that address simply because the rules of the chain say it does. Contracts included this way are usually called preinstalls.¹

This is exactly what OP Stack chains do: the four CREATE2 factories we discussed in the previous article, along with many other contracts, are available without having been deployed through a transaction.

Preinstalls make a chain more "batteries included", but they can also serve as a useful last resort. Consider a contract that was deployed many times using Nick's method but that can't be deployed in some new chain because the gas limit of the transaction is too tight. In this case, the chain could decide to add the contract as a preinstall in a network upgrade. It's not a method you would choose first, but it's good to know the option exists.

RIP-7740

RIPs are Rollup Improvement Proposals, a mechanism for standardizing behavior across different rollups. RIP-7740 simply proposes that all rollups preinstall a set of CREATE2 factories at their usual addresses, so that anyone can count on their availability. The specified set is precisely the four contracts from our previous article: Arachnid's Deterministic Deployment Proxy, create2deployer, Safe Singleton Factory, and CreateX.

EIP-7997

EIP-7997 proposes adding a CREATE2 factory as a predeploy² to the Ethereum L1 and, by extension, to any EVM-compatible chain that wants to stay in sync with the protocol. This would be a minimal factory with a behavior similar to that of Arachnid's Deterministic Deployment Proxy.³

One interesting property of this approach is that a predeploy doesn't have an ECDSA private key associated with it, making it quantum-resistant. The CREATE2 factories we discussed before don't offer this guarantee: if ECDSA is ever broken, a future attacker could derive the deployer key and potentially front-run any deployment on new chains with other code. Whether this is a realistic concern is debatable (it requires both ECDSA being broken and that new EVM chains are still being created) but it's a clean property to have regardless.

ERC-7955

As its name indicates, ERC-7955 is an ERC rather than an EIP ⁴, meaning it doesn't require any changes to the protocol. Instead, it proposes a standardized mechanism to perform a deterministic deployment, and uses it to bootstrap a CREATE2 factory.

The proposed mechanism assumes that EIP-7702 (Set EOA Account Code) is available in the target chain. We are not going to explain EIP-7702 here, but let's quickly recap two aspects that matter for the ERC:

• EIP-7702 lets an EOA "transform" itself into a contract. More precisely: any transaction sent to an EIP-7702-transformed EOA results in a delegate call to some specified address.

• For an EOA to delegate its execution, it doesn't need to send a transaction itself. It only needs to sign an authorization, and that authorization needs to be included in an EIP-7702 transaction, which in turn can be sent from any address.

With that in mind, here's how ERC-7955 works:

A well-known private key, corresponding to ERC7955EOA in the diagram, is used to sign an authorization that delegates to SomeCreate2Factory. Neither the address nor the code of this factory matter, as long as it can be used to deploy contracts with CREATE2.

Once the EOA is delegated, a transaction is sent to it (from any account) to deploy another factory: ERC7955Factory, the one we actually want to have at a deterministic address. The key insight is this: when the delegated EOA is called and it delegate-calls SomeCreate2Factory, the “sender” parameter used to compute the deployment address is ERC7955EOA, not the one from SomeCreate2Factory (as it would happen in a non-delegate call). That's why the identity of the factory doesn't matter: the resulting address is determined by the well-known EOA's address, the salt, and the init code, all of which are fixed in advance.

One way I like to think about this method is that we're executing the CREATE2 opcode from an EOA, something that was impossible before EIP-7702. This combines the address stability of a managed key with CREATE2's nonce-independence.

A big upside of ERC-7955 is that there's no need to keep a private key safe; in fact, the key is intentionally made public. Anyone who wants to deploy the factory in a new chain can use it to sign the required EIP-7702 authorization. The main downside is that this method requires EIP-7702, a relatively recent feature, to be available.

There's also a subtler downside. Since the private key is well-known, anyone could sign a different authorization with the same nonce and front-run⁵ the delegation, temporarily blocking the deployment. That said, this isn't a fatal flaw: a new authorization can always be signed with a higher nonce, and we can keep trying until one goes through. And, in the face of a stubborn attacker, we can always use a private mempool to guarantee the authorization is included.

Wrapping up

We've covered a broad range of techniques, from the simplest ones to the most recent:

• Managed private keys, pre-signed transactions, and Nick's method, which are based on normal deployment transactions and have different trade-offs around key custody, replay protection, and permissionlessness.

• CREATE2-based approaches like CREATE2 factories and CREATE3. Given the wide availability of CREATE2 factories, these should be the first option to consider for anyone wanting to deploy a contract in a deterministic way.

• The methods discussed in this article: preinstall-based ideas or the clever ERC-7955.

It's worth pointing out that both ERC-7955 and EIP-7997 were proposed less than a year ago. It wouldn't be surprising if new approaches keep emerging.

Thanks for reading! If you'd like to be notified when new articles are published, you can subscribe to the blog.

1. For a detailed explanation on the difference between precompiles, preinstalls, predeploys, and system contracts, check my answer here.

2. In this context, there isn't much difference between preinstall and predeploy. See the link in the previous footnote for more details.

3. Both use the first 32 bytes of the calldata as the CREATE2 salt, and the rest as the init code. But they have (at least) two small differences: 1) The EIP-7997 factory returns 32 bytes, while Arachnid's returns 20, and 2) The EIP-7997 code forwards the revert reason if the contract creation fails, while Arachnid's doesn't.

4. EIP stands for Ethereum Improvement Proposal, while ERC means Ethereum Request for Comments.

   
   

5. Since the contents of the mempool are public, an attacker could see a transaction that includes an authorization signed by a well-known private key, use that key to sign a different authorization with the same nonce, and pay a higher gas price to incentivize the block builder to include it first. Once included, the original transaction becomes invalid, because it contains an authorization with a nonce that has already been used.

   
   

In the first part we discussed three possible answers: deploying with the same private key and nonce, using Nick’s method, and pre-signing transactions. In this entry we’ll discuss two other approaches: CREATE2 factories and CREATE3.

The CREATE2 opcode

The two methods we’ll explain in this article are based on the CREATE2 opcode, so let’s quickly review how it works.

As we saw in the previous entry, contracts can create other contracts using the CREATE and CREATE2 opcodes. The CREATE opcode behaves in essentially the same way as deployment transactions:

• Some init code is executed to get the runtime code of the new contract.

• The address of the created contract depends on the address and nonce of the sender. For deployment transactions, the sender is the EOA that signed the transaction. For CREATE, it’s the address of the contract executing the opcode.

The CREATE2 opcode is similar to CREATE, but the way the address is computed changes. Remember that, for CREATE and deployment transactions, the formula is:

address = keccak256(rlp([sender, nonce]))[12:]

For CREATE2, on the other hand, it’s:

address = keccak256(0xff ++ sender ++ salt ++ keccak256(initcode))[12:]

where salt is an extra 32-byte input passed to the opcode.

Notice which parameters affect the resulting address now. The sender is still one, but instead of the nonce we have a salt and the hash of the init code.

CREATE2 factories

Suppose there is a factory contract that receives some init code and a salt, and executes the CREATE2 opcode with them. Let’s also suppose this factory is deployed in two chains, and we use both of them to deploy a contract.

Will the created contract have the same address in both cases?

As we explained in the previous section, the address will depend on:

• The init code and salt passed to CREATE2

• The address of the factory

Since we are deploying the same contract, the init code will be identical. And we are passing the salt, so we can just use the same value in both cases.

In other words, the address of the deployed contract will be the same as long as the address of the factory is the same in both chains. But this is exactly the thing we want to solve in the first place! It’s a chicken-and-egg problem. That being said, if we manage to solve it, we are solving the problem for everyone else, because the factory contract can then be used permissionlessly.

In the previous article we saw some approaches to tackle exactly this problem. Could we use one of those to deploy a CREATE2 factory in many chains that anyone can use? As it turns out, at least four such factories exist. Let’s briefly explore each one.

1. Arachnid’s Deterministic Deployment Proxy

Repo

This is the earliest of the CREATE2 factories we’ll discuss: it was deployed more than five years ago. It’s a very minimal contract that just receives a salt and an init code, calls CREATE2 with them, and returns the address of the created contract (or reverts if the address already had code). Its whole runtime is just 69 bytes of low-level code.

This factory is deployed using Nick’s method.¹ The deployment transaction looks like this:

{
  "to": null, // it's a deployment transaction
  "input": "0x6045...0cf3", // init code
  // ...other fields...
  "r": "0x2222222222222222222222222222222222222222222222222222222222222222",
  "s": "0x2222222222222222222222222222222222222222222222222222222222222222",
  "v": "0x1b",
}

Notice the values of the r and s fields. In our explanation of Nick’s method, we said that any random values have a good chance of being a valid signature, and that’s true. But the problem with using random values is that it’s impossible to prove you don’t actually have a private key that generated the signature. That’s why this transaction uses nothing-up-my-sleeve numbers like 0x2222...2222.

2. create2deployer

Repo

Unlike the previous factory, create2deployer is written in Solidity. This makes it more complex and its runtime much bigger, but in turn it means it can have some useful view functions and it’s easier to call from other contracts. This factory is deployed using a managed private key.

3. Safe Singleton Factory

Repo

This is a fork of Arachnid’s Deterministic Deployment Proxy made by the Safe team. The only difference is how it’s deployed: it uses a managed private key instead of Nick’s method, allowing it to be deployed in chains that enforce replay protection.

4. CreateX

Repo

CreateX was developed by the same author of create2deployer, and improves upon it in at least two ways:

• It has even more features (like CREATE3, which we’ll explain in a minute)

• It’s deployed using pre-signed transactions², with a managed private key kept as a backup

Availability

These four factories have been widely deployed. All of them are available in the chains listed by evmdiff. I went over the list of rollups in l2beat and had to reach the 15th listed chain to find an example of a missing factory: Morph doesn’t have create2deployer, at least at the time of writing this.

Even if some factory is missing in a given chain, chances are that CreateX will be there: it's been deployed to over 180 chains.

CREATE3

In our discussion of CREATE2 factories we said that we can deterministically deploy a contract as long as:

• There is a CREATE2 factory at the same address in all the target chains

• We use the same salt and init code each time

As we just saw, factories are widely available, so we can consider the first point as a given. And in all of these factories, the salt is provided by the caller, so we can just use the same value each time.

What about the init code? Since we want to deploy the same contract, it’s natural to assume it will also be the same each time, but this is not necessarily true. One simple counterexample is a contract that receives constructor arguments whose values might change between chains. Constructor arguments are included as part of the init code³, meaning that the CREATE2-generated address would change.⁴

In cases like that, CREATE2 is not an option because the init code will affect the deployment address; there’s no way around that. The methods based on deployment transactions we explored in the previous article don’t have this issue, but they involve a significantly bigger effort.

If we don’t want to use deployment transactions and we can’t use CREATE2, there’s only one mechanism left to deploy a contract: the CREATE opcode.

Suppose we have a contract factory with the following characteristics:

• It has a method that receives the init code of a contract and deploys it using CREATE.

• It has the same address in every chain.

• It has the same nonce in every chain.

The first two conditions are easy (the code of such factory is straightforward, and we can deploy it using a CREATE2 factory) but the third one is harder: we can’t control who uses this CREATE-based factory, and each time someone uses it its nonce is incremented. But what if we deploy a factory like this and, in the same transaction, we use it to deploy our contract? That’s the essence of the CREATE3 approach.⁵

In this diagram we have a Create3Factory contract with a deployCreate3 method.⁶ The parameters in green are the ones provided by the user. How will the address of MyContract be derived?

We are assuming that Create3Factory exists at the same address in every chain. This means that the two other addresses are:

• The address of the one-time-use CREATE factory. The init code for this contract is always the same, and so its address will depend only on the user-provided salt.

• The address of the contract we want to deploy. Because the one-time-use factory has just been created, its nonce is guaranteed to be 1. This means that only its address will affect the address of our contract.

Putting it all together, the address of our deployed contract depends only on the address of the one-time-use CREATE factory, which itself depends only on the user-provided salt. In other words, the address of our contract will depend only on the salt we pass to deployCreate3. It won’t be affected by its init code, the sender address, or any of the nonces involved.

While this does what we want, it introduces a new problem. When we deploy our contract in some chain using a salt S, anyone can go to some other chain and use the same factory and salt to deploy any contract. This is not great. The usual workaround is to implement deployCreate3 so that the address of the deployed contract can only be obtained by a given msg.sender (there are a couple of ways to accomplish this; see ⁷). In a way, this takes us back to where we started: we need to manage a private key so that the same msg.sender is used every time. But eliminating the nonce dependency is a significant improvement.

What’s next

We’ve covered a lot of ground in these two articles:

• Managed private keys and pre-signed transactions

• Nick’s method

• CREATE2-based approaches, like CREATE2 factories and CREATE3

But there’s still more. In the next and final entry of this series we’ll explore some other approaches to the problem, including the very clever ERC-7955. You can subscribe to the blog to get notified when the third part is published.

1. Which makes sense, because Arachnid is the Nick after which the method is named.

2. In fact, this is the only project I’m aware of that uses pre-signed transactions, and it’s where I learned about that approach.

3. In the previous article we said that the init code is executed to return the runtime code of the deployed contract. While this is correct, it’s an incomplete description. The init code also performs initialization which, in Solidity terms, means executing the constructor. The constructor arguments therefore need to be available, and the way this is done is by including them in the init code.

4. I’m using this as an example of something that makes the init code change, but I should point out that there’s a simple workaround: instead of initializing the contract in the constructor, the contract can have an init method that can only be called once, and it’s immediately called with the proper arguments during the same deployment transaction. If you are using CreateX, you can do this with the deployCreate2AndInit method.

5. CREATE3 was originally proposed as a new opcode, but it was withdrawn because there was a workaround that seemed good enough. The approach we are explaining here is a different workaround though, and the one I believe most people have in mind when they say CREATE3.

6. For simplicity I’m assuming there is a deterministically deployed Create3Factory with this functionality, but the pattern is still possible if there isn’t. In that case, you need to deploy a contract which calls the CREATE2 factory and then calls the one-time-use factory. This contract does not need to be deterministically deployed.

7. One way to ensure a target address can only be used by a given caller is to modify the salt: instead of just forwarding it to CREATE2, the factory creates a new salt by hashing the user-provided salt and msg.sender. If there aren’t other functions that let you use CREATE2 with an arbitrary salt, then this approach guarantees that the resulting address can only be used by that sender. This is not the only approach though. CreateX, for example, does something different.

In this entry we’ll go over three possible approaches: carefully managing a private key, using Nick’s method, or pre-signing transactions. The rest of the series will cover other approaches like CREATE2 factories, CREATE3, ERC-7955, and more.

Basics

Before starting, let’s review some basic concepts that are necessary to understand the rest of the discussion. Feel free to skip this section if you are familiar with the following:

• How deployment transactions work

• The difference between init and runtime code

• How contract addresses are derived

• The way in which the CREATE opcode behaves like deployment transactions

Normal vs deployment transactions

We can think of Ethereum transactions as falling into two groups:

• Transactions that have a recipient address. This recipient can be an EOA¹ or a contract. If it’s a contract, its code is executed. Let’s call these normal transactions.

• Transactions that don’t have a recipient. These are used to create a new contract, so we’ll call them deployment transactions.

Init code vs runtime code

When we use a normal transaction to call a contract, the code of this contract is executed and the data field in the transaction is used as the input. In that context, we call the contract’s code its runtime code. But when we send a deployment transaction something quite different happens: it’s the data field that gets executed. The result of this execution is used as the runtime code of the deployed contract.² In that context, we say that the data of the deployment transaction is the init code of the contract.

It’s important to emphasize how different these two scenarios are. When we call a contract, the data field usually encodes the function we are calling and the arguments we are passing. That is, it’s just data. But in a deployment transaction, the data is valid EVM code.

Address derivation

We now know that the runtime code of a newly created contract comes from executing its init code. But where is the contract deployed? Its address is determined by the following formula:

address = keccak256(rlp([sender, nonce]))[12:]

That is: we RLP-encode the address and nonce of the account sending the deployment transaction, hash the result, and take the last 20 bytes of that hash. But the details don’t matter that much. What’s important for our purposes is that the address of the deployed contract depends only on the address and nonce of the sender.

The CREATE opcode

Transactions are not the only way to create new contracts. Existing contracts can also make deployments. One of the two ways they can do it is with the CREATE opcode (the other way is with the CREATE2 opcode, which we’ll discuss in the next entry of this series).

For this discussion, there isn’t that much difference between a deployment transaction and an execution of the CREATE opcode:

• Both execute some init code, but the CREATE opcode takes it from the EVM memory of the current execution, not from the transaction data.

• In both cases, the address of the created contract depends on the deployer's address and its nonce. When a contract makes a deployment, its address and nonce are used. The only nuance here is that contracts only increment their nonce when they deploy contracts, and that their starting nonce is 1.

Approach 1: Managed private key

We want to figure out how to deploy a contract at the same address in multiple chains, and we explained that the address of a contract depends only on the address and nonce of the account that sends the deployment transaction. This means that there is a straightforward solution to our problem: deploy the contract using the same private key on every chain, making sure it's the first transaction sent from that address (or the second, or the fifth; it doesn’t matter as long as the nonce is always the same).

This is the simplest answer to the problem of deterministic deployments, but it has a few downsides:

• The private key needs to be kept secure in perpetuity. If you lose access to it, then there's no way to deploy at the target address in new chains.

• If for any reason the deployment transaction reverts, the nonce gets consumed and the possibility to deploy at the desired address is lost forever for that chain.

• The deployment can’t be done by anyone. Only the people with access to the private key can deploy the contract.

Approach 2: Nick’s method

Nick’s method is a technique to create valid transactions without using a private key. To understand how it works, we first need to have a proper view of what a transaction is made of.

In our first diagram, a transaction was represented by an object like the following:

{
  "from": EOA,
  "to": Foo,
  "data": "0x1234...",
  // ...other fields
}

While this is a useful simplification, it’s not technically correct. A more accurate representation is:

{
  "to": Foo,
  "data": "0x1234...",
  // ...other fields...
  "r": "0xabcd...",
  "s": "0xfedc...",
  "v": 27,
}

The r/s/v fields are the values of the transaction signature. Notice we have removed the from field: since the sender address can be recovered from the signature values, including it in the transaction is redundant and wasteful.

The normal way signature values are obtained is by encoding the transaction and signing it with a private key. But here’s the thing: it’s easy to use arbitrary r/s/v values and get a valid signature for a given unsigned transaction.³ The from that corresponds to this signed transaction will be effectively random, but if we fund that address and then propagate the signed transaction, it will be mined.

We can use this method to manufacture a signed deployment transaction and propagate it in multiple chains. The address of the deployed contract will be the same in every chain, because the sender is the same and the nonce is always 0 (we have to use a nonce of 0 for the transaction to be valid, because the sender address, being effectively random, is completely unlikely to have a non-zero nonce).

This method, normally called Nick’s method⁴, improves upon two of the downsides of the managed private key approach of the previous section:

• There’s no need to keep a PK secure because there’s none involved.

• Since the manufactured transaction is public, anyone can deploy the contract in a new chain by funding the sender and propagating the transaction.

But the method has a couple of downsides that the previous approach doesn’t have:

• The transaction can never be changed, because that would invalidate the signature. This means that all the fields have to be valid for every possible chain. If, for example, the gas limit is too tight and we propagate the transaction in a chain where opcodes are pricier, then the execution will revert with an out-of-gas error. In that case, the possibility of deploying to that address will be lost forever.

• Nick’s method only works on chains that don’t enforce replay protection⁵, because we are intentionally replaying the same transaction in every target chain.

Approach 3: Pre-signed transactions

This approach can be seen as an extension to the managed private key approach rather than its own thing. I’m explaining it in a separate section because it’s easier to understand its trade-offs after having gone over Nick’s method.

We said that the managed private key approach means keeping a PK secure forever, and that only those with access to it can deploy the contract. But, as we saw in the previous section, anyone can propagate a signed transaction as long as it’s valid. This means that a deployment transaction can be signed (without replay protection) and shared publicly so that anyone can use it in other chains.

In a way, this approach combines the best aspects of the previous two methods:

• As with Nick’s method, anyone can make the deployment, even if the PK gets lost.

• Unlike Nick’s method, we can use the managed PK as a fallback if the pre-signed transaction doesn’t work (for example, in chains that enforce replay protection).

• And we can sign and share more than one transaction that deploys the same contract. This is useful to have pre-signed transactions with different gas limits.⁶

What’s next

In the next article of the series we’ll look into two other approaches to the deterministic deployments problem: CREATE2 factories and CREATE3. You can subscribe to the blog to get notified when the second part is published.

1. Externally Owned Accounts. These are accounts that don't have code and are controlled by a private key.

   
   

2. More precisely: if the execution doesn’t revert, the return data contains the runtime code that will be used for the deployed contract. For example, the code 0x620102035f526003601df3 returns 0x010203. If you sent a deployment transaction with that init code, a contract with the (nonsense) runtime code 0x010203 would be created. If you want to see how that works in more depth, check this EVM playground.

   
   

3. Basically: if we pick random r and s values, we have an almost 50% chance of getting a valid signature. v can then be derived from r and s.

4. Named after Nick Johnson, who explained in this 2016 article how the method was used for a rather different problem. I’ve also seen this method called “one-time-account transactions”, which is more self-descriptive but less cool. Actually, I think the only person that uses that term is Nick himself, whom I guess is too modest to call it Nick’s method.

5. Transactions with replay protection include the chain id as part of the signed transaction. If the chain id is different from the current chain, the transaction is considered invalid.

6. Notice that this has a griefing risk. If the pre-signed transaction with the lowest gas limit doesn’t work on a given chain, then someone could fund the sender and propagate it so that it reverts with an out-of-gas error, preventing the contract from being deployed to the target address.