Charting Ethereum's Account Abstraction Roadmap II: EIP-7377 & EIP-5003

The first part of this account abstraction series set up a comprehensive framework for reasoning around account abstraction. Specifically, it evaluated select EIPs to show how programmable EOAs are.

The campaign for EOA programmability is off the back of the (relatively) slow-paced development of native smart accounts and the lack of support for EOAs by the only existing out-of-protocol account abstraction system ERC-4337 (although ERC-4337 was never intended to serve EOAs). 

This second post in the series covers another approach to achieving account abstraction: conversion of EOAs (externally owned accounts) to contract accounts (aka: EOA migration). This development pathway somewhat aligns with the original goal of getting every user to operate primarily from contract accounts using smart contract wallets. 

The schemes discussed in this article present methods for the voluntary conversion of accounts from EOAs to contract accounts. While none of the proposals covered are actively pursued, it is still necessary to cover them for historical context. 

Let's dive in. 

Setting the stage: What is the Ethereum account dilemma? 

Earlier, we had discussed the differences between EOAs (externally owned accounts) and contract accounts. In particular, we established that it all comes down to the user's preference between autonomy and programmability. 

EOAs are controlled by private keys and promise a high level of autonomy: a user can always generate and manage an EOA without relying on a third party. However, the reliance on private keys limits how programmable an EOA can be. 

For example, EOAs cannot have alternative schemes (e.g., multiparty signatures) for authenticating transactions. Why? The Ethereum protocol considers only an ECDSA (Elliptic Curve Digital Signature Algorithm) signature generated with the private key as the only way of validating that the owner of the account approved the transaction. 

A contract account is controlled by code deployed at its address and supports more programmable rules for authenticating and executing transactions. For example, a contract account can use multiparty signatures (where a transaction needs to be signed by multiple accounts to be valid). 

Here, validators do not necessarily care to know if the signature was generated by a private key (contract accounts do not have private keys, anyway). What's more important is verifying that the transaction satisfies the validity requirements specified in the contract code. 

Contract accounts are more flexible and programmable than EOAs, but give users less control. For example, a contract account cannot initiate transactions and requires an EOA to send a transaction that triggers the execution of code deployed at the former’s address. 

Doesn’t this conflict with earlier statements that contract accounts can support arbitrary authorization schemes? Not exactly. Ethereum doesn’t recognize smart contracts as “first-class” citizens (yet) and treats ECDSA signatures—which EOAs use—as the default way of validating all transactions. 

We can explore what this means for contract accounts by using the example of Alice, who owns a contract account that uses a 2-of-2 multisig scheme to approve transactions. An Ethereum node cannot confirm if the account’s owner authorized the transaction because it expects one signature generated with the private key—not two signatures on the same transaction. 

An EOA would have to send a transaction that “calls” the smart contract and triggers the execution of the operation that Alice has queued up. If the EOA’s signature checks out, the only thing left is to confirm that the operation respects validity rules programmed into the contract code. This means doing things like:

• Validating that the number of signers meets the threshold;
• Validating that the signatures are from approved signers, etc. 

Note that Alice cannot interact with her contract account unless she has an EOA—but this would defeat the point of creating a contract account in the first place. She could rely on some third party to help deliver the transaction, but then this exposes her to the risk of censorship if the third party refuses her request. 

The experience would be different if Alice owned an EOA capable of sending transactions by itself, however. Censorship can only occur at the protocol level (Ethereum validators refuse to include her transaction in blocks)—and there are potential defenses against such types of censorship. 

This mini-exploration of the differences between EOAs and contract accounts captures what we describe as the “Ethereum accounts dilemma”. Users want full programmability for accounts but also want to retain autonomy and benefit from the censorship resistance offered by EOAs. 

A question arises at this point: “Can’t we just solve the problem by allowing smart contracts to authorize transactions or allowing EOAs to behave like smart contracts?” The various proposals covered in this series are designed to either upgrade smart contract accounts or upgrade EOAs to make account abstraction feasible. 

This report considers a set of proposals (EIP-7702 (via CODERESET), EIP-5003, and EIP-7377) that transition EOAs to contract accounts. A key benefit of taking this approach is making it unnecessary for users to deploy new (smart contract) accounts to take advantage of AA features. We can simply upgrade existing EOAs to execute code and implement programmable transaction authorization and access policies. 

