Smart Accounts: The need for a unified implementation

This article is a continuation of the Ethereum Pectra Upgrade series from the OKX Web3 Team, where we focus on key findings and observations that we have, along with our perspectives on smart accounts.

The smart account landscape today is highly fragmented, not only across ERC-4337 and non-4337 accounts, but even within the 4337 ecosystem itself. Multiple, diverging implementations coexist, each with their own interfaces, assumptions, and behaviours. While this diversity enables developers to express creativity and tailor workflows to specific use cases, it comes at a significant cost to interoperability, tooling, and user experience.

This variation comes at a cost, to both users, dapps and contract developers, and is further exacerbated by the re-delegation feature of 7702, which inherently allows a single account to have multiple smart account logic, at various points in time. While powerful, this undermines any assumption about stable account behaviour.

1. Non-negotiable implementations of essential standards

ERCs are a community driven effort to create standardised proposals which indicate the behaviour and interface of a particular feature. The responsibility then falls on the developer, to decide if they want to comply with the standard, and subsequently implement it. While this model works for a majority of features, it lacks enforceability for those that must be non-negotiable.

The section below discusses 2 points that should be treated as non-negotiables in the context of changes introduced by EIP-7702.

1.1 Critical state management

All smart accounts contain state that they need to manage, as part of orchestrating transaction flows representing the user's intent. With the launch of EIP-7702, the storage space under an EOA account is not exclusive to a contract, but can be managed by various owners.

Furthermore, when users migrate across smart account implementations through re-delegation, the logic will be essentially "cleared and replaced", but the state that is written by the previous contract is still retained. This could lead to "storage pollution", that can lead to unexpected behaviours. Nethermind also mentions this as one of the attack surfaces here.

In the example above, we showcase 2 contracts A and B, where the user initially delegates to A and performs some operations, then redelegates to B. The issue at hand is that past data managed by A is now being interpreted by B as a different field, which can cause security issues in the operational logic of B

Because of the points mentioned above, there are various solutions that are proposed in the community, one of which is through segmenting storage through namespaces (ERC-7201).However, regardless of which proposal garners the most support, there is no enforceable standard ensuring that all implementations derive and manage critical state (like nonces) in a consistent manner, leading to further confusion for downstream integrators.

• From Wallet provider' perspective - How do I ensure the nonce I am supplying to my users is correct?

• From User's perspective - Why is my nonce changing, when switching between various wallet delegates?

More importantly, nonce is a critical safety mechanism for smart accounts to enforce replay-protection. Old invalid transaction nonces can potentially get reused when switching users redelegate, and requires extra care from developers to prevent them.

While it’s reasonable to expect developers to safeguard against such issues, the absence of enforcement mechanisms leads to unintended consequences for users. Innocent users may suffer from a developer’s oversight, issues that could have been avoided with stronger enforcement of essential characteristics like storage consistency, instead of leaving it open to discretion.

Validation-related state, particularly replay protection mechanisms such as nonces, should originate from a single source of truth, regardless of whether the implementation follows ERC-4337 or not.

1.2 Handling Invariant Breaks: Signature Validation

ERC1271 is a standard that is implemented, to enable contracts to validate signatures. This has also created a standardised workflow for dapps to validate signatures of any address, where it validates through:

• ECDSA recovery for an address with no code

• isValidSignature call to the address, for addresses that have code

A sample of the workflow is shown in the OZ standard SignatureChecker

However, the introduction of EIP-7702 breaks the invariant that EOAs cannot contain code, which can potentially disrupt workflows of existing dapps.

• E.g. Dapps that utilise permits will have their permits unintentionally revoked when users delegate

  • An example is circle's stablecoin permit, with the flow elaborated below

Until the point where dapps can upgrade their implementation to have better mechanisms to detect EOAs, the ideal workaround is that all 7702 smart accounts handling isValidSignature, to support the EOA method of validation as well. Since this issue causes large-scale permit invalidation, it should be addressed in a unified and non-negotiable manner.

A sample implementation can be as shown below:

2. Issues with flexible customization

One of the greatest strengths of customizability is the ability for developers to tailor and extend existing standards to suit specific needs, which fuels innovation.

However, everything comes at a cost. The sections below discuss how composability and flexibility causes issues in the value chain.

2.1 Off-chain integration pain points

Smart accounts introduce new capabilities, but also new complexity. Unlike EOAs, interacting with a smart account requires off-chain tooling to encode and construct transactions that comply with the account's specific interface and logic. This creates significant friction for ecosystem participants:

• Wallet Providers: With each smart account implementation introducing its own methods, parameters, and assumptions, wallet providers are forced to build custom logic to support each variant. This means more development overhead, slower support for new account types, and increased maintenance costs. In contrast, traditional EOA users only need to import seed phrases to complete a migration between wallet providers.

• dApps: The impact on dApp developers is equally severe. Different smart account implementations support varying features, and even when they offer similar functionality, the interfaces and behaviors may differ significantly. Hence, dApps must first detect what type of account the user has, and then tailor their workflow accordingly. Furthermore, implementations for batch executions are different, and the way to determine the outcome varies largely across various projects.

In short, the lack of standardisation at the implementation level, not just the interface level, leads to fragmentation that hurts everyone downstream. Wallets struggle to offer broad support. dApps must code around every edge case. And users are left with unpredictable and inconsistent experiences.

2.2 Security considerations for on-chain verification

Sponsor - anyone who sponsors a user's transaction, can be bundlers or relayers, which can obtain reimbursementIntent

