Sharp commentary on Solana's "Internet Capital Market" roadmap: A "copycat show" chasing Hyperliquid.

🚀 Introduction: SOLANA pros are having a meeting

Recently, something very interesting happened in the Solana ecosystem. A group of pros, including the Solana Foundation, Anza, Jito Labs, and others, gathered together to release a technical roadmap titled “Internet Capital Markets(Internet Capital Markets, ICM)”. The core concept of this roadmap is “Application Controlled Execution(Application Controlled Execution, ACE)”, which simply means allowing on-chain applications to have millisecond-level autonomous trading priority, creating a decentralized “on-chain Wall Street”.

Interestingly, upon reading through the entire roadmap, although Hyperliquid is not directly mentioned, the design seems to target Hyperliquid’s strengths almost everywhere. It’s like Solana is saying: “What you Hyperliquid have, we want to have too, and we will do it better!”

It’s important to know that Hyperliquid has dominated the on-chain perpetual contract market, with its trading volume accounting for about 65% of the entire decentralized perpetual market at one point. Obviously, faced with such competitors, Solana is naturally unwilling to be surpassed by newcomers, so it has launched this ICM roadmap.

So, what exactly is this “imitation show” all about? Can Solana really catch up to or even surpass Hyperliquid? Today, let’s dive deep into this topic.

📋 ICM Background and Content

Who is leading this transformation?

First, let’s take a look at who created this roadmap. The participants are all heavyweight players in the Solana ecosystem:

• Solana Foundation/Labs: This doesn’t need much explanation, the “pro” of Solana, responsible for overall coordination and core protocol development.
• Anza: A development company founded by former members of Solana Labs, somewhat similar to Ethereum’s ConsenSys. They have taken on many core technical challenges in this roadmap, such as the new consensus protocol Alpenglow.
• Jito Labs: A major provider of MEV infrastructure on Solana, wielding significant influence and almost controlling the “life and death power” of all MEV traffic on Solana. This time, they are leading the provision of transaction ordering solutions such as Block Assembly Marketplace (BAM).
• Multicoin Capital: A renowned crypto investment firm and an early supporter of Solana. With a significant holding of SOL and equity in ecosystem projects, it also has considerable influence in the technical direction.
• DoubleZero: A team focused on accelerating network communication, providing dedicated fiber optic network solutions to enhance communication speed between Solana validator nodes.
• Drift: A leading perpetual contract DEX project on Solana. Previously, Drift adopted an off-chain matching model, which seemed somewhat challenging when facing fully on-chain Hyperliquid. This time, participating in the roadmap formulation clearly hopes to leverage underlying upgrades to turn the situation around.

The core issue to be solved

The roadmap focuses on the improvement of the market microstructure, which can be summarized as the current on-chain trading mechanisms being unfriendly to market makers. This means that Takers, who actively initiate trades, benefit, while Market Makers, who place orders and wait for them to be filled, suffer losses. This is because Takers often have access to the latest information and proactively raise trading fees to ensure their trades are executed first, while Makers often do not have time to withdraw their orders and are forced to trade at unfavorable prices.

Some high-frequency arbitrageurs will exploit this asymmetry to launch a “toxic flow” attack. For example, when the on-chain price has not yet updated, but the off-chain price has changed, arbitrageurs can take advantage of the old price to eat up the market maker’s orders, causing the market maker to bear the losses. The result is that the Maker, in order to protect themselves, either widens the bid-ask spread or reduces the order volume, leading to a decline in overall market liquidity.

The ICM roadmap aims to balance this pattern and attract high-quality liquidity back to the chain.

The three steps of ICM

Solana has divided this grand plan into three phases:

Short-term (1-3 months): The main focus is to optimize the existing on-chain trading experience, making order book applications more user-friendly and reducing malicious MEV interference. Specifically including:

• Jito Labs’ Block Assembly Marketplace (BAM) module has launched on the mainnet. The significance of this module is to provide a temporary external system that allows smart contracts on Solana to have autonomous transaction ordering rights before the ultimate ACE (Application Controlled Execution) is launched.
• The Anza team optimized the success rate of “Entering trades in the same Slot” to reduce slippage and MEV losses.