Before diving into EOA migration standards, we'll briefly introduce EIP-3607—a standard that underpins many proposals that involve giving EOAs the ability to convert to contract accounts. EIP-3607 is key to allowing users to safely migrate their EOAs to contract accounts and is the focus of the next section. 

EIP-3607: Explicitly defining unacceptable behaviour for accounts with code

EIP-3607 defined the lack of autonomy by contract accounts by enshrining the rule that the Ethereum protocol must always reject transactions where an account containing code is specified as tx.origin. This was in order to prevent potential issues arising from address collisions, which occur when a single generated address can be controlled by both code content and a private key.

The rationale is simple: Due to the 160-bit length of Ethereum addresses, it is possible to generate a contract account and EOA whose addresses have the exact same value (i.e., their addresses collide). This was calculated to be feasible within 2⁸⁰ algorithmic operations, assuming a running cost of $10 billion within one year.

One of the potential abuses of such collisions is that a malicious actor may take advantage of users by masquerading as a contract while maintaining a private key. This could be employed by a dishonest party to deploy a contract account—whose access policy is superseded by an EOA's private key—to attract users’ funds and then steal them at a later date.

While this attack vector is quite infeasible due to the costs of generating two accounts with the same address, it’s better to make it outrightly impossible to be on the safe side. EIP-3607 achieves this goal. 

The previous article discussed the difference between tx.origin and msg.sender: tx.origin authorizes a transaction and msg.sender “hosts” a transaction. EIP-3607 explicitly prevents contract accounts from being a tx.origin—that is, they cannot provide authorization for any transaction. For any transaction where the tx.origin has a non-empty code hash value, the protocol must reject it as invalid.

Having explored EIP-3607, we now proceed to explore other EIPs (Ethereum Improvement Proposals) aimed at converting EOAs to contract accounts and show how they are intertwined with EIP-3607 (among other things). 

An introduction to EOA migration to contract accounts  

Generally, EOA migration was barely considered due to the many problems it exposed early on. Nevertheless, it presents a (thorny) pathway to achieving some of the goals of account abstraction.

EOA migration involves converting an EOA to a contract account by assigning it a non-zero code value and revoking its private key. This code value assignment can be done by allowing the EOA to copy an existing contract's code directly or by allowing it to “point” to an existing contract's code—essentially delegating its execution logic to the contract.

The two main proposed EIPs in this category are EIP-5003 and EIP-7377. EIP-5003 is expected to complement EIP-3074, while EIP-7377 is a standalone proposal for EOA migration. EIP-7702 allows users to migrate between EOAs and contract accounts using the CODERESET opcode.

The following sections will now discuss the specifications of these proposals. We’ll also compare and contrast EOA migration proposals—focusing on their implementation details, key features, and limitations. 

EOA Migration via EIP-5003

EIP-5003 was introduced as an adjunct to EIP-3074 to allow an EIP-3074-compliant EOA to revoke its original ECDSA-based signature format. As discussed in the previous report, EIP-3074 enables “signature abstraction” or “authorization abstraction” and allows EOAs to define novel transaction authorization policies using the[AUTH] and[AUTHCALL] opcodes. However, it doesn't allow the EOA's original private keys to be revoked.

EIP-3074's AUTH opcode causes the authorityaccount (the EOA's owner) to offset the tx.origin function to the authorizedaccount (the “invoker” authorized to send transactions on behalf of the EOA) while maintaining the msg.sender. AUTHUSURP from EIP-5003 extends the process by allowing the authority to completely revoke the ability to authorize transactions with the account’s private key. 

The rationale for EIP-5003 is simple: While EIP-3074 allows EOAs to behave like contract accounts, the presence of a private key is a limiting factor—particularly because the private key is a single point of failure. Smart contract accounts solve this problem by implementing novel signature schemes (e.g., multisignatures), but EOAs under EIP3074-enabled EOAs cannot take advantage while the original private key retains the authority to sign transactions. 

EIP-5003 allows users to voluntarily deprecate an account’s private key and complete the EOA-contract account conversion. After the EIP-5003 migration is complete, users will no longer be able to sign transactions using the private key—all transactions are now validated according to the rules defined in the contract account’s logic. 

An overview of EIP-5003 specifications

The EIP proposes the addition of the opcode, AUTHUSURP, which causes a smart contract to be deployed at the original EOA address. This effectively revokes the private key’s authorization power since EIP-3607 prevents addresses with code from signing transactions like an EOA. 

