HIP-4 Permissionless Deployment - Deploy Outcome Markets on Hyperliquid

Hyperliquid

Outcome Markets Are Going Permissionless

Hyperliquid has laid out how HIP-4 outcome markets will move from validator-deployed to permissionless deployment. In a future network upgrade - testnet first, then mainnet - any qualified entity will be able to deploy their own outcome markets by staking HYPE and instantiating validator-approved templates, without waiting for validators to deploy each market by hand.

This is the same arc Hyperliquid has run before. Spot tokens and perpetual futures both started life as validator-deployed primitives and only opened to permissionless deployment once the technology had been battle-tested in production. Outcome markets are now walking that same path. As the team put it, the technology "required sufficient battle testing in a validator-deployed setting before scaling to permissionless deployment."

Pictured: HyprFlip - a non-custodial binary outcome market built on Hyperliquid. Permissionless deployment is what lets front-ends like this eventually launch their own markets rather than trading only validator-deployed ones.

Why Permissionless Matters More for Outcomes Than for Perps

Permissionless deployment matters for every Hyperliquid primitive, but it matters most for outcome markets. The reason is simple math about how many markets there could be.

A perpetual or a spot token needs an underlying asset. There are only so many liquid assets in the world worth listing. Outcome markets are different: the universe of tradeable events is effectively unbounded. Every sports fixture, every election, every protocol milestone, every macro print, every "will X happen by date Y" question is a candidate market. As Hyperliquid notes, "the number of suitable discrete events for outcomes dwarfs the number of underlying assets for perps and spot tokenization."

Validators deploying every one of those by hand does not scale. That is exactly why HIP-4 launched with a small set of validator-run markets - a recurring binary BTC contract, then ETH/HYPE/SOL dailies, then canonical markets on offchain events - and why the endgame has always been permissionless deployment. The validator-deployed phase was the proving ground. Permissionless deployment is how the primitive reaches the full breadth of events people actually want to trade.

Validator-Voted Templates: The Quality Gate

Opening deployment to anyone raises an obvious risk: badly defined, ambiguous, or manipulable markets. Hyperliquid's answer is outcome templates.

Rather than letting deployers write arbitrary market definitions, validators vote to approve a set of templates that deployers must build on. The mechanics:

• Onchain specifications - the specification for each template is stored and enforced onchain, not left to a front-end or off-chain agreement
• Validator-curated - validators vote on which templates exist; the set is meant to reflect outcomes tied to events with sufficient liquidity and interest
• Public-goods standard - templates are constrained by validator vote to be healthy, unambiguous public goods for the ecosystem, not niche or gameable questions
• Open instantiation - each HIP-4 deployer can instantiate any approved template as the basis for their own markets
• No exclusivity - there is no restriction against multiple deployers deploying the exact same template instantiations

That last point is important. Templates are not land grabs. Two deployers can both launch the same market from the same template, competing on liquidity, front-end, and fee share rather than on who got there first.

What Happens to Canonical Markets

Under the current validator-deployed model, canonical outcome markets - deployed and settled directly by validators - are the main event. Permissionless deployment flips that. Once it is live, canonical markets "may still be deployed directly by validators from time to time, but these are expected to be rare." How rare? Determined by validator vote, and "ideally will represent fewer than 10 outcomes or questions per year."

In other words, canonical validator deployment becomes reserved for a handful of marquee events per year, while the long tail of markets flows through permissionless deployers instantiating templates.

The Deployer Requirements

If you want to deploy HIP-4 outcome markets, here is what the current proposal asks of you. The parallels to HIP-3 builder codes are deliberate.

500,000 HYPE Stake

The staking requirement for HIP-4 deployers is 500,000 HYPE - identical to the HIP-3 bond for builder-deployed perpetuals. This is a security bond, not a fee. It stays staked and aligns the deployer's incentives with the health of the markets they run.

Slashing for Bad Markets

The stake is subject to slashing by validator vote in three specific cases:

1. Markets that are poorly defined
2. Markets settled incorrectly according to the template
3. Markets that remain incorrectly unsettled for more than one week

That third condition is the one long-dated markets have to watch. Deploying a market that resolves years out means carrying settlement responsibility - and slashing exposure - for the entire life of the contract.

Six-Month Lock and Settle-to-Unstake

As with HIP-3, deployer stake is locked for 6 months. But there is an extra condition unique to outcomes: to unstake, a deployer must settle all of their markets first. You cannot walk away from open markets and reclaim your bond. Hyperliquid explicitly flags that this means "particular consideration should be given to very long dated outcomes" - a market that settles in two years keeps your capital committed and your settlement duty live until it resolves.

Allocation: 100 Outcomes to Start

Initially, each deployer gets an allocation of 100 outcomes (200 outcome tokens). The details that matter:

• Multi-outcome questions consume multiple outcomes - a "question" with several buckets (like a multi-outcome BTC range market) draws down more of the 100 than a simple binary
• Settled outcomes free their allocation - when an outcome settles, its slot is returned and can be reused, so the 100 is a cap on concurrent live outcomes, not lifetime deployments
• Expansion via auction - an auction mechanism to expand a deployer's allocation beyond 100 is planned as a follow-up feature, echoing the Dutch auction that governs additional HIP-3 market slots