These improvements are expected to be implemented gradually from July to September 2025.

Mid-term (3-9 months): Introduce dedicated high-speed network and new version of consensus, significantly reduce latency and improve throughput:

• Deploy a dedicated fiber optic network for DoubleZero, providing validators with near-zero jitter and reducing latency by up to 100ms for high-speed communication.
• Launched the Alpenglow consensus protocol, reducing the final confirmation time from about 12.8 seconds to approximately 0.15 seconds.
• Research and Development of Asynchronous Program Execution ( Asynchronous Program Execution, APE ), to reduce transaction execution blocking on consensus.

Long-term (9-30 months): A revolutionary upgrade to the core architecture of Solana, aimed to be achieved around 2027:

• Multiple Concurrent Leaders, MCL(: Allows multiple validators to propose transactions simultaneously within their respective pipelines, and then merge and sort these parallel blocks by priority fees. This weakens the monopoly of a single packager and enhances censorship resistance.
• Native applications can control execution ) Application Controlled Execution, ACE( Function: Truly empower on-chain smart contracts with the power to control the order of transaction execution.

Analyzing up to this point, the author believes that the story behind the proposal of the ICM roadmap should be as follows: the established DEX Drift on Solana has been surpassed by the newcomer Hyperliquid, which offers an excellent experience likened to “on-chain Binance.” Drift is unable to compete and has no choice but to seek help from “pros” like Solana Labs, Anza, and Jito. The “pros” proposed a technical transformation plan in the form of ICM, claiming they would replicate and equip Drift with Hyperliquid’s core capabilities, helping it to re-enter the DEX market. However, the “pros” also stated that this technical transformation is extremely challenging, thus dividing the technical plan into a three-step strategy, with the only equipment that can be provided to Drift in the near term being Jito’s BAM, allowing Drift to make do and compare with Hyperliquid for now.

Having clarified the background of the story, in the following chapters, the author will analyze in detail which signature skills ICM has imitated and replicated from Hyperliquid.

) 🎭 Imitation 1: Transaction Sorting Mechanism

The issue is as follows: As mentioned earlier, the current chain favors takers, and makers suffer from “toxic flow”. Users who actively take orders can initiate trades on the on-chain orders based on the latest off-chain prices and prioritize their transactions by increasing transaction fees, while market makers often do not have time to update or withdraw orders. The result is that market makers either widen the spread or simply withdraw liquidity, leading to a deterioration in market depth.

The ultimate solution of ICM: applying controllable execution ###ACE(

The ICM roadmap introduces the concept of ACE (Application Controlled Execution), which decentralizes the trading sorting rights to various chain applications, allowing the applications to determine how the transactions related to them are sorted and executed. For example, on Solana, which will implement ACE in the future, DeFi contracts can achieve the following custom trading sorting rules:

• Oracle Price Update Insertion: DeFi applications can insert a transaction to obtain the latest price from the oracle before matching large trades, ensuring that orders are matched at the latest reasonable price, preventing market makers’ quotes from being arbitraged based on outdated prices.
• Order Cancellation Priority: The application allows setting “cancellation requests” to take precedence over new “taker trades”, giving the maker the opportunity to withdraw orders in a timely manner when market conditions are unfavorable.
• Tail Auctions: For example, after a large buy order drives up the price, DeFi applications will auction off the opportunity to “follow closely behind”; whoever is willing to return the most profit to the protocol (or users) will have their transaction executed right after the large order. DeFi applications can return the auction proceeds to users, thereby converting toxic MEV traffic into positive income.

)# JITO’s BAM: Transition Plan

Before the official launch of ACE, Jito Labs introduced a transitional solution called Block Assembly Marketplace ###BAM(. The workflow of BAM is:

