Elegant Degradation & Backwards Compatibility: The Missing Piece of the Puzzle for Account & Chain Abstraction

Account AbstractionChain AbstractionEIP-7702ERC-4337ERC-7579

The solutions propsed in this article are part of a team R&D effort at Biconomy. Notable research contributions come from Filip Dujmušić, Filipp Makarov, Venkatesh Rajendran and Shunji Zhan

I have spent the better part of the last two to three years working on the problems of Account & Chain Abstraction. The initial research was done in a small R&D startup called Klaster which then merged with Biconomy in November of ‘24. Since then, myself and the team have spoken with hundreds of clients looking to improve the UX of their applications and oversaw the deployment of millions of smart accounts.

With standards such as EIP-7702 slowly picking up in usage and more and more providers joining the Ethereum UX space, I am inclined to write on one very often neglected part of development stacks in this area - ensuring backwards compatibility with non-7702 EOA users.

The problem is two fold:

  1. How do we ensure that the users of non-7702 EOA wallets are able to leverage at least a part of the capabilities of Account Abstraction
  2. How to we make the lives of developers who want to leverage Account Abstraction easier. So that they don’t have to build two completely separate transaction pipelines for two cohorts of users.

Onboarding Existing Users

Anyone who has worked in Account Abstraction will tell you that one of the hardest challenges in the space is getting existing users to migrate away from their EOA accounts onto Smart Accounts. While a lot of researchers and entrepreneurs in the space are calling out the fact that Account Abstraction was built for the next millions and billions of users - neglecting the existing userbase and the UI flows they’re used to is a mistake.

We can broadly separate the issues into three categories:

  1. Users not wanting to deposit funds into Smart Accounts
  2. Users not wanting to upgrade wallets with EIP-7702
  3. Wallets not adding support for EIP-7702

#1 - Users depositing into a smart account

I will not dwell on point #1 as it’s quite a simple one. The users who have their EOA wallets have their entire transaction history tied to that address, they have funds across multiple chains and they hold dozens of tokens. Some of them have POAPs, soulbound tokens and non-transferrable DeFi positions. If they migrate some of their funds into a Smart Account, they will have effectivelly bifurcated their onchain experiences into two distinct addresses with two distinct user experiences and flows.

For a lot of the users - this is completely unacceptable and any benefit which Smart Accounts can bring will not get them to change their mind.

This problem is widely understood to exist within the AA research community and the proposed solution to it, which a lot of people were hoping would achieve explosive adoption - was EIP-7702.

#2 & #3 - Upgrading via 7702

EIP-7702 allows users to sign a simple authorization message which will convert their existing EOA address into a Smart Account. This way they retain all of their history, all of their POAPs and soubounds and all of their DeFi positions, so - problemn solved? Unfortunately, not quite.

For EIP-7702 to work, we have a two hard requirements:

  • (a) Wallets must implement support for EIP-7702
  • (b) Apps must take advantage of Smart Account features (e.g. Batch Execution through ERC-5792)

Point (b) is far from being universally implemented, but some good progress has been made by some of the most used apps in the space. Point (a), on the other hand - has had a much choppier adoption.

At the time of writing this article, a lot of prominent wallets still haven’t implemented support for EIP-7702 and the vast majority of users of the wallets which have implmeneted it haven’t upgraded their EOAs. Reasons for this are manifold - spanning from user inertia, security concerns, wallets not wanting to allow advanced features to apps since it reduces their bottom line profitability, etc… (e.g. allowing an app to a one-click gasless bridge + swap makes their own gasless bridge + swap feature less attractive. And features like those are the main revenue driver for wallets.)

So if EIP-7702 won’t solve for it, what option do we have? In this article I will present one solution which the team at Biconomy and I have built and shipped into production - but I don’t consider this to be the solution. The point of the article is to open up the discussion and get inputs from other R&D folk in the AA community.

Backwards Compatible One-Click Fund + Execute

The way that we have tackled this challenge is by funding the smart account and approving all the subsequent actions on that account in a single signature. How did we achieve this?

We have taken advantage of a well-known “hack” within the EVM calldata encoding. Notably - the EVM treats the calldata as an unstructured byte array. When a contract call happens to an EVM contract function, any bytes in the calldata which are after the expected byte length of that specific call are ignored.

