Our blog is live! Read this article on our Safe Blog.

https://safe.global/blog/eip-3074-risks-opportunities-for-smart-account-adoption

Co-authors: Lukas Schor, Richard Meissner, Tobias Schubotz Special thanks for your feedback: Martin Köppelmann, Konrad Kopp, Itamar Lesuisse, Matt Garnett, Kristof Gazso, Ahmed Al-Balaghi, Vitalik Buterin, Yoav Weiss

On the journey to full account abstraction (AA) on Ethereum, we stand at a crossroads: ERC-4337 lies behind us, while ahead, EIP-3074 opened up a new path towards full AA. However, there is a risk to diverge onto the dangerous path of EOA Enshrinement. To prevent this it's critical to support EIP-3074 with the addition of EIP-5003 in the upcoming hardfork. This builds a sturdy bridge to full AA, avoiding the risk of fragmentation and leading Ethereum safely towards the bright future of smart accounts.

The Ethereum Core Developers have aligned to incorporate EIP-3074 in the upcoming Prague/Electra hardfork, targeted for Q4 2024 / early 2025. EIP-3074 allows externally owned accounts (EOAs) to delegate their transaction capabilities to smart contracts, enhancing functionalities like transaction sponsorship and batch processing. While EIP-3074 serves as a short-term fix to improve the UX of EOAs, most of the Ethereum community is still aligned that the end-goal is to move all users to smart accounts. EIP-3074 brings some improvements to smart accounts and is a stepping stone towards full AA, but it absolutely requires EIP-5003 to fully get there. Without EIP-5003, we would enshrine EOAs further.

EIP-3074 modifies the Ethereum protocol to allow EOAs to delegate (AUTH) their transaction capabilities to smart contracts (so-called “invokers”), enabling additional functionality like:

• Sponsored transactions: Ability for dapps or other parties to sponsor the gas of a transaction.

• Batched transactions: This allows for two or more contract calls to be executed in the same transaction. Users can call approve and transferFrom in a single transaction, for example.

• **Access delegation: **Users can delegate control of their EOA to other keys which might have different security properties. For example, a user may add a phone hot wallet key with a daily allowance to their account.

These features were so far only accessible to smart accounts. Which meant that applications had to build two different user experiences for EOAs and smart accounts.

EIP-3074 primarily empowers EOAs, but it also brings some new beneficial side-effects for smart accounts:

• Easier migration: With empowered EOAs, users could more easily migrate to smart accounts. A crucial challenge for users to switch to smart accounts so far was the effort and gas cost of migrating existing assets. EIP-3074 allows smoother migration in a single batched & gas-sponsored transaction.

• Unified UX/DevEx: Dapps can build better user experiences without having to exclude EOAs. This increases significantly the incentives to leverage sponsored transactions and transaction batching, as well as standards around them. Dapps would generally need to adjust to more flexible account logic, which would allow smart account features like session keys or multisig to fit better into overall development frameworks.

• Hybrid accounts: EOAs can set smart accounts as invokers. For example, this would enable a Safe Smart Account to control an EOA, while the EOA’s private key retains superiority and could disable the Safe’s control. This could lead to interesting new hybrid custody use-cases or allow EOA users to “test” a smart account before migrating assets.

While EIP-3074 allows to delegate control over an EOA to smart accounts, the original private key can still authorize any action on the EOA. This prevents EIP-3074 to introduce any (security) features such as:

• Multisig: Multi-signature wallets or onchain multi-factor authentication still require a smart account as EIP-3074 EOAs at any point are still controlled by the original private key.

• Recovery: While certain recovery schemes may be possible, it is never possible to recover (rotate) the primary private key controlling the EOA with EIP-3074, so many recovery schemes require a full smart account.

• Quantum-resistance: Eventually we’ll need to migrate users anyways to smart accounts to achieve quantum-resistance, either naturally or through an emergency hardfork.

• Others: Deny-lists, co-signers/guards, fallback handlers that require different signature schemes depending on the use-case.

