HIP-4 on mainnet is still mostly concentrated around recurring crypto outcomes. Testnet already looks quite different, with sports, rate decisions and other event markets beginning to appear alongside them.
That gives a decent preview of what permissionless HIP-4 could look like. Creating markets should become much easier, but liquidity, trader attention and market-making capital do not expand just because more contracts can be launched.
So the interesting question is not whether HIP-4 can support hundreds of markets. It is what happens to liquidity when all of those markets start competing for the same capital.
Liquidity is already concentrating
The recurring crypto markets give a useful early example. One BTC contract did roughly $488,000 in volume, while the comparable ETH and SOL markets were both below $10,000.
The exact ratio is not the main point. These contracts run on the same infrastructure and have a similar format, yet activity still concentrates heavily in one of them.
That tells us something important about HyperCore. It can provide the same matching and execution infrastructure to every outcome, but it cannot make traders or market makers care about every outcome equally.
This becomes a much bigger issue once HIP-4 moves beyond a small crypto market set. If liquidity already struggles to spread evenly across BTC, ETH and SOL, it is hard to assume that it will suddenly spread efficiently across football matches, central-bank decisions and hundreds of other events.
A probability is only useful if there is a market behind it
The ETH market made the liquidity issue easier to understand.
Yes had recently traded close to 99%, but the visible bids were around 88.7%, with no asks showing. Someone looking only at the recent price would see a near-certain outcome, while someone actually trying to exit would have faced a very different market.
This does not mean 99% was necessarily the correct probability. The point is that the last traded probability and the immediately available price were more than ten percentage points apart.
That matters because prediction-market prices have two functions. They are prices traders transact at, but they are also interpreted as information about the probability of an event.
Those two functions begin to separate when liquidity gets thin. A market can display 90% or 95% and still offer poor execution once someone actually tries to trade size.
Low trading frequency can make the same problem worse. The frontend may continue showing the last transaction even after the live book has moved, which makes the probability look more current and precise than the underlying market really is.
This is why total volume alone tells us very little about whether a HIP-4 market is good. The more useful question is how much capital can actually enter or leave around the displayed probability without pushing the price significantly.
More markets, same pool of liquidity
Testnet gives a good preview of how much broader HIP-4 could become.
The current testnet environment already includes sports and macro-style outcomes alongside crypto markets. Hyperliquid has also moved the first version of permissionless HIP-4 deployment onto testnet, while permissionless deployment on mainnet is still to come.
The important thing here is not testnet volume. Test capital behaves differently from real money, so those order books tell us very little about what liquidity will look like once these markets are trading with real capital.
What matters is how much easier it becomes to create markets.
Hyperliquid is moving toward a model where validators approve reusable templates and deployers use them to create the individual markets. That structure makes sense because the number of possible event markets is far larger than the number of assets that would ever justify their own spot or perpetual market.
The mainnet rollout is also being designed to expand gradually. Each deployer will initially be limited to 100 concurrent outcomes, but Hyperliquid expects that limit to increase to 1,000 once the system is stable. The important point is not the exact ceiling, but how quickly the protocol can increase the supply of markets once the infrastructure is ready.
Liquidity does not scale in the same way. Allowing a deployer to run ten times as many outcomes does not create ten times more traders or ten times more market-making capital. It simply gives that capital more markets to choose from.
This is why permissionless HIP-4 moves the bottleneck rather than removing it. Creating a market becomes much easier, but building enough liquidity around that market still has to be solved one market at a time.
Why deployers matter
The deployer model becomes more important once you look at HIP-4 from that angle.
Under the current design, a HIP-4 deployer would stake 500,000 HYPE and initially be able to operate up to 100 concurrent outcomes. Validators approve the templates, while the deployer chooses which individual markets to create from them and is responsible for operating and settling those markets correctly.
The numbers show that Hyperliquid is treating the deployer role seriously, but the incentive structure matters more. Someone now has a direct reason to make an individual market work rather than simply making sure it exists.
A sports-focused deployer may have a better understanding of which events deserve markets, how unusual results should be handled and where the traders for those markets already are. A macro-focused deployer has a different job around rate decisions, economic data and settlement sources.
That specialisation matters because an outcome market needs more than an order book. Someone has to choose useful markets, define them properly, attract traders and convince market makers that keeping capital on those books is worthwhile.
Fees are becoming part of that job as well. The latest testnet implementation lets HIP-4 deployers configure a fee multiplier for the markets they create, which means two deployers offering similar exposure do not necessarily have to offer traders the same economics.
That creates another trade-off for the operator. A market needs enough liquidity to offer good execution, but the fee structure also has to remain competitive if another deployer is trying to attract the same flow. The strongest deployers will have to get both sides right rather than relying on the listing itself.
What happens when two deployers list the same thing?
This is where permissionless HIP-4 gets more interesting.
Hyperliquid does not require every event to sit inside one official market. Different deployers can create the same template instantiation, which means two operators can run separate order books around effectively the same outcome.
The first effect is likely to be fragmentation. If two deployers list the same Fed decision, for example, traders and market-making capital can initially be divided between two books instead of concentrating in one.
But there is no reason to assume that the liquidity stays divided evenly.
Once one version develops a deeper book, traders have a reason to prefer it because execution is better. Fees can matter too, particularly when two deployers are offering almost the same exposure and traders have little reason to stay loyal to the weaker market.
More trader flow then makes that book more attractive to market makers, which can bring in more capital and deepen it further. The weaker market faces the opposite problem because lower activity gives both traders and market makers fewer reasons to keep using it.
So duplicate markets may split liquidity at first, but that does not mean the split lasts. Over time, activity can start concentrating around the deployer offering the better combination of liquidity, execution, fees and reliable market operation.
HIP-3 gives a useful precedent
HIP-3 is not the subject of this article, but it gives a useful example of how that process can look.
TradeXYZ and Markets by Kinetiq both offer NVDA exposure through separate HIP-3 markets. TradeXYZ captured essentially all of the activity, while the Markets by Kinetiq version was effectively inactive.
The products are not identical in every detail because HIP-3 deployers control their own market definitions and operating parameters. The useful point is simply that permissionless market creation does not force liquidity to remain evenly distributed across operators.
That is relevant for HIP-4 because the same basic competition can happen around event markets. Several deployers may be allowed to create similar or identical exposure, but traders still have strong reasons to concentrate around the better book.
The listing itself is not much of a moat
This is where HIP-4 becomes different from simply letting anyone launch another market.
If another deployer can create the same outcome, being first to list the question is not a very durable advantage. What is harder to copy is the liquidity, distribution and operating record that forms around the stronger market.
Market operation matters here as well. HIP-4 deployers are responsible for settling the markets they create, and the staking system gives validators a way to penalise poorly defined or incorrectly settled markets.
So deployers eventually compete on more than liquidity and fees. Traders also have a reason to care about clear market rules and whether an operator has built a reliable record over time.
A strong deployer can therefore become more than someone who lists markets. It can become the place traders automatically look for a certain category because they expect the liquidity and operation to be better there.
That could produce a very different market structure from what “permissionless deployment” initially suggests. HIP-4 may have many deployers at the creation layer while meaningful liquidity ends up concentrated among only a few of them.
Where HIP-4 could end up
The most interesting question is no longer whether Hyperliquid can list enough outcome markets. Testnet already suggests that the supply of markets can become much broader once permissionless deployment opens up.
The harder question is what happens after they are created.
If every new market simply spreads the same pool of liquidity thinner, HIP-4 could end up with a large catalogue of contracts that are difficult to trade well. If competition instead pushes traders and market makers toward the strongest operators, the ecosystem could develop a small number of category-specific liquidity centres.
That outcome would make permissionless HIP-4 somewhat counterintuitive. Market creation could remain open to many operators, while liquidity becomes increasingly concentrated.
I think that is the most interesting possibility to watch.
Hyperliquid can make it easier to create an outcome market. It cannot make traders care about every market equally. The deployers that build the deepest books, attract the strongest distribution and operate their markets well are the ones most likely to become meaningful when permissionless HIP-4 finally reaches mainnet.