Author: shisilu
Pectra is the first major upgrade after Ethereum's Dencun, covering the Prague execution layer hard fork and the Electra consensus layer update, integrating a record 11 EIPs, 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—EIP-7702—has also officially entered the public eye!
If there are any EVM-based Web3 wallets that do not support EIP-7702, then without a doubt, it means they are abandoning the entire Ethereum ecosystem and its users. This is the determination of Vitalik and EF, and it marks the beginning of the Pandora's box about to be 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 an official entry for users willing to try it out. Users can upgrade through the 【OKX Wallet homepage feature area - More - 7702 upgrade】 to experience the secure and professional EIP-7702. A friendly reminder: users can choose to upgrade and experience as needed; not upgrading will not affect the normal use of existing ecosystems and applications. To ensure asset security, please operate through official channels and be wary of phishing links and malicious websites to avoid asset risks.
Please follow this article to gain a comprehensive understanding of the evolution of account abstraction, the user value and market changes brought by EIP-7702, as well as the hidden dangers within.
Overview
The code discussed in this article is located at okx/js-wallet-sdk, the EIP-7702 SDK implementation used by OKX Wallet is open-sourced for community partners.
EIP-7702 introduces a new transaction type that allows ordinary EOA to set a specific 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 poses invisible risks to ordinary users; even if users do not upgrade, specific scenarios may lead to transaction failures or security asset loss risks.
EIP-7702 will bring a brand new user experience. As the user entity undergoes contract migration, market applications will evolve accordingly. Long-awaited smooth experiences such as gas abstraction and family-tiered accounts will lead billions of users to enter the Web3 world at low cost.
For exchanges and DApps, applying the features of EIP-7702 will result in over 50% cost reduction, fully embracing the era of contract accounts.
Why Abstract Accounts?
It is hard to imagine that the vision of account abstraction predates Ethereum itself.
During the HK Web3 Carnival, Vitalik repeatedly emphasized that through a series of solutions such as multi-signature (Multi-sig), account abstraction, and ZK Email, Ethereum has achieved 50% of its "iPhone moment" goal.
Is it fast or slow, optimistic or limited? Let us delve into the fundamentals and see why AA has such influence! After all, after a decade-long journey, Vitalik has finally welcomed the conclusion he has longed for in the field of AA, adding a significant stroke to the progress bar of the Ethereum roadmap drawn for 2023.
What is the purpose of account abstraction?
In essence, it addresses the issue of property rights separation, because currently, the ownership and signature rights of EOA (Externally Owned Account) are actually held by the same entity (both rely on private keys to control any instructions). This stems from Ethereum's transaction structure, where there is no From field in standard Ethereum transactions; the From address is derived from the VRS parameters (i.e., user signatures) during execution.
Moreover, as a "world-class state machine," Ethereum's design relies entirely on transactions to achieve on-chain state changes. The inability to specify the From party couples the execution authority of transactions with the highest ownership.
This is the root of a series of issues where EOA, despite being simple and understandable, is inconvenient to use:
Private keys are hard to protect: Losing a private key (due to loss, hacking, or quantum cracking) means losing all assets.
Limited signature algorithms lead to different performance losses and even costs for on-chain storage.
High signature authority: the native private key of EOA holds all these rights.
High fees for complex transactions: fees can only be paid in ETH, and any transaction, even a single operation, requires at least 21,000 in base fees.
No transaction privacy: even though Circle once proposed a confidential ERC-20 protocol, it has 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, and transaction blocking (Nonce order) to hide complex information from regular users, which is the problem EIP-7702 ultimately aims to solve.
What are the core differences between ERC-4337 and EIP-7702?
Around the goal of AA, there are actually more than a dozen different proposals, which I have previously explored. Overall, it can be summarized into two routes:
Route One: Let EOA addresses drive CA addresses
ERC-4337 is a typical example in this regard. In summary, it proposes a new transaction object called UserOperation, which users send to the memory pool. In the form of bundlers, it batches instructions and executes transactions one by one through delivery contracts. Essentially, it pulls the underlying transaction and account operations to the contract layer for execution.
The execution principle is illustrated in the following diagram:
Through the role of the bundler, this solution can address issues such as batch transactions, gas-free transactions, and fewer signature algorithms. However, it does not solve the complexity and user transaction costs, as well as the single point of failure risk of bundler and EntryPoint.
Once users migrate to ERC-4337, even if user2 in the above diagram only wants to make a simple Transfer transaction, the transaction fee for the user will double compared to 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 based on on-chain CA, such as batch calls, why not just use ordinary CA directly?
The design of the bundler allows it to avoid hard fork-level upgrades and launch directly at the application layer, but ERC-4337 also brings doubled cost expenditure single point of failure risks, and users lose the original flexibility of EOA. Therefore, in the face of diverse user needs, it is clear that the current market users are not so fond of the ERC-4337 solution, with a significant downward trend over the past two years. Even at its peak, the number of users is far from Ethereum's 300M independent addresses.
Of course, we are not criticizing the shortcomings of ERC-4337, but rather the roles and concepts developed alongside it, such as Paymaster and gas abstraction, are also re-applied in EIP-7702.
I believe that the development of any industry will not happen overnight; what is important is to discover patterns and summarize experiences from past ups and downs.
Route Two: Let EOA addresses become 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 only contain code and storage space, altered fee support to be paid via ERC20, and allowed native tokens to be treated like ERC20 for balance storage (with features like authorization for deductions). In January 2018, there was also the EIP-859 proposal, which core function was to execute contract wallet deployment using the code parameter attached to the transaction if the trading party's contract was not deployed. Ultimately, EIP-7702 was further derived from the EIP-3074 proposal and incorporated into the Ethereum mainnet!
The concept and effect of EIP-7702 are quite simple; it completes initialization through a new transaction type, allowing EOA to temporarily and optionally possess smart contract functionality in a single transaction, thereby supporting batch transactions, gas-free transactions, and custom 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 cost of user migration. To complete the EIP-7702 setup, users only need 80,000 Gas, approximately $0.06, while setting up a new contract or canceling the logical contract setup only requires 40,000 Gas.
Once the setup is complete, it can significantly optimize gas usage during batch transactions, as shown in the table below:
Of course, you might wonder if it is necessary to perform two or even six Token Transfers?
Ordinary users have become accustomed to doing one thing per transaction, which may seem like there are not many scenarios. However, in diverse application scenarios like Web3 Game and Web3 Pay, such situations frequently arise, such as consuming both copper coins (in-game currency) and silver coins (user-recharged currency) simultaneously. Or participating in an event while consuming both NFT tickets and entry fees.
Even if we do not imagine complex scenarios, returning to the current mainstream on-chain Swap demand, there is also a need for batch approve and transfer. In fact, a small tool can now be created to help users quickly delete their already useless approve authorizations. The effect can be easily compared, and it is evident that costs can be directly reduced by about 40%.
Core Principles of EIP-7702
To explore why there are such effects, we must return to its principles, which are fundamentally based on two logics, divided into user setup phase and daily usage phase.
Setting Up Logical Contracts
The core process is as follows:
Step 1: Signature authorization. Using the private key of the original EOA, sign a special hash string, which is composed of encoded chain_id, address, and nonce. Here, the Address is the address of the logical contract to be set, and the Nonce is a strategy to ensure that the transaction is not replayed.
Step 2: Sign the transaction. With the authorization information from Step 1, anyone can construct a transaction of type 4, which can include multiple authorization information, allowing for batch authorization settings for multiple addresses at once.
Step 3: Broadcast on-chain. When the transaction processes the internal Authorization, the logical contract will already be effective.
There are more technical details that can be referenced in the implementation of 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 Contracts
Once you have completed the setup, when 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 set into the current state of your EOA to execute its logic.
Let’s look at two scenarios:
First, you call yourself.
If you set up a highly secure and customizable contract like the OKX 7702 Smart Contract, you can specify through pre-written calldata to complete multiple instructions in one go. For example, you can complete Approve + Transfer simultaneously, or Approve + Swap at the same time.
Do not underestimate this; among the total of 2.7 billion Ethereum transactions, there are approximately 75 million Approve transactions. Calculating at 80,000 Gas per transaction, that results in 460,000 ETH consumed, which, at a market price of $1,700 per ETH, amounts to nearly $800 million.
Second, others call you.
In the past, there was no situation where others could call an EOA address on Ethereum, but now you are a universal contract, fully customizable. You can create sub-accounts with different permissions, or whitelist a few Paymasters, allowing designated DApp accounts to initiate some transactions on your behalf, completely eliminating the traditional blockchain application scenario where signatures need to be repeatedly prompted.
What a powerful capability! This is also the reason why almost all mainstream wallets: OKX Wallet, Metamask, WalletConnect, Biconomy, BaseWallet, Rhinestone, ZeroDev, TrustWallet, Safe, and related teams are quickly responding to support it.
Is EIP-7702 the ultimate form of account abstraction?
Yes, because this time users will choose it!
It is not that EOA is not good; objectively speaking, EOA is simple and clear, and safe. However, the EOA after the Prague upgrade, which introduces EIP-7702, will be even better. Because of cost and experience. When Jobs pulled the iPhone out of his jeans pocket, those experiences were things users initially did not think could be done this way.
Account abstraction is actually a field that many chains are exploring and actively trying. For example:
Starknet, as a ZK-Rollup (Layer 2), has contract accounts as its default accounts, without EOA.
zkSync Era uses AA accounts as the default method and does not require the complex bundler process.
Nervos CKB, similar to the UTXO model, also allows all accounts to customize their validators, separating ownership and control.
Aptos / Sui, as a significant player in the Move-based Layer 1, although not EVM-mode AA, also has the ability to customize accounts, allowing for modular signatures, multi-verification, etc.
EVM's Linea / Base / Mantle / Polygon / Arbitrum / Optimism ecosystems have not only completed AA support through ERC-4337 but will also follow up with the EIP-7702 upgrade like the Ethereum mainnet.
The infrastructure related to wallets and AA is also more comprehensively paving the way for EIP-7702.
From the core experience optimization of EIP-7702: batch transactions, gas abstraction (i.e., gasless solutions), account custody, services like Coinbase, Metamask, Biconomy, Zerodev, Rhinestone, Ithaca, etc., fully support these.
These are also adaptations completed further 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, allowing a large amount of previously surrounding AA infrastructure to migrate and adapt.
Now, let’s use a table to reflect the final effect layer differences between EOA, ERC-4337, and EIP-7702.
Objectively speaking, the Ethereum system carries a much heavier historical burden than other chains. This is the reason for the recent community voices opposing Vitalik's changes to the EVM virtual machine and also the reason for having to choose ERC-4337 early on. However, once a better choice (EIP-7702) is available 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 experience features like conditional signature exemption.
Users can set up ZKEmail to enable recovery capabilities, allowing for the retrieval of private keys.
For large on-chain operators, integrating multiple transactions into one can significantly reduce block waiting times, making on-chain swaps faster, and through continuous transactions, reduce 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 arbitrarily reduce block time from 3 seconds to 1.5 seconds like BSC to enhance user experience. Therefore, wallet tools based on EIP-7702 are the most important bridge for user experience.
Thus, combining our previous discussions on its underlying aspects, we can say that EIP-7702 is the ultimate form of account abstraction!
However, it is unlikely that all users will fully adopt it in the future, as its application needs to be cautious. Once complex intelligence is integrated, the security risks it brings are not insignificant, and some attack methods can be very subtle. Therefore, after the activation of the Ethereum Prague upgrade on May 7, 2025, what users need most is a truly secure wallet, with technical expertise to safeguard their assets.
Has the final battle ended?
No.
Indeed, Pectra is the most ambitious upgrade Ethereum has seen to date, encompassing 11 EIPs, the highest number in history! We have seen many benefits of EIP-7702, and we have provided judgments based on the principles and data discussed above.
However, it is precisely after user participation and choice that the market will usher in a chaotic battle.
The AA ecosystem is continuously evolving and has gradually shown signs of fragmentation. Among them, the EIPs that define account abstraction from a framework perspective already include interface standards like ERC-4337, ERC-6900, ERC-7579, etc. However, there are significant differences in user experience, interface specifications, and behavioral expectations between different implementation solutions. Different wallet implementation solutions focus on similar application scenarios and limited core functions but adopt incompatible design assumptions and implementation logic.
One of the most typical hidden issues is the disorder of storage.
After the launch of EIP-7702, the storage space under EOA accounts has become usable by contracts, and this storage space is not exclusively occupied by a single contract but can be switched among multiple smart account providers.
When a user initiates a "re-delegation" operation, the original account contract will be replaced by a new contract. However, the state data written by the old contract will not be cleared and will still 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,” which may interfere with or even disrupt the execution logic of the current contract.
Although various solutions have emerged in the community, such as isolating storage through namespaces (ERC-7201) to reduce the impact of storage chaos, 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 own versions of batch calling functionality, but the function names, interface parameters, and result handling methods among the three are all different. Among them, ZeroDev considers the case of batch call failures, while Safe and Biconomy do not handle such scenarios.
The industry’s standard of “each for their own” approach has inevitably led to a chaotic battle. Users, dApps, and developers are all victims in this situation. Therefore, the launch 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 “reconstruct consensus,” promoting the entire Web3 wallet ecosystem from diverse functionalities to structural unity, achieving true sustainable development.
Three Essential Security Understandings After EIP-7702 Activation
Now, let’s switch perspectives and look at this system from the viewpoints of users, dApps, exchanges, and other organizations to understand how it affects us, bringing both opportunities and risks. Only by understanding the risks can we better enjoy the benefits this system brings.
Can I not upgrade EIP-7702 because it’s complicated?
Of course, you can choose not to upgrade actively, but there is a risk you need to be aware of: after the Prague upgrade, a message signature of yours may 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 the signature authorization can be effective on any chain as long as the nonce is satisfied.
Through the specific implementation of the 7702 process in the OKX open-source signature SDK, we can see that to comply with this standard, the user ultimately signs a hash value: 0xabc, calculated as follows:
Here, keccak is the mainstream hashing algorithm on Ethereum, characterized by being able to produce a fixed 32-byte length result from data of any length. RLP is a set of information encoding methods, and the Magic is a fixed value.
However, since the final result is a hash value that does not reveal specific content, if users carelessly sign a message and others can carry your authorization on-chain to take effect, they may unknowingly set code on you, leading to a 0-day level attack event. Moreover, since setting code is mandatory, you cannot assume that a contract you previously set as secure will not be replaced.
Therefore, secure wallets will prohibit users from signing any arbitrary hash value, as this could also represent a regular transaction.
How to protect myself if I mistakenly upgrade a risky contract?
This risk is also quite common, as it is impossible to ensure that one will never be phished.
To guard against this issue, it is essential to understand a technical background: in the Ethereum system, transactions must be processed in nonce order; only by maintaining continuity can they be recognized on-chain.
Thus, there are two types of attack methods.
The first scenario is that a hacker steals the next nonce value of your current address to sign the Authorization. The solution is straightforward: if you are attacked, quickly use a wallet that allows you to customize Gas fees, such as OKX Wallet or another secure wallet, to swiftly transfer ETH (to another secure address of yours). This action can transfer funds at the ETH level and replace the effective nonce value, rendering the hacker's authorization invalid.
The second scenario is that the hacker steals a subsequent nonce value, which may mean that your current Transfer could inadvertently make the hacker's Authorization valid. Since you are uncertain about what the nonce is, any operation cannot guarantee absolute security. You can only quickly transfer assets to protect yourself.
From this perspective, it seems that EIP-7702 is more dangerous? Actually, it is not!
For a blockchain system that truly returns user sovereignty to the ownership of user private keys, any random signature at any time can lead to a loss of funds. However, the key point is that aside from the situation where large users are specifically targeted for poisoning, most risks arise because users frequently need to use their important private keys.
If you have already implemented a family account and personal sub-account functionality through AA, and set usable limits for each sub-account, then your main account will only need to be activated when modifying system-level settings, while routine 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 a technical background: during contract calls on Ethereum, the system first checks the code field of the user’s current address. If there is content, it will execute the corresponding logic by going through its default accepted function.
Based on this, for ordinary users, if I complete the EIP-7702 contract setup, it will generally have the functionality of a default accepted function. Therefore, any ordinary ETH Transfer transaction will execute some contract logic, increasing overall Gas usage. If you set the Gas Limit for a regular transaction to 21,000, it will naturally fail.
Similarly, many NFT projects check whether the receiving address is a black hole address (i.e., an address that cannot transfer out assets) to prohibit transactions. Therefore, if your accepted function is not handled properly, it may lead to the inability to accept ERC20 and ERC721 assets, resulting in losses.
To address this, it is recommended to set up using wallets that explicitly support EIP-7702 or use well-audited and user-approved logical contracts, such as: https://github.com/okx/wallet-core
What other changes does the Ethereum mainnet Pectra have?
There are many voices in the market suggesting that Ethereum seems to have lost its way. Why do many upgrades not seem to matter to users? Is it really the case? Let’s take a look at other EIPs from this upgrade to find answers. Indeed, EIP-7702 is the most significant upgrade change that users can feel, but there are also 10 other EIPs that bring changes to the Ethereum ecosystem from different dimensions.
First, in terms of cryptographic support. Through EIP-2537, the precompiled operation of the BLS12-381 elliptic curve has been introduced, optimizing complex cryptographic operations such as BLS signature verification, providing higher security (120+ bit security) and computational efficiency (Gas optimization).
There are also multiple optimization points in the staking scenario. Objectively speaking, staking does need optimization. The validator cluster of Ethereum has been growing rapidly, with nearly a million validator staking addresses. This is due to the MAXEFFECTIVEBALANCE being limited to 32 ETH, requiring 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, allowing aggregation staking protocols like Lido to reduce the number of controlling accounts and decrease system complexity, but this may exacerbate decentralization issues, making the ETH staking market more centralized.
After this upgrade, larger-scale node operators can merge multiple validator accounts while providing more flexibility for smaller validators, such as accumulating through compound interest or more flexible staking increments to increase returns. This is very important; originally, after reaching 32 ETH, if you generated 10 ETH in profits, you would not continue to stake ETH because you would need to gather up to 32 ETH to open a new account. However, after this update, you can directly stake 42 ETH. Thus, your compound interest returns can return to the ETH system, providing user experience convenience and hinting at a reduction in ETH liquidity.
Finally, there is a significant optimization for the L2 ecosystem. Ethereum has consistently walked the path of the L2 ecosystem community. Other SVM and MOVE systems are essentially still developing their own L1 and even exploring L2 on top of it, which creates certain contradictions and conflicts. The root cause is that the high performance of these chains 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 directly from 4/16 gas per byte to 10/40 gas, compelling L2 to avoid using calldata and instead utilize Blob more.
Additionally, EIP-7691 has increased the capacity of blobs in blocks, thereby supporting larger-scale L2 storage space. In the previous Cancun upgrade, there were two core parameters representing blobs: target and max, which indicate the target number of blobs per block and the maximum number of blobs per block, respectively.
In Cancun, these were 3 and 6; now after Prague, the parameters have changed to 6 and 9, essentially expanding capacity.
Thus, Ethereum aims to enhance itself through the TPS of L2. Although there are many issues, such as liquidity dispersion, cross-chain complexity, and emergency escape capacity, the current Pectra upgrade is about Ethereum adding a "highway" for L2, but the fundamental issue remains how to solve "traffic management" and "different toll standards."
A Glimpse into the Future
This article has nearly ten thousand words, starting from the roots of account abstraction development, to the two paths represented by ERC-4337 and EIP-7702 and their comparison, then delving into the principles and mechanisms of EIP-7702, analyzing its advantages and disadvantages in mainstream user scenarios and its adjustment effects.
The author believes that “Not your keys, Not your money” is a great concept. EIP-7702 does not subvert it but rather complements and perfects it from another dimension, allowing for both sovereignty and usability. As Ethereum Foundation researcher Yoav Weiss stated, “The next billion users won’t write 12 words on paper.”
Through the comparison of the two, it can be said that EIP-7702 significantly optimizes ERC-4337, providing users with space and flexibility, making it easier for users to recognize and use it in the subsequent market. Once users start adopting CA as the on-chain entity, complex transaction types will emerge in large numbers on EVM chains.
Thus, we glimpse the shadow 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 the logic of Nonce, Gas, etc., but instead providing simplified processing through wallet and other entry service tools.
Although facing industry-level diversity, which brings a certain degree of interface standardization and storage space chaos, the author is also optimistic that the more valuable the chaos, the more likely a unified standard will emerge. Decentralized multi-faceted competition will ultimately promote industry development. Therefore, after the launch of EIP-7702, it will not immediately ignite the ecosystem on Ethereum, as it is a spiral upgrade of the technical underlying layer. Such upgrades often precede market applications by 2-3 years, allowing time for the application layer to gradually ferment.
Moreover, starting from this upgrade, user security will increasingly depend on the service quality of entry tool layers. Open-source and openness are important steps in providing users with a sense of security. Therefore, the EIP-7702 underlying SDK implementation integrated by OKX Wallet is also open-source, publicly accepting community and market scrutiny. Many wallets that maintain openness are moving further along the path of self-custody, granting users absolute autonomy through the fairness of open-source.
Finally, returning to the Pectra upgrade itself, we can once again see Ethereum's thoughts and persistence regarding future directions. Now that the L2 strategy has entered 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 and decentralized green (POS) blockchain that is both highly scalable and easy to verify. The effective AA proposals, such as EIP-7702, that 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 competition from strong new-generation public chains like Solana) and how to become the ideal supercomputer!
References:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md
https://www.okx.com/zh-hans/learn/smart-account-standardization
https://metamask.io/news/account-abstraction-past-present-future
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
