Special thanks to Xulian, Wasim, David, and Chuck for the feedback and review.

Hyperliquid is evolving from a high-performance, curated exchange into a generalized financial infrastructure layer, where market creation, distribution, and liquidity formation are progressively handed to the community. HIP-1/2 enabled permissionless spot listing and liquidity bootstrapping; Builder Codes externalized distribution; HyperEVM added programmable composability; and, now, HIP-3 enables third parties to deploy perps on HyperCore’s orderbook – turning Hyperliquid from a curated venue into a platform others can build exchanges on.

Perps have come to dominate crypto trading activity, consistently surpassing spot volume and now accounting for the majority share of global crypto trading by as much as tenfold spot volumes. These markets demand high-throughput, low-latency execution to support sophisticated traders, liquidations, real-time risk management, and robust orderbooks. HyperCore delivers these institutional-grade features, and by enabling permissionless perps creation via HIP-3, they are now directly accessible to external builders. As such, HIP-3 is a powerful way to “communalize” growth – expanding Hyperliquid’s addressable market from curated crypto pairs to any oracle-defined asset and marking what is arguably the most important step in the protocol’s communalization roadmap.

HIP-1/2: listing + liquidity (May 2024). HIP-1 introduced a native token standard and HIP-2 addressed cold-start liquidity for new spot markets, effectively decentralizing token listings with liquidity bootstrapping right on HyperCore’s orderbooks. This is where Hyperliquid’s communalization began – external teams could issue and list assets permissionlessly.

Builder Codes: distribution as a public good (October 2024). Builder Codes allow builders (wallets, UIs, bots, aggregators) to earn an additive fee on any orders routed to Hyperliquid perps and spot, effectively turning any app into an aligned distribution partner for Hyperliquid. Builder fees charged can be at most 0.1% on perps and 1% on spot. So far, BasedApp (multipurpose crypto app) and Phantom (wallet) have led in Builder revenues, already earning eight-figure revenues.

There are already 400+ Builders that have collectively generated over $46 million in total revenue. Our portco Dexari has earned $500K in Builder Code revenue and Senpi will soon integrate it as well. This is programmatic community growth in action: more order flow → deeper book → better execution → more Builders.

HyperEVM: programmable access to HyperCore liquidity (February 2025). HyperEVM was designed to bring general-purpose programmability to Hyperliquid’s financial system. It runs on the same validator set and consensus as HyperCore, giving contracts read/write access to the orderbook, so builders can compose DeFi apps directly against Hyperliquid’s liquidity without external bridges. In practice, HyperEVM serves as a complementary programmability layer to HyperCore, enabling HyperCore-aware apps like lending, staking, vaults, and automated strategies that integrate natively with HyperCore’s liquidity and state.

HIP-3: permissionless perps (October 2025). HIP-3 supports permissionless builder-deployed perp markets, effectively turning Hyperliquid into a shared perpetuals layer where external teams can run exchanges on the same infrastructure as validator-operated perps with equivalent benefits (e.g., deterministic, sub-second matching; protocol MEV resistance). The first mainnet deployment is XYZ100 by trade[XYZ], an equity perp designed to mirror the Nasdaq‑100 index. Within days, XYZ100 reached top-10 on Hyperliquid in trading volumes (currently >$150M daily), showing that external builders can successfully leverage HIP-3 to launch their own perps contracts and also operate their own exchanges on top of HyperCore to earn both fee share from HIP-3 contract trading and via Builder Codes.

In addition to XYZ, Ventuals and Felix HIP-3 markets are now live on mainnet and listed on Hyperliquid’s official frontend. There are also 15+ projects that have deployed testnet HIP-3 markets, already covering US stocks, pre-IPO valuations, structured products, volatility indices, collectibles, and even GPU prices.

HIP-3 lets any qualified builder deploy perp markets on the same high-throughput, sub-second CLOB engine used by Hyperliquid’s native markets, with full control over oracle specification, risk parameters, fees, and settlement logic.

Key mechanics include:

