Blog>Hyperliquid's HIP-4 Goes Permissionless: Templates, Economics and Risks

Hyperliquid'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.

Quicknode

Quicknode

September 18, 2026 — 12 min read

Hyperliquid's HIP-4 Goes Permissionless: Templates, Economics and Risks

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.

What is HIP-4?

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?

What Permissionless Deployment Actually Changes for HIP-4

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?

What Validators Actually Govern in Permissionless HIP-4

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:

1. Approve templates

Validators vote on the templates deployers can use. An approved template defines a market structure that can support many individual markets.

2. Enforce deployer accountability

Every permissionless deployer stakes 500K HYPE on mainnet. Validators can vote to slash that stake for violations such as incorrectly settling a market.

3. Deploy canonical markets

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?

HIP-4 Templates: The Rules That Permissionless Deployments Need to Follow

Templates determine what the markets are allowed to look like before they're permissionlessly deployed.

What are HIP-4 Templates?

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.

How HIP-4 templates, deployers, and individual markets fit together
Validator-approved templates sit at the top. Each deployer stakes 500K HYPE and creates individual markets from a template, such as binary price markets or real-world event outcomes.

How Do HIP-4 Templates Work?

The process has three layers:

1. A template defines the boundaries

Specifies the rules deployers must follow, including the outcome structure and settlement criteria supported by that template.

2. Validators approve the template

A new market structure does not become permissionlessly available just because a deployer wants it. Validators must first approve the template.

3. Deployers instantiate individual markets

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.

How a Permissionless HIP-4 Market Actually Functions

Permissionless HIP-4 markets move through five stages:

1. Choose an Approved Template

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.

2. Meet Deployer Requirements and Set Parameters

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.

3. Launch the Market for Trading

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.

4. Resolve the Outcome

Resolution follows one of two paths:

  1. 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.

  2. 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.

5. Settle Positions

Once resolved, HyperCore settles the market at its final value.

  1. Standalone markets: An authorized settler calls settleOutcome.

  2. 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?

HIP-4 Economics: Who Has to Make Money for a Market to Exist?

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.

1. Deployer

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.

2. Market Makers

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.

3. Traders

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?

Mapping the Risks of HIP-4 Deployment

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?

Does HIP-4 Make Hyperliquid a Real Alternative to Polymarket and Kalshi?

Although the three platforms seem to list and serve similar purposes, the reasons to trade on each still remain different.

Decision factor

Hyperliquid HIP-4

Polymarket

Kalshi

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

No

No

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?

Where Permissionless HIP-4 Goes From Here

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.

Getting Started Building on Hyperliquid With Quicknode

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:

  1. Hyperliquid API Overview, Quicknode Docs

  2. Hyperliquid Sentry Peering Explained: Setup, Cost, Options | Quicknode

  3. Build a Real-Time Hyperliquid Whale Alert Bot

  4. Read HyperCore Oracle Prices in HyperEVM

  5. Real-time risk monitoring and liquidation analytics API for HyperLend Protocol on Hyperliquid

  6. Comparison of the top 6 Hyperliquid RPC providers for HyperCore and HyperEVM

SDKs and Tools

Hyperliquid Python SDK (also on PyPI), Hyperliquid API Examples, Hyperliquid SDK Examples, HyperCore CLI, and hyperliquidapi.com.

Together, these resources give builders everything from RPC access to real-time event handling and offchain logic, making Quicknode the fastest path to launching apps, markets, and analytics on Hyperliquid.

FAQs on HIP-4 Permissionless Deployment

1. Can two deployers create markets for the same event?

Yes. Multiple deployers can use approved templates to create markets around the same event, potentially competing for liquidity and traders.

2. How do HIP-4 deployers make money?

Deployers can receive up to 50% of trading fees generated by their deployed outcome markets.

3. Do HIP-4 markets share liquidity with Hyperliquid perps?

No. They use HyperCore's trading infrastructure but maintain separate order books and need their own market liquidity.

4. Can infrastructure providers build on top of permissionless HIP-4 markets?

Yes. HIP-4 exposes market and deployment primitives that frontends, trading systems, market makers, and other infrastructure can integrate with.

5. Do traders get compensated if a HIP-4 settlement turns out wrong?

No. A slashed deployer bond is burned, not redistributed, so affected traders don't recover losses through that mechanism.

6. Can HIP-4 outcome markets be traded with leverage?

No. Every position is fully collateralized at open, with no leverage and no liquidation risk involved.

7. Is Hyperliquid, and HIP-4 by extension, open to US-based traders?

No. Hyperliquid remains geoblocked to US persons, independent of how permissionless the deployment process becomes.

About Quicknode

Founded in 2017, Quicknode deploys institutional-grade blockchain infrastructure for developers and enterprises. With 99.99% uptime and support for 77+ chains, teams build and scale onchain applications without compromise.

Start building today

Stay updated

The latest engineering insights, product updates, and web3 news delivered straight to your inbox.