OKX Research Institute | The Endgame of a Decade of Account Abstraction Evolution: Exploring the Past and Future through EIP-7702

The first report from OKX Research Institute is here. The debut issue focuses on one of the hottest topics in the community right now, EIP-7702. In this in-depth article, we’ll walk you through everything you need to know: why it’s being called the “ultimate form” of account abstraction, what problems it actually solves, and what the Pectra upgrade means for wallets, developers, and everyday users.

Pectra is Ethereum’s first major upgrade since Dencun, incorporating the Prague execution layer hard fork and the Electra consensus layer update. It includes record-breaking 11 EIPs, significantly enhancing validator flexibility, network scalability, and execution efficiency. With the Ethereum mainnet’s Pectra hard fork expected to officially activate on May 7, 2025, the ultimate form of account abstraction, EIP-7702, is now stepping into the spotlight.

To support the Ethereum ecosystem, OKX Wallet has taken the lead in supporting Ethereum's latest account abstraction standard, EIP-7702. An official entry point has been opened for users eager to try it out. You can upgrade and experience the secure and professional EIP-7702 by navigating to: [OKX Wallet Home - More - 7702 Upgrade].

Kind reminder: You may choose to upgrade and experience EIP-7702 based on your needs; not upgrading will not affect your current interaction with the ecosystem and applications. For the security of your assets, please make sure to upgrade through official channels, beware of phishing links and malicious websites, and avoid exposing your assets to risk.

Follow this article to fully understand the evolution of account abstraction, the value and changes EIP-7702 brings to users and the market, and the potential risks that lie beneath.

TL;DR

• The code discussed in this article is located in okx/js-wallet-sdk, which includes the EIP-7702 SDK implementation used by OKX Wallet. It is fully open-sourced and accessible to community partners.

• EIP-7702 introduces a new transaction type that allows a regular EOA to designate a contract address as its logic proxy contract.

• Thanks to its cost-efficiency and flexibility, EIP-7702 is poised to not only inherit but also surpass the ecosystem that ERC-4337 has been building for years.

• However, EIP-7702 also poses a hidden risk for regular users. Even without opting into an upgrade, certain scenarios may trigger transaction failures or lead to fund security issues.

• EIP-7702 paves the way for next-generation user experience, by shifting user accounts to contract-based models. It unlocks long-awaited features like gas abstraction and family-tiered accounts, enabling a seamless onboarding journey that could usher a billion users into Web3 at minimal cost.

• For exchanges and DApps, adopting EIP-7702 could reduce operational costs by over 50%, accelerating the transition to a full-fledged contract account era.

Why do accounts need to be abstracted?

It's hard to imagine, but the vision of Account Abstraction actually predates Ethereum itself.At this year's HK Web3 Festival, Vitalik repeatedly emphasized that with solutions like multi-sig wallets, Account Abstraction, and ZK Email, Ethereum has now completed 50% of its "iPhone moment."Is that progress fast or slow? Is this optimism or a limitation? Let's dive into the foundations to understand why AA (Account Abstraction) carries such transformative power.After a decade-long journey, Vitalik is finally witnessing the culmination of his long-awaited vision for AA, a milestone that adds a bold stroke to the progress bar of the Ethereum roadmap he outlined back in 2023.

What is Account Abstraction really for?

At its core, Account Abstraction (AA) addresses the problem of ownership and control being tightly coupled. In today's Ethereum architecture, an EOA (Externally Owned Account) is both the owner and the executor, because control relies entirely on the private key. This design stems from Ethereum's transaction model: technically, a standard transaction contains no explicit "From" field. Instead, Ethereum derives the sender address from the v, r, and s (VRS) signature parameters during execution.

Moreover, Ethereum's design as a "world computer" is fully dependent on transactions to change on-chain state. Since there's no way to assign a transaction to a different "sender", execution authority is inherently tied to asset ownership.

This makes EOA easy to understand but brings about a series of pain points:

• Private key insecurity, if a user loses their key (through misplacement, hacks, or even quantum attacks), they lose access to all their assets.