• Staking. Deployers must lock a large HYPE stake – 500K HYPE requirement per perp DEX, which includes 3 “free” asset deployments. The staking requirement is expected to decrease over time as the infrastructure matures. The stake is subject to validator-governed slashing to ensure market quality and user protection, with slashed stake being burned. The bond filters for serious operators and also acts as a potential token sink.

• Dutch auction. Beyond the 3 included asset deployments, additional asset listings clear via HYPE-denominated Dutch auctions every 31 hours, inherited from HIP-1 spot listing auctions (starts at 2x the last winning bid, or 500 HYPE floor if there was no previous sale; linear decay over 31 hours to floor price). This helps to pace launches and introduces scarcity into price discovery for time-limited listings. HIP-3 listing auction proceeds are then burned, similar to HIP-1’s buyback-and-burn slot economics.

• Fee sharing. HIP-3 perps have 2x fees relative to validator-operated perps, and builders capture 50% of these fees; the remainder accrues to the protocol. The net effect is that the protocol collects the same fee from HIP-3 perps as validator-operated perps. The Builders can layer an additional fee via Builder Code (up to 0.1% on perps and 1% on spot). This structure keeps protocol economics neutral, while incentivizing builders to build value-add services on top.

Altogether, HIP-3 replaces opaque, pay-to-play listing with transparent, market-driven creation and recurring HYPE sinks (burns via auctions, slashed stake), while sharing revenues with the deployer for taking on the responsibilities and risks of deploying and managing their own market. The result is a credible path to “open perps” with strong value capture to the protocol and token built in.

The high HYPE staking requirement (~$15M at current HYPE price) naturally pushes the market toward collective deployment (e.g., DAOs pooling HYPE, sharing profits, and governing parameters together). There will be a rise of HYPE liquid staking protocols that let contributors earn deployer yield while distributing slashing risk and governance rights – mirroring ETH liquid staking economics (e.g., see Kinetiq’s Launch). Long-term possibilities include cross-market margining, collective risk management, and protocol-level clearinghouse functions as staking pools collectively manage more capital and govern multiple HIP-3 markets.

Builders and DAO pools will partner with MMs and other institutions to launch new HIP-3 markets and maintain liquidity in exchange for revenue share and other protocol incentives (e.g., HyperEVM protocol Felix partnering with Hyperion DeFi to seed HIP-3 stake). This can take various forms – e.g., MM can collaborate with a DAO to raise the HYPE stake; MM provides initial liquidity and ongoing depth, while the DAO supplies capital and community demand. Other forms include “retail MMs” via openly accessible HFT tools as we’re recently with tread.fi’s market maker bot, which has driven >$600M in 30-day volume for XYZ100 alone. 

These relationships would be mutually beneficial: deployers achieve a viable market with low slippage, and market makers get early-mover advantage on new revenue streams and protocol incentives (and potentially influence on market parameters). This “onchain exchange startup” model resembles exchange-MM launch relationships but open and onchain, with public state and slashing-backed accountability. With more and more HIP-3 markets, the fragmented liquidity will need to be balanced by both professional and retail market making services.

Permissionless perps imply many venues with distinct books and parameters. Expect meta-aggregators (e.g., see Lit, Katoshi) that surface all HIP-3 markets in a unified interface for ecosystem-wide discovery and execution; routing infrastructure to find best price/liquidity; and cross-market liquidity optimization vaults that algorithmically shift capital across markets by yield, prices, funding, and depth. Where there’s fragmentation, expect aggregation – we’ve seen it for spot DEXs and we can expect it for perp DEXs. 

Deployers will sell proprietary, unpublished price indices featuring with custom oracle logic (e.g., methodology, data sources, aggregation process, failover strategy) as they establish expertise in oracle design in niche sectors (e.g., structured products, as with Stratium; collectibles, as with Trove). This generates B2B revenues from API access and licensing to marketplaces, funds, and data providers, positioning new HIP-3 markets as pricing infrastructure for other applications.

HIP-3 deployers publish perp contracts that anyone can route orders to without permission from the deployer. Builders will develop alternative trading interfaces, mobile apps, trading bots, copy trading platforms, and trading games that will use Builder Codes to monetize across all HIP-3 venues.