1. The user sends the transaction to a node running BAM software (instead of directly to the current Leader).
2. BAM nodes collect local transactions and run various plugins ) plugin ( to perform reordering of the transaction bundle (the plugins run in a secure TEE environment, hiding the transaction content from the outside before execution). Through the plugins, application developers can customize various sorting rules for their contracts, such as prioritizing order cancellations, updating oracle prices before matching, and even running complex in-app bidding.
3. The sorted transaction bundle is then sent to the Solana Leader for packaging on-chain.

BAM can be seen as a testbed before ACE goes on-chain, functionally very close to the ultimate ACE, but it operates in an independent network off-chain, rather than being built into the Solana main chain protocol.

It is worth noting that Jito has previously provided infrastructure aimed at MEV extraction (such as the Jito Block Engine), with a business model that creates opportunities for arbitrageurs by optimizing transaction ordering and sharing profits. This is somewhat a “spear” that stands in opposition to ordinary users and those being arbitraged. However, Jito closed its public mempool )mempool( feature aimed at arbitrage bots in early 2024 to reduce negative externalities such as sandwich attacks. This move indicates that the Solana community tends to suppress harmful MEV and maintain fairness for users.

The launch of BAM further aligns with this idea: it essentially transforms the original ordering mechanism used for MEV arbitrage into a “shield” to protect liquidity providers such as market makers, for instance, by prioritizing forced order cancellations to avoid losses for market makers, and introducing bidding rebates to reduce front-running profits, etc. Original MEV seekers who want to make money must change roles, develop BAM plugins to serve DeFi protocols, and profit from plugin transaction fees.

)# Learn from HYPERLIQUID

The above ACE/BAM approach can actually be seen as a kind of catch-up to the on-chain matching mechanism of Hyperliquid. Hyperliquid is a dedicated chain ### Appchain (, which is inherently designed for DEX. Moreover, the HLP Vault operated by Hyperliquid officially is actually one of the largest market makers on the platform, so it is understandable that the chain rules of Hyperliquid are more inclined towards liquidity providers, having already implemented many protective designs for market makers at the chain level, such as:

• Maker Order Priority Protection: Order cancellations and maker-only orders are prioritized to prevent market makers from being adversely filled without their knowledge. The “Cancellation Priority Execution” mentioned by Solana ACE has already been practiced by Hyperliquid for many years.
• Latest Price Guarantee: Hyperliquid’s settlement and matching processes emphasize “double-checking” using the latest feed prices and margin status. For instance, when there is a matching of pending orders, the system will pull the latest oracle price again to assess both parties’ margins, ensuring that risks are not caused by price delays. This is similar to ACE inserting oracle updates before executing trades.
• Self-Trade Protection: If a buy and sell order from the same address meets, Hyperliquid automatically cancels instead of matching to prevent wash trading or unnecessary fees.

Solana ICM’s ACE/BAM is undoubtedly “learning from” Hyperliquid. As the leading on-chain CLOB, Hyperliquid has implemented various mechanisms that are friendly to market makers using a dedicated chain. Solana now hopes to replicate this effect with a universal chain and modular plugins—that is, allowing each application to have similar control over trade ordering as Hyperliquid.

) ⚡ Imitation II: Instant Finality

Existing Consensus Comparison

Solana currently uses Tower BFT, where confirmation and finality are probabilistic and progressive: a block is considered “confirmed###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)Finalized(”. For certain applications (like high-frequency trading), a final confirmation time of over ten seconds is still too long.

HyperBFT is the consensus algorithm developed by Hyperliquid, inspired by the HotStuff consensus, which adopts a two-round voting process to confirm blocks, achieving “instant finality”.