Intent - a representation of users' actions, they want to take on-chain

Validator - a contract that checks whether a user's actions are valid before allowing them to be executed

The 4337 standard is fairly well-established and includes defined security measures for handling sponsored transactions. The following section explores a theoretical approach to sponsored transactions outside of the 4337 framework

Consider an overly simplified sponsored-then-reimbursed transaction flow for a post 7702 smart account shown below. The sponsor makes a call to the smart account to execute the transaction flow. Because the account implementation is customizable and composable, there is flexibility in the validator choice. The flow below has the following assumptions:

• Sponsors only submit transactions if they determine that they will receive payment in a token of their choice for sponsorship (line30), through simulation.

  • E.g. USDC payment

• Sponsors trust the implementation of the smart account, that it is honest and reliable

• Users are able to pick any validator they have installed or whitelisted, to validate their intent.

To minimise attacks on sponsors, we need to reduce the scenarios of red pill attacks, where simulation and execution outcomes are vastly different, to ensure that payment for sponsorship always goes through. External contract calls are always a cause of concern, since a malicious callee can intentionally cause transactions to fail on-chain. Based on the flow above which we have elaborated using pseudocode, we have 3 actions that require calls to external contracts, as well as the implications

1. Validation - call to validator contract to validate the request

   1. Potentially a surface of attack, since validation happens before payment

2. Reimbursement - call to token contract to pay the sponsor

   1. Contract is a token which the sponsor trusts and wants to hold, e.g. USDC.

   2. Token transfer happens before execution, so it should not be reliant on the outcome of user's batched intents

3. Batch call - call to multiple contracts to execute user's intent

   1. Batch call is non-reverting, does not revert the entire transaction, so sponsors still get paid

   2. Batch calls can be made with gas limits, to prevent OOG (since it is a new call context)

From the 3 external calls we have identified above, the call made during validation is a key concern, since it is a call that needs to be successful for the workflow to continue, but we have no way of protecting sponsors in scenarios of red pill attacks.

The way to contain such attacks, is to maintain tight control over behaviour during validation. This would mean that a common solution is to maintain a whitelist of honest validators, which can be maintained by either the sponsor or the smart account provider.

If we take a step further to evaluate, verification processes are fairly similar, and they typically revolve around:

• Custom signature validation for users (e.g. Passkey, Multisigs)

• Scoped authorization for external parties into the account (e.g. Sessions)

Since the benefits that can be obtained from customisation are minimal, yet introduce significant uncertainty for sponsors, the cost heavily outweighs the benefits. Therefore, having opinionated validation workflows allows for standardized behaviours, reducing chances of griefing sponsors.

3. Rethinking Customisation in Smart Accounts

Taking a step back, the primary benefits delivered by smart accounts are clear and well-defined. Rather than supporting arbitrary customisation, most practical use cases center around a few key unlocks. As highlighted in the motivation for EIP-7702, these include:

Batching: allowing multiple operations from the same user in one atomic transaction. One common example is an ERC-20 approval followed by spending that approval, a common workflow in DEXes that requires two transactions today. Advanced use cases of batching occasionally involve dependencies: the output of the first operation is part of the input to the second operation.

Sponsorship: account X pays for a transaction on behalf of account Y. Account X could be paid in some other ERC-20 for this service, or it could be an application operator including the transactions of its users for free.

Privilege de-escalation: users can sign sub-keys and give them specific permissions that are much weaker than global access to the account. For example, you could imagine a permission to spend ERC-20 tokens but not ETH, or to spend up to 1% of the total balance per day, or to interact only with a specific application.

With these goals in mind, deep customisation of smart account logic is not only unnecessary, but counterproductive. Today's landscape features accounts that are largely repetitive in nature, and minimal in variation. This has several downsides:

• Bytecode bloat: Deploying nearly identical smart account implementations with minor differences leads to unnecessary on-chain duplication.

• Illusion of standardization: This is similar to the problem we’ve seen with ERC-20. While the interface is standardised, the behavior is not, leading to widespread inconsistencies and, in some cases, malicious contracts that appear compliant. As shown in this paper's abstract, ERC-20 functions can be subtly (or deliberately) manipulated in ways that break assumptions made by users and integrators.

4. Trustlessness among projects

Trustlessness is a core ideology in blockchain systems, which emphasises a system which is independent of centralised authorities or intermediaries. However, in practice, true trustlessness is difficult to achieve. In the scope of smart contracts, even audited contracts can contain vulnerabilities, and upgradability introduces its own risks. While upgradeable patterns offer flexibility, they also concentrate trust in a single authority (an EOA or upgrade controller).

One alternative is to use immutable contracts. Without shared, well-audited base implementations that have been reviewed and verified by the community, immutability can lock projects into broken logic just as easily as it can ensure safety.

This therefore reinforces the point that, a shared, standardized and auditable implementation is a step towards achieving true trust-free collaboration between various entities. Having this will provide a good basis for "ecological consensus", which fosters cooperation between various parties without establishing trust.

5. Summary

To fully unlock the potential of smart accounts and deliver substantial value to users, dApps, and wallet providers, a minimal, standardized implementation could represent the future for smart accounts in a post-EIP-7702 world. By standardizing key implementations such as critical state management and signature validation, the smart account ecosystem can significantly reduce complexity, enhance interoperability, and provide a more predictable and secure user experience. The activation of EIP-7702 is not merely an opportunity for innovation, but also a crucial chance to establish a robust foundation for the sustainable growth of the Web3 wallet ecosystem.