• Limited cryptographic flexibility, EOAs support only a single signature scheme, limiting performance optimization and inflating on-chain data costs.

• Overpowered permissions, the private key grants total and irrevocable control.

• Inefficient transactions, users must pay gas fees solely in ETH, and even the simplest action costs at least 21,000 gas.

• Zero privacy, all transactions are fully visible, and even proposals like Circle's confidential ERC-20 never became widely adopted.

Ultimately, the blockchain experience today is still too complex for mainstream users. Concepts like gas price, gas limit, nonce ordering, and transaction dependencies are unintuitive and error-prone. EIP-7702 aims to abstract away this complexity.

What are the core differences between ERC-4337 and EIP-7702?

There are actually more than a dozen different proposals centered around the goal of Account Abstraction (AA), some of which have already been explored in this article. When we distill them down, they essentially fall into two main approaches:

Approach 1: Let EOA addresses drive CA (Contract Account) logic

ERC-4337 is the most well-known example in this category. In short, it introduces a new transaction object called UserOperation, which users send to a special mempool. These operations are then collected by bundlers, who batch and execute them one by one through a designated smart contract.At its core, this shifts the execution of transactions and account logic from the protocol layer to the contract layer.Its execution flow can be illustrated as follows:

Through the bundler, this approach (ERC-4337) effectively addresses issues such as batch transactions, gasless user experience, and limited signature algorithm support.

However, what it fails to solve are the problems of complexity, higher transaction costs for users, and the single point of failure risk introduced by the bundler and EntryPoint contract.

For example, once a user migrates to the ERC-4337 system, even for a simple transfer like that of User2 in the diagram above, the gas fee ends up being nearly double that of a traditional EOA transaction.

https://dune.com/niftytable/account-abstraction

https://etherscan.io/chart/address

Based on the latest user data for both CA (Contract Accounts) and EOAs, it's clear that even advanced users who rely heavily on contract-based operations, such as batch calls, haven't widely adopted ERC-4337. If they're already using contract accounts, why not just stick to standard CAs?

The answer lies in ERC-4337's design choice: by avoiding protocol-level hard forks and instead implementing everything at the application layer via the bundler model, it gained compatibility and flexibility. But that came at a cost of double the gas fees, increased system complexity, reliance on centralized bundlers, and loss of the simplicity and flexibility that EOAs once offered.

As a result, despite its ambitious goals, ERC-4337 hasn't achieved widespread adoption. Two years in, usage trends are visibly declining. Even at its peak, the number of ERC-4337 users remains far from Ethereum's 300 million total unique addresses.

This is not to criticize ERC-4337, but rather to acknowledge that the ecosystem it created, such as paymasters and gas abstraction, continues to inspire innovation, especially in EIP-7702.

As with any industry, progress is rarely linear. What matters most is learning from past rises and falls to identify patterns and evolve accordingly.

Approach 2: Transform the EOA into a CA

The idea of turning EOAs into contract accounts isn't new. As early as November 2015, Vitalik proposed EIP-101, which reimagined Ethereum accounts as smart contracts by default. This included features like balances stored via ERC-20–like logic, fee payments using tokens, and permissioned execution through precompiles.

Later, in January 2018, EIP-859 proposed allowing users to include bytecode directly in a transaction to auto-deploy a contract wallet if one didn't already exist.

Eventually, this line of thinking led to EIP-3074, and now, its natural successor EIP-7702 which has officially been accepted into the Ethereum mainnet.

EIP-7702 introduces a new transaction type that allows an EOA to temporarily act like a contract account within a single transaction. This gives users the ability to execute batch transactions, use gasless (sponsored) transactions, define custom permission models, and retain full EOA compatibility and flexibility.

The key innovation is that these capabilities are temporary and opt-in.

Setting up EIP-7702 functionality only costs 80,000 gas (~$0.06).

Updating or removing the linked logic contract costs even less, 40,000 gas.Once enabled, the benefits in batch operations and gas optimization become immediately apparent. See the following table for a cost comparison:

Of course, you might wonder, do I really need to make 2, or even 6, token transfers at once?

For regular users who are used to doing one thing per transaction, it may seem unnecessary. But in diversified application scenarios like web3 games or web3 payments, this actually happens quite often. For example, situations where you spend both copper coins (in-game generated currency) and silver coins (top-up currency) at the same time. Or participating in an event that requires consuming both an NFT ticket and an entry fee.

Even without imagining complex scenarios, take the most common on-chain activity today, token swaps, which already involve a batch process of approve and transfer operations.

In fact, you could even build a small tool to help users quickly remove outdated approval permissions in one go. The effect is easy to compare, and the cost can clearly be reduced by around 40%.

The core principle of EIP-7702

To understand why it has this effect, we need to go back to its underlying principles. At its core, it consists of 2 main parts: the Setup Phase and the Daily Usage Phase.

Setup Phase

Core process is as follows:

• Step 1: Signature authorization. The original EOA uses its private key to sign a special hash string, which is constructed by encoding the chain_id, address, and nonce. Here, the address is the logic contract address to be set, and the nonce is used to prevent replay attacks.

• Step 2: Transaction signing. With the authorization data from step 1, anyone can construct a transaction with type set as 4, that includes one or more pieces of authorization info, allowing multiple addresses to be configured in a single batch.

• Step 3: Broadcast to chain. Once the transaction processes the internal authorization, the logic contract becomes active.

For more technical details, you can refer to OKX's open-source JavaScript SDK implementation to understand how the underlying data encoding works. Of course, this solution also comes with some hidden security risks and complexity, which will be discussed in the next section.

Execution Phase

Once setup is complete, any transaction sent to your address will behave like calling a smart contract. The system will "load" the code of your previously set logic contract into your EOA's state and execute its logic.

Let's look at two scenarios: First, when you call your own contractIf you have set a highly secure and customizable logic contract like OKX's 7702 smart contract, you can use pre-written calldata to execute multiple instructions in a single transaction.

For example, you can perform Approve + Transfer or Approve + Swap at the same time.

Don't underestimate this. Out of a total of 2.7 billion Ethereum transactions, around 75 million are Approve transactions. At an estimated 80,000 Gas per transaction, that adds up to 460,000 ETH consumed. At an ETH price of US$1,700, that's nearly US$800 million.

Second, when someone else calls your contract

Previously, Ethereum didn't allow external parties to call EOA addresses. But now, you essentially become a versatile contract with full customization. You can create sub-accounts with delegated permissions or whitelist specific paymasters or DApp accounts to act on your behalf, enabling gasless interactions without repeated signature prompts in traditional blockchain apps.

This is incredibly powerful.

That's also why nearly all major wallets such as OKX Wallet, MetaMask, WalletConnect, Biconomy, BaseWallet, Rhinestone, ZeroDev, TrustWallet, Safe, and others are rapidly adopting support.

Is EIP-7702 the final form of Account Abstraction?

Yes, because this time, users will choose to use it.

It's not that EOAs are bad. In fact, they are simple, clear, and secure. But after the Prague upgrade, EOAs that use EIP-7702 will become better.

Because of lower costs, and better experience. When Steve Jobs pulled the iPhone out of his jeans pocket, no one knew that these user experiences were even possible.

Account Abstraction is something many blockchains are exploring and actively implementing. For example:

1. Starknet, a ZK-Rollup Layer 2, uses contract accounts by default with no EOAs at all.

2. zkSync Era also defaults to AA accounts and skips the complexity of bundlers.

3. Nervos CKB, despite using a UTXO-like model, allows all accounts to define their own validators, separating ownership and control.

4. Aptos and Sui, as key players in the Move-based Layer 1 world, don't use EVM-style AA, but also support customizable accounts with features like modular signatures and multi-verification.

5. On the EVM side, Linea, Base, Mantle, Polygon, Arbitrum, and Optimism have already supported AA via ERC-4337, and are expected to follow Ethereum mainnet in adopting EIP-7702 as well.