There is a viable migration path discussed that would close the gap and allow a full migration of existing EOAs into smart accounts: EIP-5003. This upgrade extends EIP-3074, allowing for deployment of smart contract code at the address of the EOA, while revoking access of the original private key in the process. This allows fully converting EOAs into smart accounts while keeping the public address, soulbound tokens and non-transferable reputation and generally guaranteeing forward-compatibility with the future account abstraction roadmap.

However, there have been some concerns on the viability of this upgrade path, particularly related to edge-cases where the private key, that was assumed to be revoked, could still authorize actions on the account:

• Cross-chain: The revoked EOA key remains valid on other networks, including those that may emerge in the future. This could allow anyone having access to the OG private key to claim the same account on different networks and move assets.

  • If an EOA is migrated to a smart account on a specific network, it should not be assumed that the EOA is migrated on new networks automatically. Smart accounts already face a similar issue today, with them not being deployed on new networks as well as state changes (key rotations) not being synced. Cross-chain approaches like keystore rollups may mitigate this to a certain extent.

• Off-chain signatures: The compromised key can still be misused in off-chain systems, such as the login processes of dapps or permit2 token approvals, which verify signatures. While these systems may support smart contract signature standards like EIP-1271, they typically default to this only if the standard ecrecover fails, leaving room for the revoked key to potentially compromise accounts.

  • The sensible approach would be, as part of EIP-5003, for ecrecover to always fail for EOAs that were migrated to smart accounts. A migration to a smart account should be an explicit and complete move to a new authentication logic.

Over the last months, the community leaned into ERC-4337 as a first step towards full AA. It allowed kick-starting a developer ecosystem, stabilizing the spec and tooling for bundlers and creating learnings. It was subsequently planned to implement native AA on L2s (RIP-7560) and eventually bring a similar EIP on L1.

ERC-4337 initially got started with hugely inflated expectations, which helped gather momentum and attract developers. There have been positive signals that we are close to reaching the tipping point, with major exchanges (OKX, Coinbase) and wallets (Trust, Metamask) investing into support for ERC-4337. But the inflated expectations also meant the inevitable sobering moment that full AA (via RIP-7560 or similar) will take longer than initially expected, as the appetite / urgency for L2s to work on RIP-7560 is still small today.

This is one of the reasons, parts of the community turned to EIP-3074. As the migration of users to smart accounts seemed too far out, some voices became loud to at least partially fix EOAs in the meantime. EIP-3074 does not replace ERC-4337, they are actually quite synergetic, but it does shift the focus further away from ERC-4337/RIP-7560.

In order for full AA to be feasible, we need to find ways to migrate existing EOAs. As EOAs still make up a majority of users in Ethereum, impacting priorities of developers and teams. This can happen in two ways, (1) have users manually switch to smart accounts or (2) implement ways to turn EOAs into smart accounts.

The inclusion of EIP-3074 carries the risk that it will bring us further away from achieving full AA. It enhances EOAs, so it negatively contributes to (1), while not actually solving for (2).

Without EIP-5003, EIP-3074 is currently lacking any clear pathway to full AA and has a net-negative impact on AA adoption. Even more, after the Prague/Electra hard fork there might not be a window to include AA-related upgrades for another 2 years as focus will shift towards verkle trees. Therefore we should include EIP-5003 in the Prague/Electra hardfork, to prevent having EOAs enshrined further.

The debate around EIP-3074 is a critical juncture for Ethereum's account abstraction trajectory.

Original AA Roadmap

Experiment with application-level AA (ERC-4337), showcase native AA via L2s (RIP-7560) and eventually bring native AA to L1. Solve for legacy EOAs via migration transaction (EIP-5003, EIP-7377 or even force-migration). This path is likely to take significantly longer than expected and is held back by EOA dominance.

What we SHOULD be doing instead

Implement EIP-3074, but also include EIP-5003 in the Prague/Electra hardfork, allowing for a full migration to smart accounts. This allows not leaving legacy users behind while ensuring that they don’t hold up AA efforts.

What we are currently planning to do (Worst case)

Only implement EIP-3074, and risk enshrining EOAs, or at least holding up the adoption of smart accounts significantly.