The functionality AUTHUSURP offers is similar to that of the [CREATE opcode with a few tweaks to it:

• An unset authorized field, as defined by EIP-3074's standard, invalidates AUTHUSURP's operation.
• AUTHUSURP doesn't check the nonce of the authorized account.
• AUTHUSURP's initcode runs in the context of the authorized account and must return a non-zero byte value.
• The code returned due to the execution of AUTHUSURP's initcode is deployed into the authorized account after ensuring its code is empty.

In summary: EIP-5003 proposes the addition of the opcode, AUTHUSURP, which effectively causes the content code of an [authorized] account to be deployed at the account of the target address (typically the authority), causing its private key to become invalid. When paired with EIP-3074, EIP-5003 enables an EOA to fully migrate to a contract account.

Limitations of EIP-5003

One of the foremost concerns surrounding the EIP-5003 mechanism is its exposure to attack vectors via permit systems. To understand this, we must take a step back and relearn what the ecRecover precompile is. 

The ecRecover precompile is a system contract responsible for facilitating the secure and efficient verification of digital signatures. This links the ecRecover precompile is inextricably linked to the authentication logic of every EOA.

When a user signs a message, the resulting signature is presented alongside the signed message. Calling the ecRecover contract with the hash of the message and the signature allows an Ethereum node to recover the EOA’s public key from the signature. This way, anyone can verify that the signature indeed belongs to a particular account. 

More technically, when an EOA uses their ECDSA-based private key to sign a transaction, the output is a hashed message (the transaction hash), and a signature composed of three values: the recovery identifier “v”, x-value “r”, and “s”.

The ecRecover contract then takes these values and uses them to deduce the corresponding public address. This is used as proof that the message was actually sent from the corresponding account.

This procedure has numerous uses throughout Ethereum, which can be broadly classified into:

1. Protocol-level authentication: This pertains to recovering a public address for an action carried out on the protocol, such as sending native assets, where the signer's identity must be verified to prevent loss of funds.
2. Application-level authentication: This pertains to situations where the functionalities of a dapp are placed behind an authorization mechanism, such as authorizing an ERC-20 token contract or approving a multi-signature transaction. The application contract uses the ecRecover contract to verify that the authorization for an action originated from the correct signer.

This has critical implications for EIP-5003, especially in the context of schemes like permit2 that allow for authorizing dapps to access ERC-20 tokens owned by a user. Once this permission is authorized, it is valid until a predefined deadline—unless a user manually revokes the relevant token contract’s permission beforehand.

Many DeFi protocols rely on permit-style authorization to facilitate operations that involve accessing tokens without requiring the user to manually grant approval every time. For example, “yield optimizers” are designed to maximize user ROI by depositing assets in various DeFi protocols to earn interest (e.g., supplying liquidity to a Uniswap pool to earn liquidity provider (LP) shares) and require authorization to move tokens on behalf of users. 

That said, permit presents a problem for users who opt into EIP-5003. Typically, EIP-5003 revokes a user’s private key and prevents it from signing transactions. But ecRecover recovers the original signature without checking for code—this means we’ll likely run into scenarios where the private key can still authorize transactions and spend funds from an account.

Thus, the risk with EIP-5003 is that a malicious actor with access to a revoked private key can access account funds even after the user has implemented alternate transaction authorization schemes. Moreover, the account is vulnerable to exotic cross-chain attack schemes, where the original signature can be used to access the account's funds on a different EVM-compatible chain that uses the same key pair. 

There have also been arguments that propose adjusting the behavior of the ecRecover precompile contract to prevent the aforementioned issue with permits. However, it has been a cryptographic primitive for too long that altering it in any way will almost surely lead to issues in live contracts—creating a quagmire of sorts.

EOA Migration via EIP-7377

While EIP-5003 is designed to work with accounts that already implement EIP-3074, EIP-7377 bundles functionalities from both proposals into a single transaction envelope. Thus, sending an EIP-7377 transaction would cause an EOA to directly take in code value—revoking/deactivating the private key implicitly—and gain access to programmable authorization policies.

An overview of EIP-7377 specifications

EIP-7377 proposes the introduction of a new EIP2718-compliant transaction type with the format:

[0x04 || rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, codeAddr, storage, data, value, access_list, signature_y_parity, signature_r, signature_s])].

Where: codeAddr is the address of the account whose code value is being copied. It is implemented such that any address is valid for this function as long as it has deployed code (please refer to the first report, where we discuss the behaviors of other variables).