Wallets and AA infrastructure are also laying full groundwork for EIP-7702.Core features such as batch transactions, gas abstraction (gasless options), and account delegation are fully supported by service providers like Coinbase, MetaMask, Biconomy, ZeroDev, Rhinestone, and Ithaca.

These capabilities have been extended from the ERC-4337 era, which is another advantage of EIP-7702. Since the resulting account behaves as both an EOA and a CA, much of the existing AA infrastructure can be reused with minimal adaptation.

Now let's look at a table comparing the functional differences between EOA, ERC-4337, and EIP-7702.

Objectively speaking, Ethereum carries a much heavier historical burden than most other chains. This is part of the reason why recent community voices have opposed Vitalik's proposals to change the EVM, and also why ERC-4337 was initially adopted. But now that a better alternative exists in EIP-7702, which achieves both compatibility with legacy architecture and significant cost optimization, users may finally be facing their "iPhone moment". With this underlying shift in account structure, we can even imagine new possibilities, such as:

• Users controlling their wallets via Passkey or Google Account and enabling conditional no-signature experiences.

• Account recovery through mechanisms like ZKEmail, akin to finding lost private keys.

• For high-value users who suffer asset losses, combining multiple operations into one transaction can reduce block confirmation time and enable faster swaps, while lowering the risk of failure through continuous transaction execution.

Time greatly impacts user experience. As Ethereum is the second-largest blockchain (only after Bitcoin), it cannot casually shorten block time from 3 seconds to 1.5 seconds like BSC. So tools built on EIP-7702 may become the most crucial bridge for improving user experience.

Combining this with our earlier discussion of its technical foundation, we can say that EIP-7702 is the ultimate form of Account Abstraction.

However, it's unlikely that every user will switch to it. Because the feature itself demands caution. Once complex contract logic is involved, the associated risks also grow and some attack vectors are subtle and hard to detect.

Therefore, after Ethereum's Prague upgrade activates on May 7, 2025, what users will need most is a truly secure wallet to protect them through sound technical safeguards.

Has the endgame been reached?

No.

Pectra is indeed Ethereum's most ambitious upgrade to date, covering 11 EIPs, the largest number in history. EIP-7702 brings many clear advantages, and we've assessed them in this article through both principle and data.

But after users begin adopting it, the market will enter a state of chaotic competition.

As the AA ecosystem continues to grow, fragmentation has become more evident. Several EIP standards now define account abstraction at the framework level, such as ERC-4337, ERC-6900, and ERC-7579. However, there are clear differences in user experience, interface specifications, and behavioral expectations among these different implementations. Most wallet providers focus on similar use cases and core functions but rely on incompatible design assumptions and logic.

One prominent hidden issue is storage disorder.With the introduction of EIP-7702, contract code can utilize the storage space under an EOA, and that space is not exclusively owned by one contract. It may be accessed by multiple smart account providers who swap in and out of that storage.

When a user initiates a re-delegation operation to switch logic contracts, the new contract replaces the old one, but the state data written by the old contract remains in the EOA's storage.

This means that the new contract can read and even modify leftover data, introducing the risk of "storage pollution", which could interfere with or break current logic.

Although the community has proposed solutions such as isolating storage with namespaces (ERC-7201), the ecosystem still lacks strict enforcement of universal rules to guarantee nonce uniqueness and security.

• Another major issue is inconsistency in execution standards.

As highlighted in the article "From Fragmentation to Unity: The Need for Smart Account Standardization",Safe, Biconomy, and ZeroDev have each implemented their own version of batch call functionality. But their function names, interface parameters, and result-handling methods are different. ZeroDev handles failure within batch calls, while Safe and Biconomy do not.

This "each project does its own thing" approach to standards inevitably leads to chaos where users, dApps, and developers all suffer from it.

So the release of EIP-7702 is not just a technical upgrade. It's an opportunity to build a universal smart account infrastructure. It offers a window to restructure consensus and guide the Web3 wallet ecosystem from functional diversity to structural unification, enabling real long-term sustainability.

