Pectra is the next major ethereum upgrade that is scheduled to happen April 2025. As smart contract developers, the protocol upgrade that we are most interested in is EIP 7702, which includes a new transaction type, that assigns smart contract code to Externally Owned Accounts (EOA), through delegation.Once the delegation process is complete, the EOA transforms itself into a smart account, while at the same time remains as an EOA, ultimately dependent on the transaction that is sent.While the intention of EIP7702 is to be compatible with existing solutions, we believe that this provides us with the opportunity to create a new alternative, and to start with a clean slate.
EOA as the root user
An intentional design decision of the 7702 upgrade is that EOAs are ultimately the root users of the account, since:
EOAs are able to perform redelegation across any smart account implementation
EOAs are able to submit transactions as an EOA, which bypasses all validation in the delegated smart account
Because of the aforementioned 2 features that have arisen from 7702, they lead to the following 2 aspects to discuss, the first of which is regarding storage as a wallet developer, and the second is the new-found ability to have refined controls.
Storage concerns
The first point is a heavy point to consider, since any delegate can potentially access and write storage of the account, which can potentially lead to storage collisions if mismanaged. This sounds off alarm bells in our head, since a core part of our training as developers is to always consider and avoid storage collisions, at all costs. An excellent article discussing the pitfalls is shown here.
This also breaks away from the conventional trust assumption as smart contract developers, since the account state is something that is now shared, instead of solely maintained by one party. As such, we believe that storage management should not only consider avoiding storage collisions, but also how we can reduce the surface of attack from bad actors that intentionally want to corrupt account-managed state.
Refined ownership models
For those that have been in the crypto scene for awhile, the saying "not your keys, not your crypto" pops up every now and then. The best way, therefore, is to utilise hardware wallets to secure their accounts, instead of seed phrases that reside within your devices. However, this makes sending transactions extremely cumbersome, since each transaction requires interactions with the hardware device, so much so that it discourages people from utilising hardware wallets. Because of 7702, we can provide a new access management model to manage ownership, having the EOA root user secured within the hardware wallet. Users can set permissions to enable controlled access into the account for seed phrase accounts, which allows them to enjoy the seamless user experience they know and love. This model closely mirrors web2 database access best practices, whereby even if a permissioned account is compromised, the damage is still contained.
Minimal, yet powerful, when needed
As mentioned earlier, EOAs can function as smart accounts depending on the transaction sent, post-7702. Therefore, we anticipate that most users will continue using their EOAs in their standard form but will switch to the smart account flow when the traditional EOA model falls short.Being EOA users ourselves, we believe that many EOA users are like us, very accustomed to the current EOA workflow with seed phrases. The question at hand then is this: What kind of features will encourage EOA users to utilise 7702 delegation?
Batch Execution
The bulk of on-chain transactions today are swaps through various DEXes. Anyone that has gone through with an on-chain swap will tell you that the current workflow is suboptimal, due to having to send 2 transactions approvie + swap, leading to delay in execution.Enabling batch execution as a feature not only allows you to execute approve+swap atomically, they also allow you as a user to save on the base transaction fee.
Gas Abstraction
Typically, all transactions include a fee that is denominated in the chain's native tokens. Gas abstraction is a concept that provides alternative forms of payment or sponsorship, which reduces friction in user's interactions with blockchains.This feature is an unlock for a myriad of users, from those sensitive to asset exposure, to those that just want to transact one-off transactions, but do not have the corresponding native currency.
Sessions - Scoped Permissions
Sessions are a way for an EOA to open up restricted access into the account. Restrictions can come in the form of time constraints, authorised sender, as well as refined control over actions that the authorised sender can take.This feature not only enables a streamlined way to manage and utilise hardware wallets as discussed in the section above, but also enables Dapps to interact on the user's behalf, allowing for use cases like regularly scheduled DCAs.
Gas Optimization
This aspect is not really a feature in itself, but we wanted to bring it up as a core consideration, which will be heavily discussed as we explore how to implement the features that we have outlined above.We believe that a gas-minimised approach is also key to adoption, due to the fact that users are sensitive to transaction costs, and many would opt for non-smart accounts if gas costs are too high.Keeping the smart account logic minimal yet intentional about the features we want to provide will allow us to provide the best savings in transaction costs
Conclusion
EIP-7702 marks a significant shift in how we conceptualize wallets, bridging the gap between EOAs and smart accounts. Our perspective is that the optimal smart account should strike a balance—minimal in complexity but powerful when needed. Features like batch execution, gas abstraction, session-based permissions, and gas optimization are crucial in making smart accounts not just viable, but a compelling alternative to traditional EOAs. At the same time, careful storage management and refined ownership models will be essential to maintaining security and preventing abuse.Ultimately, our goal is to create a seamless transition for users who are accustomed to EOAs while unlocking the benefits of smart accounts when the use case demands it. The follow-up articles in this series will expand on the features that we have discussed above, and our perspective on trade-offs we can take.
© 2025 OKX. This article may be reproduced or distributed in its entirety, or excerpts of 100 words or less of this article may be used, provided such use is non-commercial. Any reproduction or distribution of the entire article must also prominently state: “This article is © 2025 OKX and is used with permission.” Permitted excerpts must cite to the name of the article and include attribution, for example “Article Name, [author name if applicable], © 2025 OKX.” No derivative works or other uses of this article are permitted.