Arc mainnet is now liveGet started with RPC, Streams, and Webhooks.
建立一個endpointHyperliquid's HIP-4 Goes Permissionless: Templates, Economics and Risks
HIP-4 is moving to permissionless deployment. Learn what changes, what remains governed, how markets launch and where risks sit.
已通過 SOC 2 Type II 認證 · ISO 27001

September 18, 2026 — 12 min read

Money changes how people answer a question. Ask who will win an election and everyone guesses. Ask them to bet on it and they actually think.
That's the premise behind prediction markets: turning beliefs into tradeable probabilities.
Polymarket and Kalshi built around it. Hyperliquid took a different route with outcome trading through HIP-4, where markets settle to 0 or 1.
But market creation was initially gatekept.
Recently, HIP-4 has been moving toward permissionless deployment. But that does not mean permissionless everything.
Let's learn what will actually be permissionless, what remains controlled, how these markets work, and what this shift could mean for Hyperliquid.
HIP-4 is Hyperliquid's standard for outcome contracts. These are fully collateralized contracts that settle between 0 and 1 based on event results.
Launched in May, these contracts run natively on HyperCore, the same order book that handles Hyperliquid's perps and spot markets. So, they share the necessary liquidity, margin, matching, and infrastructure with everything else on the blockchain.
Since launch, the primitive has cleared roughly $283M in cumulative volume with close to 19,000 unique traders. Recently, there's been a clear ramp-up too with the first week of September seeing $16.2M in trading volume and 351K trades.
Those numbers show demand for outcome trading. But they say less about the supply side: who gets to create the markets being traded?
Permissionless HIP-4 allows third-party deployers to launch outcome markets on Hyperliquid without getting each individual market approved by validators.
However, deployers still cannot build any market they want.
Each market must follow a validator-approved template that sets the guidelines for a class of outcome contracts.
Deployers then get to create individual markets within those rules or templates.
This splits market creation into two layers:
Validators govern the market structure via templates.
Deployers create markets within it.
Let's understand what this split means for the overall HIP-4 market:
Before permissionless HIP-4 | Permissionless HIP-4 | |
|---|---|---|
Who can create markets? | Hyperliquid validators | Third-party deployers |
What can they create? | Validators choose individual markets | Deployers create markets from validator-approved templates |
Requirement to deploy | Validator privilege (initially 1M HYPE bond) | 500K HYPE staked for at least six months on mainnet (100 HYPE on testnet) |
Fee share | No third-party deployer | Deployers can receive up to 50% of trading fees |
Validator role | Choose and deploy every market | Approve templates, vote on slashing, deploy rare canonical markets |
So, permissionless deployment does not remove validators from HIP-4. What will they be responsible for?
One responsibility of validators is being lifted off their shoulders, i.e. individual market creation, which is moving to deployers.
However, there are three functions that validators still need to run:
Validators vote on the templates deployers can use. An approved template defines a market structure that can support many individual markets.
Every permissionless deployer stakes 500K HYPE on mainnet. Validators can vote to slash that stake for violations such as incorrectly settling a market.
Validators can still create markets directly. Hyperliquid reserves this route for rare canonical outcomes that should exist independently of third-party deployers.
Next, we are going to answer the core question: what exactly is a template and how does it work?
Templates determine what the markets are allowed to look like before they're permissionlessly deployed.
HIP-4 templates are validator-approved contract specs for a class of outcome markets.
For example, a template could establish how a binary outcome works and settles.
Deployers can then use that structure for different questions without asking validators to approve each question separately.
This separation is what makes permissionless deployment scalable: Approve the structure once > deploy many individual markets from it.

