Original title: (OKX Research Institute | The 10-Year Evolution Endgame of Account Abstraction, Looking at the Past and Future through EIP-7702)
Original author: shisilu, OKX Research Institute
Pectra is the first major upgrade following Ethereum Dencun, encompassing the Prague execution layer hard fork and Electra consensus layer updates, integrating the most EIPs in history, significantly enhancing validator flexibility, network scalability, and execution efficiency. With the Ethereum mainnet Pectra hard fork expected to officially activate on May 7, 2025, the 'ultimate form' of account abstraction (Account Abstraction) - EIP-7702 - has also officially entered public view!
If there are still any EVM-based Web3 wallets that do not support EIP-7702, then without a doubt, it means they have abandoned the entire Ethereum ecosystem and its users. This is the determination of Vitalik and the Ethereum Foundation, and it is the beginning of Pandora's box being opened! Currently, to support the Ethereum ecosystem, OKX Wallet has taken the lead in supporting Ethereum's latest account abstraction standard EIP-7702 and has opened the official entrance for users willing to try it out. You can upgrade through the 【OKX Wallet Homepage function area - More - 7702 upgrade】 to experience the secure and professional EIP-7702. A kind reminder: users can choose to upgrade and experience as needed; not upgrading will not affect the normal use of existing ecology and applications. To ensure asset safety, please operate through official channels and beware of phishing links and malicious websites to avoid asset risks.
Please follow this article to fully understand the evolution history of account abstraction, the user value and market changes brought by EIP-7702, and the hidden dangers within.
Overview
The code involved in this article is located at okx/js-wallet-sdk, and the EIP-7702 SDK implementation used by OKX Wallet is open source to the community.
· EIP-7702 introduces a new type of transaction that allows a regular EOA to set a particular contract address as its logical proxy contract.
· EIP-7702 will fully inherit and surpass the ecosystem built over many years by ERC-4337 due to its 'cost advantages' and 'flexibility.'
· EIP-7702 presents hidden risks for ordinary users; even if users do not upgrade, specific scenarios may still lead to transaction failures or security risks.
· EIP-7702 will bring a whole new user experience. When the user entity undergoes contract migration, market applications will evolve accordingly. Gas abstraction, family hierarchical accounts, and other long-awaited smooth experiences will lead billions of users to enter the Web3 world at low costs.
For trading platforms and DApps, applying the features of EIP-7702 will bring over 50% cost reduction, fully embracing the era of contract accounts.
Why is account abstraction necessary?
It is hard to imagine that the vision of account abstraction might predate Ethereum itself.
During this HK Web3 Carnival, Vitalik repeatedly emphasized that through a series of solutions such as multi-sign (Multi-sig), account abstraction, ZK Email, etc., Ethereum has completed 50% of its 'iPhone moment' goal.
Is it fast or slow, optimistic or limited? Let's delve into the underlying reasons for AA's influence! After all, after a decade of running, Vitalik has finally welcomed the endgame in the AA field he has longed for, adding a significant stroke to Ethereum's roadmap for 2023.
What is account abstraction really for?
In essence, it resolves the issue of property rights separation because currently, the ownership and signing authority of EOAs (Externally Owned Accounts) are held by the same entity (both rely on private keys for any instruction control). Its root comes from Ethereum's transaction structure, where there is actually no From party in Ethereum's standard transactions; execution is determined by reversing the VRS parameters (i.e., user signature) to derive the From address.
Moreover, as Ethereum is designed as a 'world-class state machine,' it completely relies on transactions to achieve changes in on-chain states. Combined with the inability to specify the From party, the execution authority of transactions is coupled with the highest ownership.
This is the root of a series of issues with EOAs, although they are simple and understandable, but inconvenient to use:
· Private keys are hard to protect: losing your private key (due to loss, hacking, quantum cracking) means losing all assets.
· Fewer signature algorithms lead to different performance losses and costs of on-chain storage.
· High signature permissions, EOA's native private keys hold all this power.
· The transaction fees for complex transactions are high, and fees can only be paid in ETH; any transaction, single operation requires at least 21,000 in base fees.
· Transactions lack privacy; even though there was a confidential ERC-20 protocol proposed by Circle, it did not become mainstream.
Ultimately, the current blockchain world is too complex for users entering and exiting; users need to understand concepts like Gas price, Gas limit, transaction blocking (Nonce order), and hiding complex information from regular users is the problem EIP-7702 ultimately aims to solve.
What are the core differences between ERC-4337 and EIP-7702?
There are actually more than ten different proposals centered around AA, which I have explored previously. Overall, it can be summarized as two main routes:
Route One: Let EOA addresses drive CA addresses.
ERC-4337 is a typical case in this aspect. In summary, it proposes a new transaction object UserOperation, which users send to the memory pool in batches as bundlers, packaging instructions collectively and executing transaction operations through delivered contracts. Essentially, it pulls the underlying transaction and account operations to be executed at the contract level.
The execution principle is as follows:
Through the role of the bundler, this plan can solve issues like batch transactions, gas-free transactions, and fewer signature algorithms. However, it cannot solve the complexity and user transaction costs, as well as the single point of failure risks of bundlers and EntryPoints.
Because once users migrate to ERC-4337, even if the requirement is just to make a Transfer transaction like user2 in the diagram, the user's transaction fees will double compared to an EOA.
From the latest user data of CA and EOA, it can be seen that even if some users are high-end players who heavily rely on various operations with CA as the on-chain entity, batch calls, etc., if so, why not directly use ordinary CAs?
Due to the design of the bundler, it allows avoiding hard fork level upgrades and launching directly at the application level, but ERC-4337 also brings doubled costs and single-point failure risks, and users lose the original flexibility of EOAs. Therefore, facing diverse user needs, the current market users do not seem to favor the ERC-4337 solution, which has shown a significant downward trend over the two years of development, even if peak user numbers are far from Ethereum's 300M independent addresses.
Of course, we are not blaming ERC-4337 for its shortcomings, but rather recognizing that as it develops, roles and concepts such as Paymaster and gas abstraction have also been reapplied in EIP-7702.
I believe that any industry's development will not happen overnight; the important thing is to discover patterns and summarize experiences from past ups and downs.
Route Two: Make EOA addresses into CA addresses
In fact, as early as November 2015, Vitalik proposed EIP-101, which introduced a new structure for accounts as contracts. It changed addresses to consist only of code and storage space, altered fee support to be paid by ERC20, and used pre-compiled contracts to change native tokens to ERC20-like for balance storage (could have functions like authorized deduction). In January 2018, there was proposal EIP-859, whose core function was to deploy contract wallets using the code parameter attached to the transaction if the counterparty's contract was not deployed. Finally, from the scheme of EIP-3074, the further derived EIP-7702 was eventually incorporated into the Ethereum mainnet!
The concepts and effects of EIP-7702 are quite simple. It completes initialization through a new type of transaction, allowing users to temporarily and optionally grant EOA smart contract functions in a single transaction, thus supporting bulk transactions, gasless transactions, and customized permission management. The most critical capability is that it provides users with temporary and optional space.
Moreover, multiple users can share the same logical contract, significantly reducing the user's migration costs. Users need only 80,000 Gas to complete the setup of EIP-7702, approximately $0.06, and to set up a new contract or cancel the logic contract, only 40,000 Gas is needed.
After completing the setup, it will significantly optimize gas in bulk transactions for users, see the table:
Of course, you might feel, is it necessary to perform two, or even six token transfers?
Ordinary users have become accustomed to doing one thing per transaction, seemingly few scenarios, but in diversified application scenarios like Web3 Game, Web3 Pay, such situations often occur. For example, simultaneously consuming copper coins (in-game currency) and silver coins (user recharge currency) or participating in an event while consuming NFT tickets and entrance fees.
Even if we do not imagine complex scenarios, returning to the current mainstream on-chain Swap needs, there are also demands for approval and bulk transfers. Moreover, nowadays, a small tool can be made to quickly help users delete their already useless approval authorizations. The effects can be easily compared, and it is evident that costs can be directly reduced by about 40%.
The core principle of EIP-7702
To explore why such effects arise, we must return to its principles, which essentially consist of two logics, divided into the user setting phase and the daily usage phase.
Setting the logical contract phase
The core process is as follows:
The first step: signing authorization. Using the private key of the original EOA, sign a special hash string, the content of which is encoded from chain_id, address, and nonce. Here, the Address is the final logical contract address to be set, and the Nonce is a strategy to ensure the transaction is not replayed.
The second step: Sign the transaction. With the authorization information from the first step, anyone can construct a type 4 transaction, which can contain multiple authorization pieces, to authorize multiple addresses in one go.
The third step: Broadcasting on-chain. Therefore, when the internal Authorization of the transaction is processed, the logical contract is already effective.
There are more technical details that can be referenced in the implementation of the okx open source js sdk to see the process of underlying data encoding. Of course, this solution also hides some security risks and complexities, which we will discuss in detail later.
Executing logical contract phase
When you complete the setup, whenever any transaction's To address points to you, it will be like calling a smart contract; the system will 'load' the code of the logical contract you originally set into the current EOA's state to execute its logic.
Similarly, we can check using two scenarios:
The first type is calling yourself.
If you set up a highly secure and customizable contract like the OKX 7702 Smart Contract, you can specify pre-written calldata to allow your current operation to complete multiple instructions at once. For example, you can complete Approve + Transfer simultaneously or Approve + Swap.
Don't underestimate it. Among the total of 2.7 billion Ethereum transactions, Approvals account for about 75 million transactions. Based on each transaction requiring 80,000 Gas, that results in 460,000 ETH consumed. Based on the market price of ETH at $1700, that is nearly $800 million.
The second type is when someone else calls you.
Previously, Ethereum did not have situations where others could call EOA addresses, but now you are a universal contract, fully customizable. You can create sub-accounts with divided permissions or set up whitelists for specific accounts to authorize DApps to initiate transactions on your behalf, completely eliminating the need for repeated signature prompts in traditional blockchain applications.
What a powerful capability! This is also why almost all mainstream wallets, including OKX Wallet, Metamask, WalletConnect, Biconomy, BaseWallet, Rhinestone, ZeroDev, TrustWallet, Safe, and related teams are quickly responding and supporting it.
Is EIP-7702 the ultimate form of account abstraction?
Yes, because this time the user will choose him!
It's not that EOAs are not good; objectively speaking, EOAs are simple and clear, and safe. However, after the Prague upgrade, the EOA introduced with EIP-7702 will be better. Because of cost and experience. When Jobs pulled the iPhone out of his jeans pocket, those experiences were things users initially never thought they could play with.
Account abstraction is a field that many chains are exploring and actively trying out. For example:
· Starknet, as a ZK-Rollup (Layer 2), its default accounts are all contract accounts, with no EOAs.
· zkSync Era uses AA accounts as the default method and does not require the cumbersome steps of Bundlers.
· Nervos CKB, similar to UTXO model, but it also allows all accounts to customize validators, separating ownership from control.
· Aptos / Sui, as a significant player in the Move system Layer1, while not an EVM model AA, also possesses account customization capabilities, permissioned modular signatures, multi-verification, etc.
EVM's Linea / Base / Mantle / Polygon / Arbitrum / Optimism and other related ecosystems not only have completed AA support through ERC-4337, but they will also almost certainly follow up with the EIP-7702 upgrade just like the Ethereum mainnet. Meanwhile, the infrastructure related to wallets and AA is more comprehensively laying the groundwork for EIP-7702.
The core experience optimization from EIP-7702 includes: batch transactions, gas abstraction (i.e., gasless solutions), account custody, and similar services that are fully supported by providers like Coinbase, Metamask, Biconomy, Zerodev, Rhinestone, Ithaca, etc.
All of this is further completed through the adaptation from the era of ERC-4337, which is a significant advantage of EIP-7702. Ultimately, the account entity is a form that belongs to both EOA and CA, so a large amount of infrastructure that once surrounded AA can be migrated and adapted.
Now, let's illustrate the final effect layer differences between EOA, ERC-4337, and EIP-7702 with a table.
Objectively speaking, the Ethereum system has a much heavier historical burden than other chains, which is the reason for the recent community voices opposing Vitalik's changes to the EVM virtual machine and also the reason for the early necessity of choosing ERC-4337. However, once there is a better option (EIP-7702) that can achieve compatibility with historical burdens and excellent cost optimization, users will welcome their 'iPhone moment.'
With the transformation of the underlying form, the derived forms can also be further imagined, such as
· Users can use Passkey or Google Account to control their wallets, achieving functions such as conditional signature exemptions.
· Users can implement recovery capabilities through methods like setting ZKEmail, allowing them to retrieve their private keys.
For large on-chain operators, integrating multiple transactions into one can significantly reduce block wait times, allowing on-chain swaps to be faster, and through consecutive transactions, lower the risk of transaction failures. Time has a huge impact on user experience; as the second-ranked consensus system in the entire blockchain world (second only to BTC), ETH cannot casually reduce block time from 3 seconds to 1.5 seconds like BSC to enhance user experience. Therefore, wallet tools based on EIP-7702 will serve as the most important bridge for user experience.
Thus, integrating our previous discussions about its underlying structure, we can say that EIP-7702 is the ultimate form of account abstraction!
However, if we say that in the future, users will fully utilize it, that is not very likely because its application needs caution. Once complex smart contracts are integrated, the security risks that come with them are also significant. Some attack methods can be very subtle. Therefore, after the activation of the Ethereum Prague upgrade on May 7, 2025, what users need the most is a truly secure wallet to safeguard them with technical expertise.
Has the ultimate battle ended?
No.
Indeed, Pectra is the most ambitious upgrade in Ethereum's history, encompassing 11 EIPs, the largest number ever! Moreover, we have seen the numerous benefits of EIP-7702 and made judgments based on the principles and data discussed above. However, it is precisely after user participation in choices that the market will welcome a chaotic battle.
The AA ecosystem has gradually revealed a trend of fragmentation during its continuous development. Among them, frameworks defining account abstraction, such as ERC-4337, ERC-6900, ERC-7579, have emerged. However, there are significant differences in user experience, interface specifications, and behavioral expectations between different implementation solutions. Each wallet implementation focuses on similar application scenarios and limited core functionalities but employs incompatible design assumptions and implementation logic.
A typical hidden problem is the disorder of storage. After the launch of EIP-7702, the storage space under EOA accounts becomes available for contract use, and this storage space is not exclusively held by a single contract but can be switched and used by multiple smart account providers.
When a user initiates the 'switching proxy contract (re-delegation)' operation, the original account contract will be replaced by the new contract. However, the state data written by the old contract will not be cleared and will remain in the storage of that EOA. This means that the new proxy contract can access and even modify the storage data written by the old contract, introducing the risk of 'storage pollution' that may interfere with or disrupt the current contract's execution logic.
Although several proposals have emerged in the community, such as isolating storage through namespaces (ERC-7201) to reduce the impact of storage chaos, regardless of the adopted solution, there is still a lack of mandatory unified standards in the current ecosystem to ensure the uniqueness and security of nonces.
Another typical issue is the disorder of execution standards. As revealed in this article: (From Fragmentation to Unity: The Necessity of Standardizing Smart Accounts)
Currently, Safe, Biconomy, and ZeroDev have each implemented their versions of batch calling functionality, but the naming of functions, interface parameters, and result handling methods among the three are all different. Among them, ZeroDev has considered scenarios where batch calls may fail, while Safe and Biconomy have not addressed such situations.
The industry's standard practice of 'each for themselves' has inevitably led to a chaotic battle. Users, DApps, and developers are all victims in this scenario. Therefore, the introduction of EIP-7702 is not only a technological innovation but also an opportunity to establish a universal infrastructure for smart accounts. It provides us with a window to 'restructure consensus,' pushing the entire Web3 wallet ecosystem from diverse functionalities to structural unity, achieving true sustainable development.
After the activation of EIP-7702, there are three essential security understandings.
Now, let's switch perspectives, looking at it from users, DApps, trading platforms, and other organizations, to comprehensively see how this system affects us; it will bring opportunities but also risks. Only by understanding the risks can we make the most of the benefits this system offers.
Is EIP-7702 very complicated? Can I not upgrade?
Certainly, you can choose not to upgrade actively, but there is a risk you need to know: after the Prague upgrade, your message signature could inadvertently put you in danger.
Indeed, EIP-7702 has a strong phishing risk because its Authorization parameters consist of address, nonce, and chainid. If the chainid is 0, then this signature authorization can also take effect on any chain as long as the nonce condition is met.
Through OKX's open-source signing SDK, we can see the specific implementation of the 7702 process; to comply with this standard, the hash value that users ultimately sign is: 0xabc, calculated as follows:
Among them, keccak is the mainstream hashing algorithm on Ethereum, characterized by being able to produce a fixed 32-byte length result from data of arbitrary length. RLP, on the other hand, is an information encoding method, with the Magic being a fixed value.
However, due to the final result being a hash value that does not make the specific content understandable, if a user rashly signs a message and others can carry your authorization on-chain to take effect, it will unknowingly set code, thus triggering a 0-day level attack incident. Moreover, since setting code is mandatory, you cannot assume that a contract you once set as secure will not be replaced.
Therefore, secure wallets will prohibit users from signing an arbitrary hash value, which was also the case before (because a hash value could also represent a normal transaction).
How to protect yourself if you mistakenly upgrade a risky contract?
This risk is also very common, as it is impossible to ensure that one will not be phished. To protect against this issue, it is essential to know a technical background: in the Ethereum system, transactions need to be processed in nonce order; only by maintaining continuity can they be recognized on-chain. Therefore, there are also two types of attack methods.
The first scenario is that the hacker steals the nonce value from your current address and signs the Authorization. The handling is simple: if you are attacked, please quickly use a wallet that allows custom Gas fees, such as OKX Wallet or other secure wallets, to quickly transfer ETH (to another secure address). This action can transfer funds at the ETH level, while also replacing the effective nonce value, rendering the hacker's authorization ineffective.
The second scenario is that the hacker steals a subsequent nonce value, potentially making your current Transfer inadvertently enable the hacker's Authorization. Since you cannot be sure what the nonce is, no operation can guarantee absolute security. The only option is to quickly transfer assets to protect yourself.
From this perspective, it seems that EIP-7702 is more dangerous? However, that is not the case!
For blockchains, truly returning user sovereignty to systems where users own their private keys means that any random signing can lead to fund loss. However, the key point here is that aside from the situation where large users are targeted for poisoning, most risks arise because users need to frequently hold important private keys.
If you have already implemented the combined functions of a family account and personal sub-accounts through AA, and set available limits for each sub-account, then your main account will only need to be invoked when modifying system-level settings, while regular daily use can be handled by small accounts.
Why have some common transactions failed after the upgrade?
This situation often occurs in wallet tools that do not support EIP-7702.
First, let's provide some technical background: during contract calls on Ethereum, the system first checks the code field of the user's current address. If content exists, it will run its default accepted function to execute the corresponding logic. Based on this, for us ordinary users, the performance will be that if I complete the contract setup of EIP-7702, there will generally be a default acceptance function, so any ordinary ETH Transfer transaction will execute some contract logic, thereby increasing the overall Gas use. If your ordinary transaction sets the Gas Limit to 21,000, it will naturally fail.
Similarly, since many NFT projects will check whether the receiving address is a black hole address (i.e., an address that cannot transfer out assets) to prohibit transactions, if your acceptance function is not handled properly, it may also lead to the inability to accept ERC20 and ERC721 assets, resulting in losses. It is recommended to set up through wallets that explicitly support EIP-7702 or use logically secure contracts that have been well-audited and recognized by users, such as: https://github.com/okx/wallet-core
What other changes are there in the Ethereum mainnet Pectra?
Many voices in the market believe that Ethereum seems to have lost its way? Why do many upgrades not seem to matter to users? Is this really the case? Let's take a look at other EIPs from this upgrade to find answers. Chen Ran, EIP-7702 is the biggest upgrade change that users can feel, but there are another 10 EIPs that bring changes to the Ethereum ecosystem from different dimensions.
First is the support for cryptography. EIP-2537 introduces precompiled operations of the BLS12-381 elliptic curve, which can optimize BLS signature verification and other complex cryptographic operations, providing higher security (120+ bits) and computational efficiency (Gas optimization).
In staking scenarios, there are multiple optimization points. Objectively speaking, staking indeed needs optimization. The Ethereum validator cluster has been growing rapidly, with nearly a million validator staking addresses. This is due to the MAX_EFFECTIVE_BALANCE being capped at 32 ETH, which forces node operators to create multiple validator accounts to manage larger staking assets, leading to a large number of 'redundant validators.' Therefore, EIP-7251 has raised the maximum limit, which for aggregation staking protocols like Lido can reduce the number of control accounts and simplify the system, but this may exacerbate decentralization issues, making the ETH staking market more centralized.
After this upgrade, it will allow larger scale node operators to merge multiple validator accounts while also providing more flexibility for smaller validators, such as increasing yield through compound returns or more flexible staking increments. This is very important because originally after reaching 32 ETH, if you generated an additional 10 ETH in yield, you would not continue to stake ETH because you still needed to reach 32 in order to open a new account. However, after this update, you can directly stake 42 ETH. Clearly, your compound returns can then return to the ETH ecosystem, offering convenience in user experience and hinting at a certain reduction in ETH liquidity.
Finally, there is a significant optimization for the L2 ecosystem. Ethereum is steadfastly walking on the path of the L2 ecosystem community. Other systems like SVM and MOVE are fundamentally still developing their own L1 and are even exploring their L2, which has certain contradictions and conflicts. The root cause is that these chains' high performance is relatively less dependent on developing L2.
To encourage more efficient interactions between L2 and the Ethereum mainnet, EIP-7623 has increased the gas fees for calldata in transactions from 4/16 gas per byte to 10/40 gas, forcing L2 not to use calldata but to use Blob more.
Additionally, through EIP-7691, the capacity of blobs in blocks has been increased to support larger-scale L2 storage. In the previous Cancun upgrade, two core parameters representing blobs, target and max, were used to indicate the target number of blobs per block and the maximum number of blobs per block.
Cancun is 3 and 6; now after Prague, the parameters change to 6 and 9, in short, it means expansion.
Thus, Ethereum aims to improve itself through L2's TPS. Although there are many issues, such as liquidity dispersion, cross-chain complexity, emergency escape capacity, etc. Therefore, in the current Pectra upgrade, Ethereum is adding a 'highway' for L2, but how to solve 'traffic management' and 'different highways' charging standards is the most fundamental issue.
Glimpsing the future
This article runs close to ten thousand words. We started from the root of account abstraction development, went through ERC-4337, and the two routes represented by EIP-7702, then delved into the principles and mechanisms of EIP-7702, analyzing its advantages and disadvantages in mainstream user scenarios and its adjustment effects.
I believe that 'Not your keys, Not your money' is a great concept. EIP-7702 does not overthrow it but complements and improves it from another dimension, allowing it to possess both sovereignty and usability. As Ethereum Foundation researcher Yoav Weiss said, 'The next billion users will not write 12 words on paper.'
By comparing the two, it can be said that it has significant optimizations over ERC-4337, providing users with space and flexibility, thus making it easier to gain user recognition in the subsequent market. Moreover, once users begin to adopt CA as the on-chain entity, complex transaction types will significantly surge on the EVM chain.
Thus, we glimpse the shadows of the future. With the richness of underlying account entities and transaction types, many previously bottlenecked application experience issues will also be resolved, no longer forcing users to understand concepts like Nonce, Gas, etc., but rather having entry service tools like wallets provide simplified processing.
Although facing industry-level diversity brings a certain degree of interface standard and storage space chaos, I also optimistically see that the more valuable the chaos, the more likely it is to carve out a unified standard. Decentralized multi-dimensional games will ultimately promote the development of the industry. Therefore, after the launch of EIP-7702, it will not immediately ignite the ecology on Ethereum, as it is a spiral ascending underlying technical upgrade. Such upgrades often lead market applications by 2-3 years of time, allowing the application layer to gradually ferment.
Moreover, starting from this upgrade, user safety will rely more on the service quality of entry tools. Open-sourcing is an important step in providing users with a sense of security. Therefore, the underlying SDK implementation of EIP-7702 integrated by OKX Wallet is also open-sourced and publicly accepts scrutiny from the community and market. Many wallets that maintain openness are moving further down the path of self-custody, using the fairness of open-source to give users absolute autonomy.
Finally, returning to the Pectra upgrade itself, we can once again see Ethereum's thoughts and insistence on future directions. Today, with the L2 grand strategy entering a stable execution phase, Ethereum's roadmap has undergone many changes in detail over the past decade, but the core goal has surprisingly remained consistent: to have a secure, decentralized, green (POS) blockchain that is highly scalable and easy to verify. Proposals like EIP-7702, which effectively enhance user experience, introduced from hard forks, represent Ethereum's ongoing exploration of how to enhance competitiveness among multiple chains while ensuring decentralization (even in the face of strong competition from new generation public chains like Solana) and how to become the ideal supercomputer!
Reference materials:
1、https://github.com/okx/js-wallet-sdk
2、https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md
3、https://www.okx.com/zh-hans/learn/smart-account-standardization
4、https://mp.weixin.qq.com/s/WjpPNKEVlxlCSz1WyHH4tw
5、https://vitalik.eth.limo/general/2024/12/03/wallets.html
6、https://metamask.io/news/account-abstraction-past-present-future
This article comes from a submission and does not represent the views of BlockBeats.