• First Round: Pre-vote ) Prevote (: After the validator receives the candidate block broadcasted by the Proposer, a quick verification will be conducted. If the verification passes, each validator will cast a “pre-vote” ) Prevote ( vote for this block and broadcast it to the entire network. This vote represents: “I have initially reviewed this, and this block is fine.”
• Round 2: Precommit)Precommit(: Once a validator collects Prevotes from more than two-thirds of the validators for the same candidate block, it gains enough confidence that the majority of the network members acknowledge this block. Therefore, the validator will cast a more weighty “Precommit”)Precommit( vote, and broadcast 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 Precommits 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 of Hyperliquid is a final block, with no possibility of fork rollbacks, and the overall chain block delay is extremely low—official disclosure states that the average confirmation delay is 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 executed, it can be quickly confirmed and cannot be reorganized, greatly improving capital efficiency.

(# ALPENGLOW achieves instant finality

Alpenglow is a new consensus protocol that Solana is preparing to launch, aiming to accelerate block finality to 1-2 slots (about 150ms), achieving instant finality similar to HyperBFT. The component in Alpenglow that replaces TowerBFT for consensus 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 the validators) vote in favor of this block being valid, then this block will be immediately confirmed as “finalized”.
• Slow Channel: If the percentage of agreeing stakes does not reach 80% in the first round of voting, but is equal to or exceeds 60%, Votor will initiate a second round of voting. If the percentage of agreeing stakes remains at 60% or above after the second round of voting, then this block will also be finally confirmed.

Votor is essentially saying: “We assume a round of voting is confirmed, but if the conditions are not perfect, we initiate a two-round voting process that is almost identical to HyperBFT as a safeguard.” This is actually an imitation of the Hyperliquid voting mechanism.

)# The cost and countermeasures of instant finality

Hyperliquid can conduct two rounds of voting, with an important prerequisite: it employs a very streamlined set of validators, where in the early stages, less than 5 entities actually controlled the majority of the validating nodes. A limited-scale network can significantly reduce the communication overhead of BFT consensus.

But if the number of nodes expands to dozens or hundreds, the complexity of the voting process will rapidly increase, because the complexity of each round of voting is proportional to the square of the number of participating communication nodes. Solana has thousands of validator nodes, and achieving two rounds of voting while maintaining a high degree of decentralization poses 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:

• The Alpenglow also features a Rotor component, which replaces the old data distribution protocol Turbine. Unlike Turbine, which requires multi-level relays, Rotor uses a “single-hop relay” mode, allowing data blocks to reach the target validators faster, significantly reducing transmission latency. Additionally, under the current Turbine mechanism, the position of nodes in the data distribution tree is primarily based on stake weight ranking, with nodes having more stake positioned at higher levels to prioritize receiving data shards (shreds). However, this also means they must handle more downstream forwarding tasks, resulting in greater bandwidth consumption. The assumption behind this design is that nodes with more stake are often “pros”, presumably having stronger hardware and more sufficient bandwidth resources. Rotor updates this logic by no longer relying solely on stake size but by comprehensively considering each node’s actual bandwidth and communication performance. Nodes that perform better in real-time network performance will be dynamically assigned to critical positions, thereby intelligently planning the optimal data propagation path for the entire network, achieving a fast and stable “express” service.
• DoubleZero High-Speed Network is based on a dedicated fiber optic network + multicast technology, providing low-latency communication that is an order of magnitude faster than the public internet. This reduces the latency and jitter of messages traveling back and forth between geographically dispersed nodes, making the physical network foundation for rapid consensus more robust.

Even so, it is still quite challenging for Solana to achieve both “high decentralization + millisecond finality” at the same time. This is also why Alpenglow expects that it will take more than a year of development, and it is projected to go live in early 2026 (one can only hope).

🔄 Imitation Three: Asynchronous Execution Pipeline

HYPERLIQUID’s asynchronous pipeline

Traditional blockchain is single-threaded, meaning that 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 multi-threading and ensure that all nodes receive the same results in exactly the 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: ‘sorting (consensus)’ and ‘execution’. The execution process is as follows:

1. Time point T1:

   • Consensus Pipeline: Validators reach consensus on the transaction content and order of block N-1.

2. Time Point T2 (The Place Where the Magic Begins):

   • Consensus Pipeline: Starts processing block N. It packages and sorts transactions in the network, and votes and reaches consensus on this order. It does not care at all about the execution result of block N-1.
   • Execution Pipeline: Obtain the block N-1 that has reached consensus at time T1 and begin executing the transactions within it.

3. Time Point T3 (Pipeline Continues to Operate):

   • Consensus Pipeline: Completed the consensus for block N and passed the consensus result (a sorted list of transactions) to the execution pipeline. Then, it immediately started processing block N+1.
   • Execution Pipeline: Completed the execution of block N-1 and finally confirmed its status. Then, it seamlessly connected and immediately received block N, which was just completed by the consensus pipeline, to start executing its transactions.