3 critical safety insights after EIP-7702 activation

Let's now shift perspectives. From the standpoint of users, dApps, exchanges, and organizations, how will this system affect us? It brings opportunity, but also risk. Only by understanding the risks can we fully enjoy the benefits this system offers.

EIP-7702 is complicated. Can I choose not to upgrade?

Of course, you can choose not to proactively upgrade. But there's one risk you should know. After the Prague upgrade, a single message signature might inadvertently expose you to danger.

Indeed, EIP-7702 introduces a strong phishing risk because its Authorization parameters are composed of address, nonce, and chain ID. If the chain ID is set to 0, then the signature authorization may become valid on any chain, as long as the nonce is satisfied.

According to the specific implementation of the 7702 flow in the open-source OKX SDK, to comply with the standard, what users ultimately sign is a hash value: 0xabc, which is calculated as follows:

keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]）

Here, keccak is the mainstream hash algorithm used on Ethereum, known for producing a fixed 32-byte output regardless of input length. RLP is a data encoding scheme, and MAGIC is a fixed constant.

Because the final result is a hash string that's incomprehensible to users, someone could maliciously ask a user to sign it, and then broadcast the authorization on-chain without the user knowing. This could lead to setting code without the user's knowledge, creating a zero-day level attack. Since set code is mandatory, even previously secure contracts can be replaced.

For this reason, secure wallets usually prevent users from signing arbitrary hash values because even hashes might represent valid Ethereum transactions.

What should you do if you accidentally authorize a risky contract?

This risk is common, because no one can be fully sure they won't be phished.

To protect yourself, it's important to understand that Ethereum transactions require nonce sequencing, and only continuous nonces will be accepted by the chain. So there are two possible attack types:

The first case is where a hacker obtains the next nonce of your address and uses it to sign an Authorization. In this case, the solution is simple. Quickly use a wallet that supports custom gas fees, such as OKX Wallet or another secure wallet, and transfer your ETH to a safe address. This both protects your assets and consumes the nonce, making the hacker's authorization invalid.

The second case is where the hacker has an authorization for a future nonce. If you now perform a transfer, it might unintentionally activate the hacker's transaction. Since you don't know the exact nonce, any operation could potentially be unsafe. The only reliable action is to move your assets as quickly as possible.

Doesn't this make EIP-7702 seem more dangerous? Actually, not quite.

In blockchain systems where user sovereignty is tied to private key ownership, signing anything carelessly always comes with risk. But unless a large holder is specifically targeted, most issues arise because users frequently expose their private keys.

If you use AA to set up family accounts and sub-accounts with quotas, your master account only needs to be active when changing system-level settings. Day-to-day usage can be handled by child accounts.

Why do some common transactions fail after upgrading?

This typically happens when using wallets that don't support EIP-7702.

First, a technical background: during contract execution on Ethereum, the system first checks the code field of the sender's address. If code exists, it executes the default fallback function.

As a result, if you've set a logic contract via EIP-7702, any ETH transfer will also trigger contract logic, consuming additional gas. If you set the Gas Limit to 21000 (the minimum), the transaction will fail.

Similarly, many NFT projects check if the recipient address is a black hole (i.e., cannot transfer out). If your fallback logic is flawed, you may not be able to receive ERC-20 or ERC-721 tokens.

To avoid this, use a wallet that clearly supports EIP-7702 or a well-audited logic contract like the one here: https://github.com/okx/wallet-core

What else is included in Ethereum's Pectra upgrade?