The process has three layers:
Specifies the rules deployers must follow, including the outcome structure and settlement criteria supported by that template.
A new market structure does not become permissionlessly available just because a deployer wants it. Validators must first approve the template.
Once approved, eligible deployers can create markets that conform to the template without another validator vote for each deployment.
So potential HIP-4 builders have two possible paths:
Fits an approved template > deploy permissionlessly
Needs a new market structure > template approval comes first > deploy market, if approved
Now, once the template is sorted, the deployment process of a HIP-4 outcome market is pretty straightforward.
Permissionless HIP-4 markets move through five stages:
The deployer checks the live catalog through outcomeTemplates and selects a template that fits the market.
If none supports the intended structure, a new template must first receive validator approval.
On mainnet, deployers must stake 500K HYPE for at least six months and activate through activateOutcomeDeployer. On testnet the requirement is 100 HYPE, so the full flow can be tested before committing mainnet capital.
The stake secures all markets they deploy. They then set the parameters permitted by the template, such as the question, settlement date, and outcome criteria.
Forge is a live example of this on testnet: pick a validator-approved format, fill in the question, and sign with your wallet to deploy the market.
A single call creates the market:
registerStandaloneOutcomeFromTemplate for a single yes/no market
registerQuestionFromTemplate for a question with multiple named outcomes
Markets run as native HyperCore assets, using Hyperliquid's existing matching and trading infrastructure.
Deployers can receive up to 50% of trading fees generated by their markets.
Resolution follows one of two paths:
Price-threshold markets settle based on whether the price crosses a set threshold. The settlement price is interpolated from HyperCore mark-price updates immediately before and after settlement.
Event-based markets run through the deployer's authorized oracle or other resolution source that determines the result and submits it onchain.
This is where wording matters. Ambiguous definitions or incorrect resolution can put the deployer's stake at risk.
Once resolved, HyperCore settles the market at its final value.
Standalone markets: An authorized settler calls settleOutcome.
Multi-outcome questions: settleQuestion2 can resolve the remaining outcomes together.
And the matching engine takes it from there. The market closes and collateral is distributed and settled according to those final positions.
Once correctly settled, the market no longer keeps the deployer's stake locked as an outstanding market.
Validators can vote to slash the stake if the deployer settles contrary to the template's criteria or leaves a market incorrectly unsettled.
This way, HIP-4 outcome markets are permissionless to create without being trustless at every step of their lifecycle.
Mechanisms aside, what are the economics of HIP-4 outcome markets?
Every HIP-4 market needs three parties to have a reason to participate: a deployer to operate it, market makers to supply liquidity, and traders to create flow.
Participant | Capital / cost | Economic incentive | What makes the economics work |
|---|---|---|---|
Deployer | 500K HYPE stake (mainnet) + operating costs | Up to 50% of trading fees from deployed markets | Enough aggregate volume across markets to justify locked capital and operations |
Market maker | Full collateral (no leverage) + inventory + infrastructure | Spread, deployer-funded incentive programs where they exist, trading P&L | Enough volume and two-sided flow to compensate for inventory and settlement risk |
Trader | Trading collateral + fees + spread | Profit from being right or faster than the market | Sufficient depth to enter and exit without losing the edge to execution costs |
The economics create a clear tension.
The 500K HYPE stake is per deployer so operators can spread that fixed cost across multiple markets. This favors those who can launch repeatedly and attract trading volume.
Market makers face the reverse: every new market is another order book competing for limited capital. Too many thin markets can fragment liquidity and make trading costly.
Traders connect the loop. Their volume generates fees and trading opportunities; deeper liquidity can lower execution costs and attract more volume.
Now, more permissionless markets do improve the supply of things to trade.
However, at the end of the day, permissioned or not, liquidity determines which markets become viable.
Liquidity is a market problem. HIP-4 deployment is a market-making solution. Does it come with any risks attached that even deep liquidity cannot solve?
HIP-4 deployment is a playing field for validators, deployers, resolution sources, market makers, and traders. Risk and responsibility are shared between them all.
Risk | What can go wrong | Who/what provides the check |
|---|---|---|
Market-definition risk | Wording leaves room for multiple interpretations of the same event | Clear question, criteria, sources, and settlement conditions at deployment |
Resolution risk | The source is wrong, unavailable, disputed, or cannot cleanly answer the market question | Template-defined resolution rules + deployer accountability |
Liquidity risk | A market exists but has too little depth to trade efficiently | Market makers + trader flow; no protocol guarantee of liquidity |
Fragmentation risk | Similar markets compete for the same traders and market-making capital | Distribution, market quality, deployer reputation, and liquidity concentration |
Validator risk | Validators approve weak templates or make contentious slashing decisions | Validator consensus and the wider Hyperliquid governance/security model |
The distinction between price-based and event-based outcomes matters here.
Price markets can derive settlement from HyperCore's own mark-price history.
But, real-world events introduce another dependency: some external mechanism must establish what happened. Elections, regulatory decisions, sports results, and similar markets therefore inherit the quality of their question wording and resolution source.
Permissionless deployment removes a listing bottleneck but does not remove the work required to make a market trustworthy and tradeable.
Now, how do Hyperliquid HIP-4 outcome markets fare against Kalshi and Polymarket?
Although the three platforms seem to list and serve similar purposes, the reasons to trade on each still remain different.
Decision factor | Polymarket | 卡爾希 | |
|---|---|---|---|
Market creation | Permissionless within validator-approved templates | Markets selected by Polymarket | Contracts listed by Kalshi |
Trading model | HyperCore CLOB | Prediction-market CLOB | Regulated exchange CLOB |
Market coverage | Growing; constrained by approved templates | Broad event-market catalog | Broad event-market catalog |
Liquidity today | Early and concentrated | Established prediction-market liquidity | Established prediction-market liquidity |
Resolution | Deployer-submitted, validator-slashable | UMA optimistic oracle, bond-and-challenge | CFTC-regulated exchange rules |
Dispute path | None onchain. Slashing is an aftermath | Open challenge window before finality | Regulatory adjudication |
Permissionless deployment | Yes, within approved templates | 不 | 不 |
Primary structural edge | Native integration with Hyperliquid's trading stack | Prediction-market distribution and market breadth | U.S.-regulated event-contract venue |
Let's talk numbers to see how big the gaps are between the platforms.
On a September Fed market, prices across Hyperliquid, Kalshi, and Polymarket sat within roughly one cent of each other. However, the gap was market depth: the Hyperliquid event had around $600K of volume while its peers were already in the tens of millions.
That leaves HIP-4 with a different problem from the one it started with.
Permissionless deployment can create the markets. It cannot guarantee that liquidity follows them. What next?
Permissionless deployment changes the constraint on HIP-4.
The first phase proved that outcome contracts can trade natively on HyperCore. The next phase tests whether independent deployers can turn that primitive into a market ecosystem.
That shifts the pressure elsewhere.
Templates need to cover enough market structures.
Deployers need to find questions worth trading.
Market makers need enough volume to justify spreading capital across more order books.
Resolution needs to remain predictable as markets move from crypto prices into elections, macro events, sports, and other real-world outcomes.
The stronger signal will be repeat deployers attracting repeat liquidity across other markets without relying on Hyperliquid to choose what gets listed.
Quicknode supports both HyperCore and HyperEVM through a unified developer platform, so builders can connect to Hyperliquid without running their own infrastructure. For trading applications, analytics platforms, and AI agents, it provides production-ready access through a single endpoint.
View current pricing: quicknode.com/api-credits/hyperliquid.
More Quicknode resources for Hyperliquid builders:
Hyperliquid Python SDK (also on PyPI), Hyperliquid API Examples, Hyperliquid SDK Examples, HyperCore CLI, and hyperliquidapi.com.
這些資源綜合起來,為開發者提供了從 RPC 存取到即時事件處理及鏈下邏輯等全方位功能,使Quicknode 在Hyperliquid 上部署應用程式、市場及分析Quicknode 快Quicknode 。
Yes. Multiple deployers can use approved templates to create markets around the same event, potentially competing for liquidity and traders.
Deployers can receive up to 50% of trading fees generated by their deployed outcome markets.
No. They use HyperCore's trading infrastructure but maintain separate order books and need their own market liquidity.
Yes. HIP-4 exposes market and deployment primitives that frontends, trading systems, market makers, and other infrastructure can integrate with.
No. A slashed deployer bond is burned, not redistributed, so affected traders don't recover losses through that mechanism.
No. Every position is fully collateralized at open, with no leverage and no liquidation risk involved.
No. Hyperliquid remains geoblocked to US persons, independent of how permissionless the deployment process becomes.
Quicknode 成立於 2017 年,為開發者與企業Quicknode 機構級的區塊鏈基礎設施。憑藉 99.99% 的正常運行時間以及對 80 多條區塊鏈的支持,各團隊得以在無需妥協的情況下,開發並擴展鏈上應用程式。
將最新的工程見解、產品更新及 Web3 新聞直接送至您的收件匣。