? Introduction: Solana Big Shots Meeting
Recently, an interesting event occurred in the Solana ecosystem. Key players including the Solana Foundation, Anza, Jito Labs, and others gathered to release a technical roadmap titled "Internet Capital Markets (ICM)." The core idea of this roadmap is "Application Controlled Execution (ACE)," which essentially aims to give on-chain applications millisecond-level control over transaction ordering, creating a decentralized "on-chain Wall Street."
Interestingly, while the entire roadmap does not directly mention Hyperliquid, its design seems to target Hyperliquid's strengths at almost every turn. It's as if Solana is saying: "What Hyperliquid has, we want too, and we want to do it better!"
It's important to note that Hyperliquid has dominated the on-chain perpetual contract market, with trading volume at one point accounting for about 65% of the entire decentralized perpetual market. Clearly, facing such a competitor, Solana is not willing to be surpassed by newcomers, hence the release of this ICM roadmap.
So, what is this "imitation show" all about? Can Solana really catch up to or even surpass Hyperliquid? Today, we will delve into this topic.
? Background and Content of ICM
Who is Leading This Transformation?
First, let's take a look at who formulated this roadmap. The participants are heavyweight players in the Solana ecosystem:
Solana Foundation/Labs: This needs no introduction; Solana's "parent," responsible for overall coordination and core protocol development.
Anza: A development company founded by former members of Solana Labs, somewhat akin to Ethereum's ConsenSys. They undertook many core technical challenges in this roadmap, such as the new consensus protocol Alpenglow.
Jito Labs: A provider of MEV infrastructure on Solana, with significant influence, controlling almost all MEV traffic on Solana. They are leading the provision of transaction ordering solutions like the Block Assembly Marketplace (BAM).
Multicoin Capital: A well-known crypto investment firm and an early supporter of Solana. With substantial holdings in SOL and ecosystem projects, they have considerable say in technical directions.
DoubleZero: A team focused on accelerating network communication, providing dedicated fiber network solutions to enhance communication speed between Solana validators.
Drift: A leading perpetual contract DEX project on Solana. Previously, Drift used an off-chain matching model, which struggled against the fully on-chain Hyperliquid, and their participation in the roadmap formulation clearly aims to leverage underlying upgrades to turn the tide.
Core Issues to Address
The roadmap focuses on improving the market microstructure, which essentially means that the current on-chain trading mechanism is not friendly enough to market makers, with Takers (those who actively initiate trades) benefiting while Market Makers (those who place orders and wait for them to be filled) suffer. This is because Takers often have the latest information and proactively increase transaction fees to ensure their trades are executed first, while Makers often cannot cancel their orders in time and are forced to execute at unfavorable prices.
Some high-frequency arbitrageurs exploit this asymmetry to launch "toxic flow" attacks. For example, when the on-chain price has not yet updated but the off-chain price has changed, arbitrageurs can execute trades at the old price, causing losses for market makers. The result is that Makers, to protect themselves, either widen the bid-ask spread or reduce their order volume, leading to decreased market liquidity.
The ICM roadmap aims to balance this situation and attract high-quality liquidity back to the chain.
Three Steps of ICM
Solana has divided this grand plan into three phases:
Short-term (1-3 months): Mainly optimizing the existing on-chain trading experience, making order book applications more user-friendly, and reducing malicious MEV interference. Specifics include:
Launching Jito Labs' Block Assembly Marketplace (BAM) module on the mainnet. This module serves as a temporary external system to provide Solana's smart contracts with autonomous transaction ordering rights before the ultimate ACE (Application Controlled Execution) is launched.
The Anza team optimizing the success rate of "trades entering the same Slot" to reduce slippage and MEV losses.
These improvements are expected to roll out between July and September 2025.
Medium-term (3-9 months): Introducing dedicated high-speed networks and a new consensus to significantly reduce latency and increase throughput:
Deploying DoubleZero's dedicated fiber network to provide validators with near-zero jitter and reduce latency by up to 100ms.
Launching the Alpenglow consensus protocol, compressing the final confirmation time from about 12.8 seconds to approximately 0.15 seconds.
Developing Asynchronous Program Execution (APE) to reduce transaction execution blocking on consensus.
Long-term (9-30 months): A revolutionary upgrade to Solana's core architecture, aiming for implementation around 2027:
Multiple Concurrent Leaders (MCL): Allowing multiple validators to propose transactions simultaneously within their respective pipelines, then merging and ordering these parallel blocks based on priority fees. This weakens the monopoly of a single packager and enhances censorship resistance.
Native Application Controlled Execution (ACE) functionality: Truly empowering on-chain smart contracts with control over the order of transaction execution.
From this analysis, I believe the story behind the proposal of the ICM roadmap is as follows: The established DEX Drift on Solana has been surpassed by the newcomer Hyperliquid, which offers an excellent experience akin to "on-chain Binance." Drift, unable to compete, sought help from "big shots" like Solana Labs, Anza, and Jito. The "big shots" proposed the ICM technical transformation plan, claiming they would replicate and equip Drift with Hyperliquid's core capabilities to help it re-enter the DEX market. However, they also stated that this technical transformation is extremely challenging, thus dividing the technical plan into a three-step strategy, with the only equipment available to Drift in the short term being Jito's BAM, allowing Drift to make do and compare with Hyperliquid for now.
With the story background clarified, in the following sections, I will analyze in detail which core capabilities of Hyperliquid the ICM has imitated and replicated.
? Imitation One: Transaction Ordering Mechanism
The Problem: As mentioned earlier, the current chain favors Takers, while Makers suffer from "toxic flow." Users who actively take orders can initiate trades on on-chain orders based on the latest off-chain prices, and prioritize execution by increasing transaction fees, while market makers often cannot update or cancel their orders in time. The result is that market makers either widen the spread or withdraw liquidity altogether, worsening market depth.
ICM's Ultimate Solution: Application Controlled Execution (ACE)
The ICM roadmap proposes the concept of ACE (Application Controlled Execution), which decentralizes transaction ordering rights to each on-chain application, allowing applications to decide how to order and execute transactions related to them. For example, in a future Solana with ACE implemented, DeFi contracts could implement the following custom transaction ordering rules:
Oracle Price Update Insertion: DeFi applications can insert a transaction to fetch the latest price from an oracle before matching large trades, ensuring orders are matched at the latest reasonable price and preventing market makers from being arbitraged based on outdated prices.
Priority for Order Cancellation Execution: Applications can set "cancellation requests" to be executed before new "taking trades," giving makers the opportunity to withdraw their orders in unfavorable market conditions.
Tail-End Auction: For instance, if a large buy order pushes the price up, the DeFi application can auction off the opportunity to "follow closely," allowing the trade that offers the most benefits back to the protocol (or users) to execute right after the large order. DeFi applications can return auction proceeds to users, thus converting toxic MEV flow into positive income.
JITO's BAM: Transitional Solution
Before ACE officially launches, Jito Labs has introduced a transitional solution called Block Assembly Marketplace (BAM). The workflow of BAM is as follows:
Users send transactions to a node running BAM software (rather than directly to the current Leader).
BAM nodes collect local transactions and run various plugins to reorder the transaction bundle under privacy protection (plugins run in a secure TEE environment, hiding transaction content from the outside before execution). Through plugins, application developers can customize various ordering rules for their contracts, such as prioritizing cancellations, updating oracle prices before matching, or even running complex in-application auctions.
The reordered transaction bundle is then sent to the Solana Leader for packaging on-chain.
BAM can be seen as a testing ground for ACE before it goes on-chain, with functionality very close to the ultimate ACE, except it operates in an independent off-chain network rather than being built into the Solana main chain protocol.
It is worth noting that Jito previously provided infrastructure aimed at MEV extraction (such as the Jito Block Engine), with a business model that created opportunities for arbitrageurs by optimizing transaction ordering and sharing profits. This, to some extent, positioned them as a "spear" against ordinary users and those being arbitraged. However, Jito closed the public mempool feature for arbitrage bots in early 2024 to reduce negative externalities like sandwich attacks. This move indicates that the Solana community leans towards suppressing harmful MEV and maintaining fairness for users.
The launch of BAM aligns with this idea: it essentially transforms the ordering mechanism originally used for MEV arbitrage into a "shield" to protect liquidity providers like market makers. This includes enforcing cancellation priority to prevent losses for market makers and introducing bidding rebates to reduce front-running profits. Original MEV seekers must now switch roles and write BAM plugins to serve DeFi protocols, profiting from plugin fees.
Learning from HYPERLIQUID
The ACE/BAM concept can be seen as an attempt to catch up with Hyperliquid's on-chain matching mechanism. Hyperliquid is a dedicated chain (Appchain) designed specifically for DEX services. Moreover, the HLP Vault operated by Hyperliquid is actually one of the largest market makers on the platform, making it understandable that Hyperliquid's chain rules are more favorable to liquidity providers. It has already implemented many designs at the chain level to protect market makers, such as:
Priority Protection for Makers: Cancellation requests and maker-only orders are prioritized to avoid unfavorable trades for market makers without their knowledge. The "cancellation priority execution" mentioned in Solana's ACE has been practiced by Hyperliquid for years.
Latest Price Assurance: Hyperliquid emphasizes using the latest feed prices and margin status for "double-checking" during its liquidation and matching processes. For example, when an order is matched, the system will pull the latest oracle price again to assess both parties' margins, ensuring that risks do not arise from price lag. This is similar to ACE inserting oracle update transactions before executing trades.
Self-Trade Protection: If a buy and sell order from the same address meet, Hyperliquid automatically cancels rather than matches them to prevent wash trading or unnecessary fees.
Solana's ICM's ACE/BAM is undoubtedly learning from Hyperliquid. As a leader in on-chain CLOB, Hyperliquid has implemented various mechanisms friendly to market makers using a dedicated chain. Solana now hopes to replicate this effect using a general-purpose chain with modular plugins—allowing each application to have control over transaction ordering similar to Hyperliquid.
⚡ Imitation Two: Instant Finality
Comparison of Existing Consensus
Solana currently uses Tower BFT, where confirmation and finality are probabilistic and progressive: a block is marked as "Confirmed" once it receives 2/3 of the votes, but it requires the accumulation of about 32 subsequent blocks on-chain (usually around 13 seconds) to be anchored as "Finalized." For certain applications (like high-frequency trading), a final confirmation time of over ten seconds is still too long.
HyperBFT is Hyperliquid's self-developed consensus algorithm, inspired by the HotStuff consensus, which uses a two-round voting process to confirm blocks, achieving "instant finality."
First Round: Prevote: After validators receive the candidate block broadcasted by the Proposer, they perform a quick verification. If the verification passes, each validator casts a "Prevote" and broadcasts it to the network. This vote represents: "I have preliminarily reviewed this block, and it seems fine."
Second Round: Precommit: Once a validator collects Prevotes from more than two-thirds of validators for the same candidate block, it gains enough confidence that the majority of the network members recognize this block. Therefore, the validator casts a more substantial "Precommit" vote and broadcasts it. This vote represents: "I see that the majority of the network agrees, and I am ready to officially write this block into the ledger."
When a validator collects Precommit votes from more than two-thirds of validators for the same candidate block, consensus is reached! The block is considered Finalized. It will be permanently and irreversibly added to the blockchain.
This means that every block in Hyperliquid is a final block, with no possibility of forks or rollbacks, resulting in extremely low block production delays—officially disclosed average confirmation delays are about 0.2 seconds, and in 99% of cases, it does not exceed 0.9 seconds. This millisecond-level finality is ideal for high-frequency trading, as once a trade is initiated, it can be quickly confirmed and cannot be reorganized, greatly enhancing capital efficiency.
ALPENGLOW Achieving Instant Finality
Alpenglow is a new consensus protocol that Solana plans to launch, aiming to accelerate block final confirmation to 1-2 slots (about 150ms), achieving instant finality similar to HyperBFT. In Alpenglow, the component responsible for consensus instead of Tower BFT is called Votor, which is a dual-track voting system:
Fast Track: If in the first round of voting for a block, more than or equal to 80% of the network's "stake" (which can be understood as the voting weight represented by the amount of SOL tokens staked by validators) votes to agree that the block is valid, then this block will be immediately confirmed as "Finalized."
Slow Track: If the agreeing stake in the first round of voting does not reach 80%, but is more than or equal to 60%, Votor will initiate a second round of voting. If the proportion of agreeing stake remains at 60% or above after the second round of voting, then this block will also be finally confirmed.
Votor essentially states: "We default to confirming after one round of voting, but if the conditions are not perfect, we will initiate a two-round voting process almost identical to HyperBFT as insurance," which is essentially an imitation of Hyperliquid's voting mechanism.
The Cost and Countermeasures of Instant Finality
Hyperliquid's ability to conduct two rounds of voting has an important prerequisite: it uses a very streamlined set of validators, initially controlled by fewer than five entities that managed the majority of validation nodes. A smaller network can significantly reduce the communication overhead of BFT consensus.
However, if the number of nodes expands to dozens or hundreds, the complexity of the voting process will quickly increase, because the complexity of each round of voting is proportional to the square of the number of participating nodes in communication. Solana has thousands of validation nodes, and achieving two-round voting while maintaining a high degree of decentralization presents a technical challenge far beyond that of Hyperliquid. Therefore, Solana needs to do a lot of work on network communication. The roadmap mentions several measures:
Alpenglow also includes a Rotor component, which replaces the old data distribution protocol Turbine. Unlike Turbine, which requires multiple levels of relays, Rotor uses a "single-hop relay" model, allowing data blocks to reach target validators more quickly, significantly reducing transmission delays. Additionally, under the current Turbine mechanism, nodes' positions in the data distribution tree are primarily sorted by stake weight, with nodes having more stake arranged at higher levels to receive data shards (shreds) first, but this also requires them to undertake more downstream forwarding tasks, consuming more bandwidth. The assumption behind this design is that nodes with more stake are often "wealthy" and presumably have stronger hardware and more bandwidth resources. Rotor updates this logic by no longer relying solely on stake size but instead comprehensively considering each node's actual bandwidth and communication performance. Nodes that perform better in real-time network performance will be dynamically assigned to key positions, thus intelligently planning the optimal data propagation path for the entire network, achieving fast and stable "express" service.
The DoubleZero high-speed network is based on dedicated fiber networks and multicast technology, providing low-latency communication that is an order of magnitude faster than public internet. This reduces the delays and jitters of messages traveling back and forth between geographically dispersed nodes, solidifying the physical network foundation for rapid consensus.
Even so, achieving both "high decentralization and millisecond-level finality" remains a significant challenge for Solana. This is also why Alpenglow is expected to require more than a year of development, with an anticipated launch in early 2026 (one can only hope).
? Imitation Three: Asynchronous Execution Pipeline
HYPERLIQUID's Asynchronous Pipeline
Traditional blockchains are single-threaded; a block must be fully executed and verified before the next block can begin processing. The purpose of this approach is to eliminate the uncertainty introduced by multithreading, ensuring that all nodes receive the same results in the exact same order. However, the downside is that it limits the performance of modern multi-core CPUs.
Hyperliquid, on the other hand, breaks from tradition by introducing multithreading, decoupling the workflow into two parallel pipelines: "ordering (consensus)" and "execution." The execution process is as follows:
Time Point T1:
- Consensus Pipeline: Validators reach consensus on the transaction content and order of block N-1.
Time Point T2 (the magic begins here):
Consensus Pipeline: Begins processing block N. It packages and orders transactions from the network and votes on this order to reach consensus. It is completely unconcerned with the execution results of block N-1.
Execution Pipeline: Takes the block N-1 that has already reached consensus at time T1 and begins executing its transactions.
Time Point T3 (the pipeline continues to run):
Consensus Pipeline: Completes consensus on block N and passes the consensus result (an ordered list of transactions) to the execution pipeline. Then, it immediately starts processing block N+1.
Execution Pipeline: Completes the execution of block N-1 and confirms the state. It then seamlessly transitions to block N, which has just been completed by the consensus pipeline, and begins executing its transactions.
In this Pipeline model, different CPU cores can be effectively utilized. Some cores can be dedicated to handling network messages and consensus voting (ordering), while others can focus entirely on state computation (execution), allowing both pipelines to operate simultaneously and maximizing hardware efficiency.
ICM's APE Solution
Asynchronous Program Execution (APE) is a crucial part of the ICM roadmap, aiming to replicate Hyperliquid's asynchronous dual-pipeline solution to completely remove the current constraints of "consensus -> execution -> broadcasting." APE will allow transaction execution to be decoupled from the critical path of block confirmation, enabling validators to confirm transactions entering blocks first and then execute program calculations asynchronously, thereby reducing the latency of transactions on-chain.
However, achieving secure parallel/asynchronous execution on a decentralized chain is inherently a highly challenging engineering task: to ensure that all nodes globally reach complete agreement on transaction results, any factors that could lead to different execution orders producing different results must be eliminated.
The success of the asynchronous pipeline solution in Hyperliquid is largely due to Hyperliquid being a single-function appchain with a simple and clear state model (mainly the order books of various trading markets and user positions). The development team can clearly delineate which operations can be parallelized and which have dependencies, allowing for the design of an efficient pipeline.
However, as a general-purpose chain, Solana's dependencies in transactions are far more complex than a simple order book system. Therefore, reproducing Hyperliquid's performance in a general environment presents a much more daunting engineering challenge for Solana, requiring the redevelopment of a significant amount of code, which cannot be achieved in the short term. Thus, it can only be categorized as a mid-term plan in the ICM roadmap. Even so, launching APE will still require overcoming a series of challenges:
Extreme Code Complexity: Enabling asynchronous parallel execution in a distributed system necessitates extensive underlying modifications. Once multithreading is introduced, the software complexity of Solana's validator node clients will increase exponentially, along with the risk of unknown bugs. A single mishandled race condition could lead to consensus errors, resulting in catastrophic outcomes.
Increased Hardware Requirements: Parallel execution demands powerful multi-core CPUs and more memory to run multiple execution threads simultaneously, maintaining various temporary states and rollback points. The entry threshold for Solana nodes is already high, and further increases could impact network decentralization.
Worst-Case Handling: The worst-case scenario for parallel execution is when a large number of transactions contend for the same state. For instance, if certain popular contracts (like popular DEXs or flash sale contracts) cause all transactions to read and write to the same account, the parallel scheduler will continuously check for conflicts, roll back, and replay, potentially making it slower than serial execution. How to gracefully degrade in the worst-case scenario without allowing the system to fall into livelock or performance cliffs is a significant architectural challenge.
Development and Audit Difficulty: Verifying safety under asynchronous, multithreaded conditions is extremely challenging. The Solana community will need to invest additional resources to audit the new execution model to prevent consensus vulnerabilities from being maliciously exploited.
? Will This Imitation Show Succeed?
In summary, the Solana ICM roadmap is essentially a deep "imitation show" of Hyperliquid's technical architecture. The core team of Solana plans to replicate Hyperliquid's key capabilities one by one and equip them to Drift, helping it compete with Hyperliquid in the DEX market. However, the author is not optimistic about the prospects of this imitation show.
Exponential Increase in Technical Difficulty
Hyperliquid's success is largely built on its favorable inherent conditions:
As a dedicated chain, it can optimize consensus and execution around a single application, without needing to accommodate various different smart contract requirements in its design.
As an emerging chain, it can even sacrifice a certain degree of decentralization for performance (initial validators were controlled by the team, and most users tacitly accepted this).
In contrast, Solana faces an exponential increase in technical difficulty to achieve Hyperliquid's level while maintaining the universality and decentralization of a public chain. For example, Hyperliquid's HyperBFT consensus can achieve a 0.2-second delay with fewer than five nodes, while Solana would need to push the limits of network communication to achieve the same delay with 2000 nodes; Hyperliquid's matching engine only serves its own exchange logic, while Solana's ACE/BAM must adapt to a myriad of DeFi protocols.
It can be said that Solana is taking a class on Hyperliquid, and the difficulty of the course is "unknown to what extent higher than what Hyperliquid initially experienced." The ICM roadmap breaks these tasks down to 2027, indicating that the officials are well aware that this is not a one-day effort.
The Conflict Between Decentralization and Efficiency
Another distinction between Solana and Hyperliquid lies in governance and upgrade pace. The Hyperliquid team is small, with centralized decision-making and no external governance checks, allowing for rapid action. In March of this year, when Hyperliquid encountered the JELLY contract manipulation incident, the team promptly delisted the related markets within hours, protecting fund safety and demonstrating that centralized decision-making, although "politically incorrect," can indeed be effective and useful in critical moments.
In contrast, as a public chain, Solana has a foundation, core developers, and community interests at play, resulting in a relatively slow and conservative upgrade process. For instance, the highly anticipated Firedancer (a high-performance Solana client developed by Jump) has been in testing since its launch in 2022 and is still not fully online as of mid-2025; any changes involving consensus require long periods of auditing and testnet operation. The changes planned in the ICM roadmap are even more significant: replacing the core consensus algorithm, introducing entirely new parallel execution, and decentralizing key powers, all present increased difficulty and risk. It is foreseeable that over the next two to three years, the Solana team will need to gradually advance these upgrades, with each step potentially encountering unexpected technical challenges or community resistance.
For example, for BAM launched by Jito to truly benefit users, a majority of validators must switch to clients that support BAM. Otherwise, user transactions may sometimes go through BAM and sometimes not, leading to inconsistent experiences and even arbitrage loopholes. The problem is that Solana cannot force validation nodes to upgrade their clients. Therefore, even if BAM is successfully developed, its promotion speed is difficult to predict. Thus, the timeline in the ICM is merely an optimistic plan, and its realization may be delayed repeatedly, with the full achievement of goals uncertain for a long time.
Even if everything goes smoothly and Solana achieves ACE and other features by 2027, it would merely be "catching up"—matching the functionalities that Hyperliquid has already provided in 2023-2024. Moreover, Hyperliquid itself will not stop progressing: for example, the HIP-3 proposal is set to launch in the second half of 2025, allowing the community to independently list perpetual contract markets. Various innovations will further expand Hyperliquid's market coverage. By the time Solana finally achieves the current functionalities of Hyperliquid, Hyperliquid may have already opened up new leading advantages.
Competition Beyond Technology
Although this article primarily compares the technical confrontations between Solana and Hyperliquid, it is also important to recognize that Hyperliquid's success is not solely due to technical factors. Hyperliquid has many commendable aspects in its operations and ecosystem:
For instance, in terms of token economics, Hyperliquid has no VC funding, with over 76% of tokens allocated to the community. The profits earned by the platform can be used to repurchase HYPE tokens, genuinely sharing benefits with users and avoiding the issue of capital parties excessively exploiting users. This has earned Hyperliquid a strong reputation among loyal users.
Additionally, the Hyperliquid team is extremely adept at capturing market demands: when NFTs were hot, they launched an NFT index; when SocialFi was trending, they introduced the FriendTech index; HIP-2 addressed the "cold start difficulties and lack of initial liquidity" for new tokens; Hyperps solved the problem of providing futures trading for assets that have not yet officially launched; and the planned HIP-3 upgrade this year supports any project to issue perpetual contract markets independently. The continuous product innovations and diverse trading categories greatly enhance Hyperliquid's attractiveness as a trading platform—users come here not only for speed but also for unique profit opportunities unavailable elsewhere.
In contrast, Solana's DEX track, such as Drift and other Solana-native DEXs, currently lacks significant advantages in product design and incentive mechanisms. Simply replicating Hyperliquid's technology will only match the chain's performance; without addressing user pain points with distinctive features, it will not automatically lead to a large-scale return of users, as user migration also incurs costs.
Therefore, if Solana merely follows in Hyperliquid's footsteps, it will forever remain behind, eating dust. The true opportunity in the Solana ICM roadmap does not lie in the perpetual contract or order book fields. There are many areas in the Solana ecosystem that Hyperliquid has not yet ventured into, such as MEME launchpads, lending protocols, etc. These areas can also leverage the improvements brought by ICM to create a smoother user experience. If Solana can innovate features in these areas and address user pain points, then even if it cannot immediately regain ground in the perpetual contract market, it can still solidify its vision of becoming an "internet capital market." After all, no matter how strong Hyperliquid is, it is merely a vertical App chain, while Solana has a vast and diverse application landscape, which is its greatest long-term asset.
? Conclusion: Imitation is Easy, Surpassing is Difficult
The Solana ICM roadmap demonstrates the Solana community's determination to not be outdone and to catch up. From ACE to Alpenglow to APE, each corresponds to a distinctive feature of Hyperliquid, indeed reflecting a sense of "targeted imitation."
However, imitation is easy, surpassing is difficult. For Solana to successfully perform this imitation show, it needs to make comprehensive efforts in technical breakthroughs, ecological collaboration, and market strategies. In the short term, Solana may improve the on-chain trading experience through BAM and partially regain some users. But to truly shake Hyperliquid's leading position may require more time and further innovations.
At least for now, Hyperliquid continues to expand its territory based on its market share advantage, while Solana is still in the process of accelerating its engine transformation, and this transformation process is likely to take a considerable amount of time.
The future depicted by the ICM roadmap is promising, but whether it can achieve "overtaking on a curve" remains to be seen. As ordinary users, we can look forward to this competition bringing better on-chain trading experiences—regardless of who ultimately wins, users will be the beneficiaries.
This article is based on publicly available information and analysis and does not constitute investment advice. Cryptocurrency investment carries significant risks; please make cautious decisions and do your own research (DYOR).
If you like this article, feel free to follow, like, and share your support!
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