What does this mean for our elegant degradation? It means that we are able to:

  1. Call an approve function which approves a certain amount of some token to a users smart account
  2. Append a hash of the additional instructions we want to execute after the end of the byte array
  3. Call a bundler/node/relayer with the additional instructons which will then call the execute function on the smart account
  4. The smart account will pull the required funds from the users EOA
  5. The smart account will verify that the additional instructions executed by the relayer match the hash which the user has signed
  6. As the last step of the execution, the smart account will transfer any resulting funds back to the EOA

Example

Let’s use a simple example (for which we will show a video and a link to explorer transactions). The desired action of the user is to do a cross-chain batch execution in the style of Biconomy MEE or Etheruem EIL (multiple function calls across multiple chains). For this - a smart account is necessary if the user doesn’t have EIP-7702 upgraded account. The execution will do the following:

  1. Take USDe tokens on Base
  2. Bridge the USDe from Base to Arbitrum
  3. Supply USDe into Compound Vault on Arbitrum

What our “elegant degradation” will enable is for the user to achieve all of this in a single signature from a normal, non-upgraded EOA account. Under the hood the process is the following:

  1. User approves their Smart Account to spend USDe tokens on Base (ERC-20)
  2. The hash of additional instructions is appended to the approve function call. In this case this is a Merkle Tree encoded list of all function calls across all chains.
  3. The relayer calls the execute function and starts execution all the transactions across all chains.
  4. The smart account has an implementation which knows how to read these extra bytes and check this merkle tree hash against the operations being executed. All validation is done onchain. The relayer can’t “cheat” the user.
  5. The last step of the operation transfers the resulting Compound Vault tokens back to the users EOA

From the users perspective, all operations were done from their EOA. They didn’t even have to see the “passthrough” smart account.

Here is a link to the smart account explorer showing this: https://meescan.biconomy.io/details/0x617c16a2071e4b109f6575ccaa9b1560b3cf8f6dec8c555a5db71484b9c12248

Here are the underlying links for the operations being executed:

Polygon: https://polygonscan.com/tx/0xd3030f83185e7f295f675efd92a457e7b199d803ca553244f30a1019f95ae72b Base: https://basescan.org/tx/0x32f6def621dd916c9d76afb2d87de05c321b2314e117213aeb5cbec2412955b9

Here is link to the video showing an app which is using this:

By using this approach we enable all of the users to get some advanced features of Smart Accounts such as batch execution, cross-chain execution, scheduled execution and much more.

Atomicity

In single-chain operations, after the approval is done - all of the operations (including sending the resulting funds back to the users EOA) are executed atomically.

In multi-chain operations, this approach doesn’t “add” any new atomicity concerns which werent present before.

Pros

The pros of this approach are:

  • The user sees a standard approve message. This fits into their existing mental model of approving execution to a smart account.
  • Many smart account features become available to all EOA users, including wallets which don’t support EIP-7702, users who don’t want to upgrade and legacy wallet users.
  • This approach requires zero opt-in from the wallets, apps or any other providers, meaning it can be shipped quickly and used by apps immediately.
  • This can be used as an introduction to Smart Accounts and Account Abstraction for many users. Once they get used to the advanced features, they’ll be incentivised to upgrade to EIP-7702.
  • This approach is easily plug-inable into solutions such as the Ethereum Interop Layer, Biconomy MEE, ZeroDev, Rhinestone, Porto, Alchemy Smart Accounts, Coinbase Wallet, Ambire Wallet, and all other major providers of Account Abstrdaction Solutions. For ERC-7579 and ERC-6900 accounts, it’s a simple validator module change and is compatible with all the other modules.

Cons

The cons of this approach are:

  • The user doesn’t see a clear-signed order of operations for the appended hash. This might be offputting to some users. Though this can also be solved with the Clear Signing ERC (https://eips.ethereum.org/EIPS/eip-7730)
  • Some hardware wallets reject transactions which don’t fit the calldata length. This can be solved by getting the hardware wallets to upgrade the firmware to support it. Hardware wallets don’t have the same incentives to not allow this, like the standard wallets have incentives to not upgrade to EIP-7702
  • While it’s a single signature, this solution includes at least two transactions. This can increase latency and gas. But this is an acceptable tradeoff taking that it targets specifically users who otherwise wouldn’t have access to these features at all.

Conclusion

In this article I’ve presented one possible solution to the backwards compatibility and elegant degradation problem. This article, though - is meant to be a kickstart point for the discussion around this problem, it’s relevance and potential other proposed solutions.