HIP-4 Permissionless Deployment - Now Live on Hyperliquid Testnet

Hyperliquid

Outcome Markets Have Gone Permissionless on Testnet

Update, July 31, 2026: the initial implementation of HIP-4 permissionless deployments is live on Hyperliquid testnet. The deployer actions API is documented and callable, so anyone running against testnet can activate as a deployer, instantiate a validator-voted template, and settle their own markets. Mainnet has not shipped. Hyperliquid said additional features will roll out iteratively, including configurable fees and more testnet templates, and asked for feedback in the meantime.

That moves HIP-4 outcome markets from validator-deployed to permissionless deployment, the same arc Hyperliquid ran with spot tokens and perpetual futures. Both started as validator-deployed primitives and only opened up once the technology had been battle-tested in production. As the team put it, the technology "required sufficient battle testing in a validator-deployed setting before scaling to permissionless deployment."

The Outcomes tab on app.hyperliquid.xyz today. Every market shown here was deployed by validators. Permissionless deployment is what lets anyone else add to this list.

What Shipped on Testnet

The testnet release is a working deployer lifecycle, not a preview. Six actions cover it end to end.

Two things stand out immediately. Deploying has no gas cost, and there is no auction gate of the kind that governs HIP-3 market slots. Capacity is managed with rate limits and the staking requirement instead of with a price.

Testnet Rate Limits

Two caps apply, and the docs write both as variables with testnet values attached:

• At most 10 active outcomes per deployer (N=10 on testnet)
• 50 deployments per day (M=50 on testnet)

The 10-outcome cap is much tighter than the 100-outcome allocation described in the original mainnet proposal, which is what you would expect from a sandbox. Read them as parameters chosen to keep testnet tidy, not as a downgrade of the mainnet plan.

The Staking Requirement in Practice

The docs frame staking as a condition rather than a one-time payment. A deployer "must maintain the staking requirement for as long as it remains an outcome deployer," with a 183-day minimum stake duration, which is the six-month lock the July proposal described. Staking requirements also stack with any other deployer obligations, so an entity already running a HIP-3 perp DEX does not get to reuse the same bond for outcome deployment.

How Templates Are Instantiated

Validators vote templates into existence and deployers fill in the blanks. A template carries display text with {keyword} placeholders, and each placeholder has a type hint the instantiation has to satisfy:

Templates come in three roles: a standalone outcome, a question container, and a question outcome. That structure is what lets one template produce both a simple binary market and a multi-outcome question with several named buckets.

The hlPerp type is the interesting one. It ties an outcome market directly to a listed perp, which is the machinery behind the recurring BTC, ETH, HYPE, and SOL dailies. A deployer picks the perp and the expiry and the template handles the rest.

Settlement Rules

Settlement takes a fraction in the range 0 to 1. Standalone outcomes accept any fraction in that range, which allows partial or scalar resolution. Outcomes that belong to a question are stricter: they must settle to exactly "0" or "1", because a question's outcomes have to sum to a single winner. Settling the final named outcome triggers fallback settlement for whatever is left, and settleQuestion2 does the whole set in one call.

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. Any app that surfaces outcome markets is currently limited to the validator-deployed set. 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.

What Permissionless Deployment Means for You as a Trader

For traders, permissionless HIP-4 does two things: it widens the menu of outcome markets you can trade, and it gives you a choice between competing versions of the same market. When several deployers instantiate the same validator-approved template, such as a recurring BTC daily, you can route to whichever instance offers the tighter spread and deeper book at a lower net fee. The catch is that an open menu also fills with thinner, newer markets, so choosing which market to trade starts to matter as much as choosing a direction.

Because every deployer earns up to half the fees on their own markets, expect them to compete for your order flow. That competition works in a taker's favor: it pushes deployers to seed liquidity and keep fees keen on the markets they want you to use. It also means a headline like "the HIP-4 market for event X" can exist several times over, and those instances are not interchangeable. You can watch the current lineup of live perps and outcome markets on the markets page as the deployer set grows.

How to Evaluate a Newly-Deployed Market Before Trading It

Before you put real size into a freshly-listed permissionless market, run through a short checklist:

• Order-book depth and spread. Pull up the book and check how far your intended size walks the price. A market can post real 24-hour volume and still have a thin resting book between bursts. Size to the depth you actually see, the same discipline that applies to thin equity and commodity perps on trade.xyz.
• Which template it instantiates. Confirm the market is built on a validator-voted template and read the exact settlement question. The template layer is the quality gate, so a market that does not map cleanly to an approved template is a red flag.
• Settlement criteria. You should be able to state in one sentence what makes the market resolve YES or NO, and when. Ambiguity in the resolution source is the most common way outcome traders get caught out.
• Deployer track record. A deployer starts with an allocation of 100 outcomes and has 500,000 HYPE staked against slashing. One with a clean history and real skin in the game is safer to trade than an anonymous operator's very first market.
• Quote asset. HIP-4 markets settle in USDC under AQAv2. Confirm the collateral and settlement asset before you fund the position so there are no surprises on exit.

Risks and Due Diligence on Permissionless Markets

An open marketplace shifts more of the diligence onto the trader. The template layer and the deployer bond remove the worst outcomes, but they do not make every market equal.

• Thin liquidity on long-tail markets. The popular recurring markets, such as BTC, ETH, and HYPE dailies, will carry depth. A niche one-off event deployed by a single operator may not. Wide spreads and slippage on exit are the practical risk, especially outside peak hours.
• Oracle and settlement risk. Outcome markets resolve against a defined data source. If that source is ambiguous or disputable, settlement can turn contentious even when the template itself is sound. Read the resolution mechanics, not just the headline question.
• Quality and rug risk. Permissionless does not mean unvetted. The 500,000 HYPE bond and slashing are designed to punish bad-faith or mis-settled markets, but a deployer can still list a poorly-chosen market within the rules. Slashing compensates and deters. It does not guarantee you a good fill.
• Testnet is not mainnet. The deployer actions run on testnet with testnet rate limits. The stake amounts, allocation sizes, and fee splits described here come from the mainnet proposal and can change before the mainnet upgrade. Configurable fees in particular are still listed as a follow-up feature.

Timeline and Status

Where HIP-4 permissionless deployment sits as of August 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
• Permissionless deployment on testnet: July 31, 2026 - initial implementation live, deployer actions documented, 10 active outcomes and 50 deployments per day
• Next: configurable fees, more testnet templates, support for adding outcomes to a live question
• Then: mainnet, plus the allocation-expansion auction

There is still no firm mainnet date. The testnet release is explicitly an initial implementation with features arriving iteratively, and Hyperliquid asked for feedback during that window. Testnet parameters carry testnet values and the economic terms remain a proposal until the mainnet upgrade lands.