EIP-7702 comes with a lot of promise for better UX, better onboarding, retail adoption, cheaper wallet operations and many more great features. The hype is real and is justified. However, it does come with a tradeoff between new capabilities and risk.
The recent ByBit hack showed the consequences of inadvertently delegating control to a malicious actor.
Without proper security in 7702-enabled wallet operations, organizations are taking the risk of malicious actors leveraging unclear signatures or misunderstanding of the technology. Even when done consciously and intentionally, delegating your wallet to a smart contract potentially exposes organizations to a new class of code vulnerabilities that were not on their risk radar before.
Let’s explore the risks themselves and a security first approach to getting value from EIP-7702 while limiting the risk exposure.
A new signature that can cost you everything
EIP-7702 introduces a new “authorization tuple signature”.
It creates a code delegation that can be used to take over accounts when used incorrectly. The first thing that wallets need to do is make sure that they are aware and handling (limiting) the new signature type properly to protect the less tech savvy clients from accidental damage.
A reckless approach would strive to allow as open and free delegations as possible, but that is likely to end very fast with losing all funds. A single malicious delegation is all that is needed. It’s very hard to impossible to audit a delegated contract on demand.
A security oriented approach would limit the delegations that can be performed. A delegated smart contract can be seen as an upgrade of the account’s logic – a part of the account/wallet implementation. Any delegation that is performed should be done to a contract that is fully audited and trusted.
Old smart contract wallets are not an option
Adopting an existing smart contract wallet and delegate to it, is the most dangerous and likely to be exploited action that one can do with EIP-7702.
While EIP-7702 has a lot of good traits, one thing that it does not have is compatibility with existing smart contract wallets. Any smart contract wallet that was built before EIP-7702 will be vulnerable to a front-running attack that can wait for an authorization signature, and then execute its own init logic on the account to take over it. This is due to the fact that EIP-7702 does not have support for initialization code or initialization of storage.
Another problem that most pre-existing smart contract wallets do not handle is preventing storage collisions and so they are not ready for the redelegation process that EIP-7702 supports.
These issues are not only the case with the old smart contract wallets but also a new attack vector on accounts in general, using the initialization and storage collision issues in EIP-7702 to attack accounts that want to use the new cool features.
A security oriented approach would only use smart contracts that have been purposely built for EIP-7702 based on the latest specification with support for stateless or protected initialization and future proof storage management.
The smart contract code risk
An EOA has a simple security posture – you need to protect the key.
Smart contracts come with their own security posture – any bug in the contract can result in lost funds. When thinking about the smart contract risk of an EOA, it’s important to understand that the contract has full access to the account and it is limited only by its own code. Furthermore, once a smart contract is authorized it is active until it is deauthorized. Smart contract attacks can be fully simulated by the attacker and so the execution of an on-chain attack is usually immediate and executed on all vulnerable accounts at the same time.
So managing the smart contract risk becomes a core concern when using EIP-7702. We will explore some of the issues and possible mitigation strategies.
EIP-7702 is mostly for hot wallets
Since the value in EIP-7702 is a UX value, rather than security value, it is reasonable to categorize it as a feature for hot wallets which perform more actions that are more sophisticated.
A security oriented approach would be to add EIP-7702 delegation to accounts that hold limited value and keep additional funds in a wallet that does not have smart contract risk associated with it. This is exactly what the hot/warm/cold wallet design pattern is built for.
In smart contract security, less is more
The more feature rich a smart contract is, the more complicated it is, the more attack surface it has and more likely it is to have an exploitable vulnerability. A larger contract is also harder to audit well.
This risk is amplified because in the arms race of smart contract wallet providers, the marketing game is all about adding more features and supporting more use cases with the same infrastructure. A smart contract that is capable of doing things that you don’t need is adding risk without value. The added feature is exactly the one that might be used when an attacker is targeting your wallet to circumvent some security features.
A security first approach should prioritize battle tested contracts and smaller footprint. Since there is no single 7702 compatible battle tested smart contract today – it’s reasonable to look for a smaller attack surface and over time as bigger smart contracts are being validated on chain to add more capabilities based on the learnings from experience. This requires really understanding what features matter and what features are optional and being conscious of that in the decision making.
Trust dependencies and sub-delagations
A smart contract is not only open to the risk of its own code, but also to the risk of any smart contract code that it delegates to for security.
Different paradigms that are used on Ethereum delegate the security away from the account itself to other contracts. Prominent examples are all the smart contract proxy patterns, the ERC-4337 EntryPoint and the new EIP-7710.
When you allow a delegation framework you are giving another contract the ability to go around your own contract and key security. In some situations vulnerabilities can creep in directly in the connection layer (as seen in the earlier days of ERC-4337 with the smart contract wallet implementation itself becoming a point of risk and an exploitable vulnerability) or targeting the delegated code/operation itself like in the Bybit hack which took over the proxy contract to the multisig wallet and used the delegate call the execute bypassing the security layer. Eventually it also just makes your attack surface even larger.
A security first approach would limit dependencies as much as reasonably possible for the use case that it tries to serve. Optimizing for battle tested protocols that have been immutable for a while and are already trusted by millions of users and billions in funds can reduce risk. This can often come at the cost of some features that can be achieved using a dependency or sub-delegation of security.
Security is never just about the contract
Moving from an EOA to an upgraded 7702 based account involves adapting a lot of operations off-chain, accounting for new kinds of signatures and new kinds of approval flows as well as monitoring and incident response. This is especially important for multi-user and multi-wallet operations. A lot of the operations paradigms in the blockchain ecosystem are built just for the success flow and do not consider enough what needs to happen if issues arise. This way of thinking is rooted deeply in the permissionless ethos of blockchains that assume maximum responsibility and authority by the user.
A security first approach would need to validate that the security flow for 7702 enabled signatures is compatible with the security flow of regular EOA transactions and has as similar as possible security guarantees. Supporting the on-chain validation with proper off-chain security is critical to maintain a strong security posture.
A security first approach
While it is very enticing to jump right into any new feature or capability that is being introduced, it is usually not the most security oriented way of doing things.
Gradual adoption of new capabilities, letting the market mature, choosing vetted technologies, using future compatible architectures, optimizing for minimal exposure and focusing on risk management are the practices that will allow a safe adoption of all the great things that EIP-7702 can bring.