Signing this transaction allows a user to deploy any executable code of their choice at the EOA’s address. This changes the EOA to a contract account and invalidates the original private key. Like EIP-5003, this functionality relies on EIP-3607. 

The execution of this payload occurs in two stages:

1. The contract deployment phase: In this phase the migration transaction directly specifies what [code] value the originating account intends to take on and sets a pointer from the account to this value using state[tx.codeAddr]code. Then, it sets the account's storage trie to be equivalent, per tuple, to that of the account whose code it copied.
2. The transaction execution phase: In this phase an EVM call is sent into the originating account, setting the call's origin as a hash of the originating address (the EOA's address): keccak255(sender)[0 … 20].

This serves two purposes:

• It prevents the limitation of the account due to the caller == origin check implemented by some contracts, by setting the origin of the transaction to a hash of the migrated account's address.
• It allows the originating account to immediately check the logic of the inherited code obtained in the previous phase and utilize it for subsequent transactions.

EIP-7377 is designed to use a code pointer rather than causing an account to assume actual code value. That is, an originating account takes on the logic that deprecates its private key's signing authority and places a pointer to the smart contract code the user wishes to implement its functionality in their account. This allows ease of use since there's a good chance that most of the functionalities users wish to implement for their EOAs already exist.

After setting the code pointer, the account is immediately called with the [data] and [value] variables it specifies to verify that the migration process was successful. The process is meant to be atomic so that if the call fails, the account remains a vanilla EOA.

The EIP-7377 transaction is also designed not to carry a “to” value, as it is valid only once for every account (“once a contract, always a contract” per EIP-3607). Subsequent transactions from an account that has executed the payload cause the code value to provide additional functionalities dependent on its logic. This makes it a contract account for all intents and removes the ability to authorize transactions. 

Limitations of EIP-7377

Flaws related to codeAddr 

The flexibility of codeAddr value presents a double-edged sword in this proposal. While the transaction's high customizability allows any address containing deployed and executable EVM code to serve as a codeAddr value, this same flexibility introduces significant security risks. 

For example, unsuspecting users may authorize their EOAs to point to rogue contracts capable of stealing assets or executing malicious logic. The risk is compounded by the opacity of codeAddr values, which users typically sign without being able to read or verify.

A potential mitigation strategy mirrors the approach proposed for EIP-3074 invoker contracts, where wallet providers would limit signable contracts to verified trusted proxies. However, the specification still lacks a clear resolution on balancing permissionless innovation (using multiple invokers) with security concerns (avoiding rogue invokers). 

Gas pricing issues 

EIP-7377's gas pricing mechanism creates systemic vulnerabilities through discounted contract migration costs, calculated independently of deployed code size. This discount is offered in the contract deployment phase (setting the storage slots consumed by the code). 

Smart contract developers could take advantage of this discount by setting up an EOA, accruing funds to it, and then using an EIP-7377 transaction to migrate it. The issue with this is that contracts initialized in this manner are arbitrarily assigned storage slots during the first phase of the transaction, causing slots to be non-associative with mappings and ultimately leading to opaque storage assignment for contracts.

The complexity highlighted above could lead to a scenario where a deployed token contract holds a balance of the token on an arbitrary address unknown to anyone else but the contract's creator. Another relevant example is that a multi-signature contract created in this way doesn't immediately make it obvious who its signers are. Only the contract's creator is aware, and there is no way to verify it on-chain.

Incompatibility with L2s

On Optimism and other OP-Stack L2s, an L1 contract that wants to make a deposit will have its address transformed to an equivalent alias on the L2 using the code:

// Transform the from-address to its alias if the caller is a contract.address from = msg.sender;if (msg.sender != tx.origin) { from = AddressAliasHelper.applyL1ToL2Alias(msg.sender);}

This logic is necessary to allow the L2 to distinguish between accounts with colliding addresses but different logic (or controllers) on L1 and L2s. However, it is not applied to EOAs due to the assumption that they are controlled by the same entity regardless of the consensus environment. 

This design also prevents confusion arising from address multiplicity due to the call method utilized. Currently, L2 contracts can be called via a direct deposit transaction from the L1, or via a sequencer transaction on the L2.

EIP-7377, however, allows an EOA to migrate to a contract account so that it loses its aliasing exemption on the relevant OP L2. Such an EOA would consequently lose the ability to send direct deposit transactions, potentially reducing the L2's censorship resistance due to the inability to force-include transactions in the L2 chain. 

