Unlocking chain abstracted EOAs with EIP-7702 and irrevocable signatures

TL;DR

• Irrevocable signatures are one of the most important elements to chain abstraction. It’s often overlooked and bucketed into the resource lock problem. This article aims to highlight the intricacies of irrevocable signatures for EOAs and Smart Accounts, and the design impacts for chain abstracting both these account types.
• Irrevocable signatures for EOAs is a given, but compromised under EIP-7702. This needs to be carefully navigated to ensure chain abstract Smart EOAs are not able to attack solvers with double spend attacks.
• Smart Accounts enable key rotation, which is a great security feature, but compromises irrevocable signatures. Systems that chain abstract these smart accounts need to also enable irrevocable signatures.
• Omni Account addresses both these concerns ensuring that both smart accounts and smart EOAs can be chain abstracted under one common system.

Introduction

One underappreciated feature of EOAs is their ability to give irrevocable signatures. This means that once an EOA has signed over a blob of data and propagated the resulting signature, that will always be valid, meaning that it will always recover to that same EOA. While it is possible to allow signatures to be single use for a specific protocol, such as by making the signed data unique and then invalidating it when it has been verified once, the holder of the EOA private key has no recourse of revoking their signature unless this is specifically built into the protocol that recovers the signature.

Given that one of the core feature propositions of smart accounts is key rotation, it is easy to see how this paradigm does not necessarily apply to smart accounts. By definition, key rotation is about making signatures, whether already signed or yet to be signed, unusable in case the signing key gets compromised. However, smart accounts generally can achieve irrevocable signatures depending on the tradeoffs that the developer is willing to make. Before going into the specifics of this and how this paradigm applies to “smart EOAs”, by which we mean EOAs (momentarily) transformed into smart accounts through EIP-7702, it feels useful to first elaborate on what the use cases are that require irrevocable signatures.

The importance of irrevocable signatures

Generally speaking, having irrevocable signatures is useful whenever a signature is validated with some delay after being signed. One clear and recent example of this is in the intents and chain abstraction space. For use cases in this space, it is common to have the user sign a payload that is propagated to solvers and only verified onchain at a later time. In chain abstraction, it might even be common to verify a signature at a much later time, after an intent has been filled on a target chain and solvers are reclaiming their funds on the source chain. In fact, this is how our chain abstraction solution, Omni Account, works. Omni Account allows a user to instantly spend funds on a target chain that are dispersed across many origin chains in a single signature. Being trustless on the user side means that solvers also reclaim their funds on the origin chains using the same user signature as authorization. One attack vector here is to revoke a signature on an origin chain before the solver can come back to claim your funds, essentially double-spending.

Smart accounts

As mentioned above, smart accounts are generally able to key rotate without restriction in order to give users a way to mitigate key loss or compromise. However, smart accounts (and especially modular smart accounts) being programmable means that it is feasible to restrict key rotations in different ways depending on the tradeoffs. For example, one could timelock key rotation so that a user would need to wait for a certain amount of time in order to be able to actually rotate their key. This could solve the problem mentioned above with ensuring that signatures will be valid for at least a certain amount of time.

Smart EOAs (EIP-7702)

The problem gets tricker for smart EOAs. The reason for this is that while the account is programmable, it is not fully programmable meaning that some logic sits outside of the account itself so that the code deployed at the account has no visibility over it. This logic is the re- or un-delegation of the account. Full smart accounts deployed as a proxy do not have this issue because even the upgrade of the proxy is an action that goes through the account so can be restricted in certain ways. Because of this, there can be logic that monitors and enforces checks on any actions that could lead to the revocation of a signature and there is a guarantee that this logic will always run. Because this is not the case in smart EOAs, this presents a challenge to any system that depends on such a guarantee.

One solution is to fall back on the signature of the EOA which will continue to be valid even when the account is delegated. The main caveat is that it is common for contracts and libraries, such as solady, to first check if an account has code and then try using ERC-1271 before even trying to use ecrecover. If this is the case in the protocol that one intends to use then it seems like there’s no way to achieve irrevocable signatures using smart EOAs. However, if the signature logic is controlled by the protocol, then the developer can choose to try ecrecover before even checking if the account has code deployed. This is, for example, what Uniswaps TheCompact does.

Conclusion

Irrevocable signatures are a useful construct especially in the context of multiple execution environments, namely rollups, and the desire to verify a signature across multiple environments with a potential time delay. For example, this is how Omni Account allows users to instantly and trustlessly spend their funds across chains with a single signature. However, while EOAs and smart accounts can give the guarantee of irrevocable signatures, smart EOAs cannot, limiting their usefulness or at least reducing their user experience.