Some say Ethereum has lost its way because many upgrades don't seem to impact users. But is that really true? Let's explore the other EIPs in this upgrade. Clearly, EIP-7702 is the biggest change felt by users, but the other 10 EIPs also bring important improvements. First, is cryptographic support. EIP-2537 introduces precompiled operations for the BLS12-381 curve, optimizing BLS signature verification with higher security (120+ bits) and better computation efficiency (gas optimization). The staking landscape also sees several key improvements. Objectively speaking, staking has long needed optimization. Ethereum’s validator set has grown rapidly, now approaching one million staking addresses. This is mainly due to the MAX_EFFECTIVE_BALANCE being capped at 32 ETH, forcing node operators to create multiple validator accounts to manage large staking amounts, resulting in a high number of redundant validators. EIP-7251 addresses this by raising the cap, allowing pooled staking protocols like Lido to reduce the number of control accounts and simplify the system architecture. However, this also risks increasing centralization in the ETH staking market by concentrating more stake into fewer entities. Previously, if you earned 10 extra ETH after staking 32 ETH, you couldn't stake it unless you reached another 32 ETH. Now you can stake 42 ETH directly. This improves user experience and subtly reduces ETH liquidity.

Finally, there are major L2 ecosystem improvements. Ethereum remains committed to L2 scaling. Other ecosystems like SVM and Move-based chains are still focused on building L1s, and L2 plans can sometimes conflict as their performance is not reliant on L2s. EIP-7623 increases calldata gas cost from 4/16 to 10/40 gas per byte to discourage calldata usage and encourage blob usage. EIP-7691 increases blob capacity per block, expanding L2 storage. The Cancun upgrade had blob target and max per block set to 3 and 6. After the Prague upgrade, the values are 6 and 9 respectively. This is an overall expansion. Ethereum improves throughput via L2, but challenges like liquidity fragmentation, complex bridging, and exit capacity remain. Pectra is giving L2s a "highway," but "traffic management" and "toll standardization" are the real issues ahead.

Looking Ahead

The article has traced the roots of Account Abstraction, compared the two major paths represented by ERC-4337 and EIP-7702, explored EIP-7702's mechanisms, and evaluated its impact on mainstream use cases.

"Not your keys, not your money" is a powerful idea. EIP-7702 doesn't undermine it but complements it instead by making sovereignty and usability coexist.

As Ethereum Foundation researcher Yoav Weiss said, "the next billion users won't write 12 words on paper".

Compared to ERC-4337, EIP-7702 offers better flexibility and performance. Once users adopt CA-based account models, complex transaction types will flourish across EVM chains.

We can now glimpse the future.

As base account types and transaction formats diversify, past UX bottlenecks will dissolve. Users no longer need to understand nonce and gas as wallets will abstract it away.

While fragmentation in interfaces and storage may persist, we believe that the more valuable the chaos, the greater the push toward standardization. Decentralized, diverse competition will ultimately drive growth.

So EIP-7702 won't instantly trigger a DeFi explosion. It's a foundational upgrade that may take 2–3 years to mature in apps.From now on, user security will depend heavily on tooling quality. Openness is critical, which is why OKX Wallet has open-sourced its EIP-7702 SDK implementation. Many other wallets are also advancing along the path of open self-custody, giving users full sovereignty.

In the end, the Pectra upgrade reflects Ethereum's consistent long-term vision. Though its roadmap has shifted over the past decade, the core goals remain: a secure, decentralized, scalable, and POS-based green blockchain that is easy to verify.

EIP-7702 and other user-experience-oriented proposals show that Ethereum continues exploring how to stay competitive in a multi-chain world, even against newer chains like Solana, while striving to be the ideal world computer. Reference Materials:

• https://github.com/okx/js-wallet-sdk

• https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md

• https://www.okx.com/zh-hans/learn/smart-account-standardization

• https://mp.weixin.qq.com/s/WjpPNKEVlxlCSz1WyHH4tw

• https://vitalik.eth.limo/general/2024/12/03/wallets.html

• https://metamask.io/news/account-abstraction-past-present-future

About "OKX Research Institute"

The "OKX Research Institute" column offers institution-level insights, focusing on headline-making trends, innovative applications, and cutting-edge developments in the crypto industry. Through data analytics, on-chain behavior analysis, and cross-market correlation studies, it uncovers the core drivers and potential impacts behind market dynamics. The goal is to foster knowledge sharing, idea exchange, and in-depth discussion within the industry, contributing to the healthy growth of the crypto ecosystem.