In this Pipeline model, different cores of the CPU can be effectively utilized. Some cores can specifically handle network messages and consensus voting (sorting), while others can focus entirely on state computation (execution). Both pipelines operate simultaneously, maximizing hardware efficiency.

ICM’s APE plan

execution

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 consensus on the transaction results, any factors that could lead to different outcomes due to varying execution orders must be eliminated.

The reason why the asynchronous pipeline solution can succeed in Hyperliquid is that Hyperliquid, as a single-function appchain, has 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, and design an efficient pipeline based on this.

However, Solana, as a general-purpose chain, has dependencies in transactions that are much more complex than a traditional order book system. Therefore, to replicate the performance of Hyperliquid in a general environment, Solana faces significantly greater engineering challenges, requiring a lot of code to be redeveloped, which cannot be accomplished in the short term, thus it can only be classified as a mid-term plan in the ICM roadmap. Even so, the actual launch of APE still requires overcoming a series of challenges.

• Extreme Code Complexity: Supporting asynchronous parallel execution in distributed systems requires extensive underlying modifications. Once multithreading parallelism is introduced, the software complexity of the Solana validator node client will rise exponentially, along with an increased risk of unknown bugs. A single race condition mishandled could lead to consensus errors, resulting in catastrophic outcomes.
• Hardware Requirements Increased: Parallel execution requires a powerful multi-core CPU and more memory to run multiple execution threads simultaneously, maintain multiple temporary states, and rollback points. The threshold for Solana nodes is already high, and if it is further increased, it will affect the decentralization of the network.
• Worst Case Handling: The worst-case scenario for parallel execution is when a large number of transactions compete for the same state. For example, when certain popular contracts (such as 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, rollbacks, and replays, which may actually be slower than serial execution. How to gracefully degrade in the worst-case scenario without letting the system fall into livelock or performance cliff is a challenge in architectural design.
• Development and Audit Difficulty: Security verification under asynchronous and multithreaded conditions is very challenging. The Solana community needs to invest additional resources to audit the new execution model to prevent consensus vulnerabilities caused by parallelism from being maliciously exploited.

🤔 Will this imitation show be successful?

Based on the above analysis, the Solana ICM roadmap is essentially a deep “imitation show” of the Hyperliquid technology architecture. The core team of Solana plans to replicate all of Hyperliquid’s key skills and equip them to Drift, helping it to compete again in the DEX market with Hyperliquid. However, the author is not optimistic about the prospects of this imitation show.

Technical difficulty increases exponentially

The success of Hyperliquid is largely based on its favorable inherent conditions:

• As a dedicated chain, it can optimize consensus and execution around a single application, designed without the need to accommodate various different smart contract requirements;
• As an emerging chain, it can even sacrifice a certain degree of decentralization for the sake of performance (initial validators are controlled by the team, and most users tacitly accept this).

In contrast to Solana, achieving the level of Hyperliquid while maintaining the universality of general public chains and the degree of decentralization presents an exponential increase in technical difficulty. For instance, Hyperliquid’s HyperBFT consensus can achieve a 0.2-second latency with fewer than 5 nodes, while Solana would have to push the limits of network communication to achieve the same latency with 2000 nodes; Hyperliquid’s matching engine only serves its own exchange logic, whereas Solana’s ACE/BAM must adapt to a myriad of DeFi protocols.

It can be said that Solana is catching up with Hyperliquid, and the difficulty of the course is much higher than what Hyperliquid experienced back then, “who knows how high it has gone.” The ICM roadmap breaks these tasks down to 2027, indicating that the officials are well aware that it is not a task that can be accomplished in a day.

The contradiction between decentralization and efficiency

Another difference between Solana and Hyperliquid lies in their governance and upgrade pace. The Hyperliquid team is small and centralized in decision-making, lacking external governance checks, allowing for rapid action. In March of this year, when Hyperliquid encountered the manipulation of the JELLY contract, the team swiftly delisted the relevant markets within hours, protecting the safety of funds, demonstrating that centralized decision-making, although “politically incorrect,” can be effective and useful in critical moments.

As a public chain, Solana has a foundation, core development, and a community involved in various power struggles, leading to a relatively slow and conservative upgrade process. For example, the highly anticipated Firedancer (a high-performance Solana client developed by Jump) has been in testing and refinement since its launch in 2022 and is not expected to be fully online until mid-2025; any changes involving consensus require long periods of auditing and testnet operation. Moreover, changes to the ICM roadmap are even more significant: switching the core consensus algorithm, introducing new parallel execution, and decentralizing key powers come with heightened difficulty and risk. It is foreseeable that over the next two to three years, the Solana team will need to gradually implement these upgrades, with each step potentially facing unexpected technical challenges or community resistance.

For example, for the 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 validator 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 goals potentially taking an indefinite amount of time to achieve.

Even if everything goes smoothly and Solana achieves ACE and other goals by 2027, it will only be a “successful catch-up”—merely catching up to the features that Hyperliquid has already provided in 2023-2024. And Hyperliquid itself will not stop: for example, the HIP-3 proposal will 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 features of Hyperliquid, perhaps Hyperliquid will have opened up new leading advantages.

Beyond Technical Competition

Although this article focuses on comparing the technical clashes between Solana and Hyperliquid, we must also recognize that Hyperliquid’s success is not solely attributed to technology. Hyperliquid has many commendable aspects in its operations and ecosystem:

• For example, in terms of token economics, Hyperliquid has no VC funding, and over 76% of the tokens are allocated to the community. The profits from the fees earned by the platform can be used to repurchase HYPE tokens, truly achieving shared benefits with users and eliminating the issue of capital parties excessively squeezing users. This has earned Hyperliquid a strong reputation among many loyal users.
• In addition, the Hyperliquid team is extremely keen on capturing market demand: when NFTs were hot, they launched the 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; the planned HIP-3 upgrade this year will support any project to issue perpetual contract markets on their own. Product innovation is constantly emerging, and these rich trading categories and innovative gameplay greatly enhance Hyperliquid’s attractiveness as a trading platform — users come here not only for speed, but also for the money-making opportunities that are unavailable elsewhere.

In contrast to Solana’s DEX track, native DEXs like Drift do not actually have significant advantages in product design and incentive mechanisms. Simply replicating the technology of Hyperliquid and achieving parity in chain performance will not automatically lead to a large-scale return of users if unique features that address user pain points are not provided, after all, user migration also has its costs.

Therefore, if one merely follows in the footsteps of Hyperliquid, they will forever be left eating dust behind others. The real opportunity in the Solana ICM roadmap does not lie in the perpetual contract or order book space. There are many areas within the Solana ecosystem that Hyperliquid has yet to explore, such as MEME launchpads, lending protocols, etc., which 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 the realization of its “internet capital market” vision. After all, no matter how strong Hyperliquid is, it is just a vertical domain app chain, whereas 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 showcases the determination of the Solana community to not be outdone and to strive for progress. From ACE to Alpenglow to APE, each corresponds to Hyperliquid’s unique features, indeed implying a sense of “targeted imitation.”

However, imitation is easy, but surpassing is difficult. For Solana to successfully perform this imitation show, it needs to make comprehensive efforts in technological breakthroughs, ecological collaboration, and market strategies. In the short term, Solana may improve the on-chain trading experience through BAM and regain some users. However, to truly shake Hyperliquid’s leading position, it may require a longer time and more innovations.

At least for now, Hyperliquid is continuously expanding its territory with its advantage in market share, while Solana is still in the process of accelerating its engine overhaul, and this transformation process is likely to take quite some time.

The future depicted in the ICM roadmap is exciting, but whether it can achieve “overtaking on a curve” remains to be seen. As regular users, we can look forward to this competition bringing a better on-chain trading experience — regardless of who ultimately wins, the users are the beneficiaries.

This article is based on publicly available information and does not constitute investment advice. Cryptocurrency investment carries significant risks, please make decisions cautiously, DYOR.

If you like this article, feel free to follow, like, and share your support!