EIP-7377 also faced the same issues as EIP-5003 regarding permit systems. Applications that use permit systems for authorization/authentication will run into scenarios where EOAs cannot make transactions, but ecRecover goes on to recover the ECDSA signature anyway. Hence,  smart contracts that verify the signature without checking for code will pose great risks to users if the EIP is implemented.

Migration via CODERESET

The changes introduced in EIP-7702 established a new account standard—migrated EOAs—in Ethereum, besides the two legacy standards (contract accounts and EOAs). These migrated EOAs can behave as EOAs (sending transactions authorized using their private key) while having the added ability to execute code that they point to (thus behaving as a contract account).

In the current specifications, the private keys of such migrated EOAs are a valid access policy with greater power than their contained code. This makes the proposal liable to issues similar to those we previously discussed for EIP-3074, where a private key leak could still be detrimental to the user.

CODERESET is used to refer to a set of changes proposed to make EIP-7702 compatible with EIP-3607 such that EOAs implementing EIP-7702 effectively become contract accounts and cannot spend funds assets using a private key. At the same time, users can also revert (migrated) EOAs to normal EOAs by using the CODERESET opcode, which deletes their code. 

As explained here, the current specifications of EIP-7702 support only persistent contract accounts—meaning that accounts cannot bounce between either standard. Also, EOAs that migrate can keep their private key as a valid access policy while allowing their contained code to be used in other scenarios. 

As a consequence, the account remains able to bypass all onchain policies encoded in its subsumed code via the original private key. This prevents the account from implementing alternative transaction authorization policies like multiparty signing and timelocks to improve security. 

The account can technically implement these policies, but it does not matter because the private key can always override them. Thus, it is not as secure as the usual case in which there is no “master key”.

This model allows such migrated EOAs to behave as what we'll refer to as a “vanilla EOA” with in-protocol restrictions, while often behaving as a contract account, thus convoluting its security guarantees since no complementary changes are made to the protocol's mempool to accommodate such accounts.

For context, each account type has distinct constraints:

• EOAs follow strict protocol-level rules through the native mempool.
• Contract accounts operate based on their internal logic with minimal protocol oversight.
• ERC-4337 smart accounts adhere to ERC-7562 specifications.

EIP-7702's migrated EOAs are currently designed to have their transactions processed by the native mempool, whose logic doesn't optimize for accounts with the ability to behave as both EOAs and contract accounts. Thus, there is the possibility that this account standard will introduce new Sybil attack vectors.

The core of the changes suggested by the addition of the CODERESET opcode to EIP-7702 is as follows:

1. Disallow accounts that opt into EIP-7702's offering from acting as tx.origin in any frame, thus making them EIP-3607-compliant and unable to provide authorization for transactions via a private key.
2. Allow such accounts to reset to a vanilla EOA by calling the CODERESET opcode, which deletes their code.

Additionally, an optional calldata field is included to allow a user to explicitly define storage variables for the account during its migration. This feature ensures that the account's setup and code deployment occur atomically to prevent unique frontrunning attacks in which malicious agents can replace the intended content code's address with a different value and take control of the account.

The changes introduced by this proposal offer several significant benefits. First, they maintain the persistence of Sybil resistance mechanisms. EOAs and contract accounts traditionally have explicitly defined restrictions on their behavior, implemented either through in-protocol constraints or their content code. When an EOA can masquerade as a contract account, it introduces new security considerations that current mempool designs aren't equipped to handle. By restricting an EIP-7702 account's behavior to either that of an EOA or contract account, the proposal maintains existing security assumptions.

Another key advantage is policy persistence. Because the private key is no longer a valid access policy for EIP-7702 accounts, developers can implement more sophisticated access policies, such as multisigs and timelocks, with reduced complexity and overhead. This simplification makes them more practical to implement and maintain.

The proposal also offers another compelling feature: the ability for accounts to take on ephemeral functionality during execution. Through the inclusion of the CODERESET opcode in EIP-7702, calldata passed in an initialization transaction can execute the opcode after completing the target content code's logic—all in an atomic operation. This enables an EOA to begin a transaction as itself, transition to acting as a contract account during execution, and return to its EOA state at completion.

Limitations of CODERESET (EIP-7702) 

The proposal faces significant criticism regarding its security model. In particular, the incompatibility with ecRecover-based permit systems is concerning. 