Fees and Settlement Asset

Up to 50% Fee Share

HIP-4 deployers will be able to set up to a 50% fee share on the markets they deploy - the same maximum as HIP-3 builders earn on their perps. This is the core economic incentive: run popular, well-settled markets and keep half the trading fees they generate. Full fee configurability is planned as a follow-up feature, so expect the initial release to be simpler than the eventual system.

AQAv2 Quote Tokens Only

As previously announced, only AQAv2 quote tokens are eligible for HIP-4. Under the AQAv2 aligned-quote-asset spec, that means markets settle in the aligned quote asset - USDC for canonical markets - rather than an arbitrary token. This keeps outcome markets denominated in assets the ecosystem has blessed for quality and liquidity, and it is the same denomination the existing validator-deployed HIP-4 markets already use.

HIP-4 Permissionless vs HIP-3 at a Glance

The two permissionless-deployment regimes rhyme closely. The table below lines up the parameters that carry over and the ones unique to outcome markets.

The big structural difference is the template layer. HIP-3 deployers largely define their own markets and are trusted to run a sane oracle. HIP-4 deployers must build on validator-approved templates, because an ambiguous outcome market is far more dangerous than an ambiguous perp - there is a discrete settlement event where someone wins and someone loses, and "what exactly did this market mean?" has to have an unarguable answer.

What This Means for the Ecosystem

Permissionless HIP-4 deployment is the piece that turns outcome trading from a curated set of markets into an open marketplace.

For builders and front-ends. Apps like HyprFlip currently surface validator-deployed markets. Permissionless deployment means a front-end with 500k HYPE staked could launch its own markets from approved templates - choosing which events to list, earning up to half the fees, and differentiating on UX rather than waiting for a validator to deploy the market it wants.

For traders. More deployers instantiating more templates means a far wider menu of events to trade, and competing deployments of the same template mean markets compete for your liquidity on fees and depth. The template requirement is a feature here - it is what keeps the growing menu from filling up with ambiguous or gameable questions.

For HYPE holders. Every deployer locks 500,000 HYPE for at least six months, adding sustained staking demand as the deployer set grows. And every deployed market feeds trading fees into the protocol's economics, the same flywheel HIP-3 already runs for perps.

Timeline and Status

Where HIP-4 permissionless deployment sits as of July 2026:

• HIP-4 announced: February 2, 2026
• Mainnet binary launch: May 2, 2026 - recurring binary BTC outcome, validator-deployed
• Multi-outcome markets: May 7, 2026 - questions, split, negate, merge
• Canonical outcome markets: May 25, 2026 - validators deploy markets on offchain events
• Recurring outcomes expand: June 2026 - ETH, HYPE, SOL dailies join BTC
• Permissionless deployment: announced July 2026 - specifications published as preliminary; ships on testnet first, then mainnet, in a future network upgrade
• Follow-up features: allocation-expansion auction, full fee configurability

There is no firm launch date. Hyperliquid will announce once permissionless deployment is live on testnet and the docs are updated. Until then, the parameters here are the current proposal and can change based on feedback.

Frequently Asked Questions

What is HIP-4 permissionless deployment?

HIP-4 permissionless deployment lets any qualified entity deploy their own outcome markets on Hyperliquid without needing validator approval for each market. It is the outcome-market equivalent of HIP-3 for perpetuals. Instead of validators deploying every prediction market by hand, deployers stake HYPE and instantiate validator-approved templates to launch markets themselves. It rolls out on testnet first, then mainnet, in a future network upgrade. Get a 4% fee discount on Hyperliquid

How much HYPE do I need to deploy HIP-4 outcome markets?

The staking requirement for HIP-4 deployers is 500,000 HYPE - the same bond as HIP-3 builder-deployed perpetuals. The stake is locked for 6 months and is subject to slashing by validator vote if markets are poorly defined, settled incorrectly according to the template, or left incorrectly unsettled for more than one week. To unstake, a deployer must first settle all of their markets.

What are HIP-4 outcome templates?

Outcome templates are validator-approved specifications that define what a valid, well-formed outcome market looks like. Validators vote on templates, and the specifications are stored and enforced onchain. HIP-4 deployers use these templates as the basis for their permissionless deployments, and each deployer can instantiate any approved template. Templates exist to keep markets high-quality, unambiguous, and liquid, since the universe of possible tradeable outcomes is effectively unlimited.

How many outcome markets can one HIP-4 deployer launch?

Initially, each deployer has an allocation of 100 outcomes (200 outcome tokens). Multi-outcome questions can consume multiple allocated outcomes at once. When an outcome settles, its allocation is freed and can be reused, so the cap is on concurrent live outcomes rather than lifetime deployments. An auction mechanism to expand a deployer's allocation beyond 100 is planned as a follow-up feature.

Will validators still deploy outcome markets after permissionless launch?

Yes, but rarely. Canonical markets may still be deployed directly by validators from time to time, decided by validator vote, but these are expected to represent fewer than 10 outcomes or questions per year. The vast majority of outcome markets are expected to come from permissionless deployers instantiating validator-approved templates, with canonical validator deployment reserved for a small number of high-profile events.