More markets → more traders → more volume → more protocol revenue and stronger HYPE demand (via auctions, staking, burns). The effect compounds similarly to Uniswap’s open listing flywheel – but with explicit value capture to HYPE.

While the long-term thesis for Hyperliquid with HIP-3 is compelling, it’s important to address non-trivial challenges and risks that come with this model.

• Fragmentation. Fragmentation is the central long-term tradeoff of permissionless perps. Opening perps deployment to external builders brings the risk of thin, scattered orderbooks and a proliferation of “long tail” venues with poor execution and slippage. While staking and auctions are designed to curb spam, total capital is still finite. Without effective aggregation, routing infrastructure, and accessible volume-generating bots, UX is likely to degrade as liquidity fragments across more and more HIP-3 markets. There’s risk of something like the altcoin dilution we’re seeing lately (too many tokens; liquidity and attention diluted) – HIP-3 faces a similar risk but with perps.

• Liquidity and volatility. The binding constraint for many HIP-3 markets is insufficient committed liquidity in the launch phase. Nascent markets lack clean delta-neutral opportunities (e.g., long SPACEX on Ventuals has no symmetrical short on other venues), leaving market makers with inventory and basis risk without reliable hedges. Professional MMs won’t quote size or tight spreads if they can’t hedge efficiently, which elevates realized volatility, widens spreads, worsens price impact, and suppresses organic volume. Until robust MM programs are in place, many new HIP-3 markets may underperform their potential simply because liquidity is too thin.

• Stress events and ADL. Extreme moves can still trigger auto-deleveraging (ADL), closing profitable hedges and impairing delta-neutral strategies – a real risk institutions will consider before adopting HIP-3 strategies, especially in the aftermath of the 10/10 flash crash. If a hedge can be involuntarily taken away, it poses unique challenges in modeling risk management for perps in general. Builders and the protocol will need larger insurance buffers and better

HIP-3 standardizes the market-creation primitive for order-book perps the way AMMs standardized token pools. It’s permissionless; shared infrastructure handles matching/settlement; protocol economics (stake, slashing, auction) screens quality; and fee-sharing aligns builders with the Hyperliquid ecosystem. HIP-3 is “Uniswap for perps,” but with explicit value accrual mechanisms linking it to HYPE (staking, auctions, slashing, fee split) – a big improvement over past DEX governance tokens.

HyperCore’s orderbooks are already fed by Builder Codes, which monetize distribution and deepen their liquidity; HIP-3 adds supply-side composability, creating a two-sided community flywheel with market creators on one side and distributors on the other: more markets attract UIs, wallets, and bots → more distribution attracts traders → higher volumes attracts more market creation.

Becoming the “house of all finance” starts like this, but there are real obstacles to overcome along the way including (a) reliability under stress, (b) oracle robustness, and (c) solving for fragmentation.

All the components are coming together, with execution (HyperCore); programmability (HyperEVM); distribution (Builder Codes); and permissionless market creation (HIP-1/2/3). The upside case is a durable, token-aligned network effect across all oracle-definable markets; the risk case is liquidity fragmentation and volatility risks that limit institutional participation. On balance, Hyperliquid’s communalization strategy – layering open infrastructure with incentive alignment – is working very well so far.

Disclaimer

This article is prepared for general information purposes only. This post reflects the current views of its authors only and is not made on behalf of Lemniscap or its affiliates and does not necessarily reflect the opinions of Lemniscap, its affiliates or individuals. The opinions herein may be subject to change without this article being updated.

This article does not constitute investment advice, legal or regulatory advice, investment recommendation, or any solicitation to buy, sell or make any investment. This post should not be used to evaluate the making of any investment decision, and should not be relied upon for legal, compliance, regulatory or other advice, investment recommendations, tax advice or any other similar matters.

All liability in connection with this article, its content, and any related services and products and your use thereof, including, without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement is disclaimed. No warranty, endorsement, guarantee, assumption of responsibility or similar is made in respect of any product, service, protocol described herein.