Applications using the ecRecover precompile without ERC-1271 support cannot properly verify migrated EOA privileges, as the precompile recovers public addresses without checking for the signer code. This leaves migrated EOAs vulnerable to asset loss if their keys are compromised, particularly on applications lacking ERC-1271's signature validation.

Recovery mechanisms introduce further security risks (although maintaining the migrated EOA's private key as a valid access policy creates an in-protocol revocation pathway). Malicious or accidental actions can override delegations, either through redelegation to a different contract or by reverting to a vanilla EOA state via the zero address or EOA's address.

However, the first point may be moot since most assets that can be spent via permit systems support ERC-1271. For the second point, we can debate if a private key leak would be more detrimental when the private key exists as a master key over the account's logic with spend access to all assets—as opposed to the case in which the private key only has the ability to spend tokens that support ecRecover-based permits. Thus, it is mostly a case of consumer education on a complex topic.

While the suggested changes were considered too complex due to the new [CODERESET] opcode, the merits were considerable and led to discussions around redelegation schemes and superior access policies. There are still many debates around EIP-7702's specifications, but the only way for a migrated account to clear a delegation is to redelegate to an empty account.

EOA migration as a last resort

One of the goals we believe must be satisfied by a viable pathway to native account abstraction is that it must remain composable across the Ethereum ecosystem. The most obvious drawback of EOAs converting to contract accounts is that the method doesn't satisfy this condition due to its inherent state drift problem.

When an EOA revokes its private key access on one chain using EIP-7377, for example, it must replicate this action across all chains where that address exists. Without universal migration, the account remains vulnerable to private key exploits on chains where the migration hasn't occurred.

EIP-7377 and EIP-5003 face significant adoption challenges on Ethereum today because they would require implementation across the entire Ethereum L1/L2 ecosystem. The need to complete the key revocation on every chain adds too much complexity for users and makes such proposals unattractive. 

Another general argument against migrating EOAs to the contract standard is that it is something of a circular development. Since the consensus at this point is that both are faulted in different ways, we should try to address their observed shortcomings, not just bounce between standards. This becomes evident when considering that a migrated EOA would still require another EOA for authorization—the original issue remains, just at a different level of abstraction.

Account abstraction isn't enabling EOAs to behave like legacy contract accounts—the former should be able to maintain their autonomy to an extent—and coupling it with the programmability of contract accounts. Fully migrating to a contract account effectively eliminates the EOA’s autonomy, leaving it with the challenges of legacy contract accounts and some more. 

EOA migration schemes would create unnecessary technical debt in the EVM since their functionality would become redundant once native account abstraction is achieved. When accounts can inherently utilize advanced features through built-in mechanisms, there would be no need for migration between different account standards. 

Also, the increasingly present threat of quantum computation leaves the Ethereum protocol with much less time for experimenting with the ECDSA- and BLS-based schemes it employs for most of its cryptographic proofs. Quantum-resistant schemes such as lattice- and hash-based cryptography are probably the protocol's best bet for post-quantum computation in the following years, and smart accounts that aren't ECDSA-dependent are an easy route to the solution.

Ultimately, these reasons have allowed the EOA-programmability route to be considered and adopted as a more viable way to allow accounts to access some of the features of abstraction without enshrining any existent features any further.  It is important to note that this is all in the interim while native/in-protocol account abstraction is being figured out for a not too distant future.

Conclusion

Migrating EOAs undoubtedly comes with the benefit of some backward-compatibility and lesser development costs since we are simply taking advantage of existing smart wallet infrastructure. However, this approach has faced setbacks due to its incompatibility with a fully functional account abstraction framework (in addition to other issues described in this report). 

Account migration is good—just not good enough to be the route Ethereum takes in the short term to achieve full account abstraction. The next report will cover another approach to accelerating Ethereum’s account abstraction roadmap: native account abstraction. 

Native account abstraction proposes to enshrine AA features directly at the protocol layer and make smart contract accounts first-class citizens. Such proposals would reduce reliance on or totally eliminate the need for out-of-protocol AA solutions like ERC-4337 and resolve many issues that have blocked the development of account abstraction on Ethereum so far. 

Acknowledgements: Special thanks to Hadrien Crubois, Nicolas Cosigny, Sam Wilson, Yoav Weiss, Konrad Kopp, Alexander Chopran, Eugenio Reggianini, and Koray Akpinar for review and feedback. We also appreciate SafeDAO for funding work on this report via the OBRA program.