HIP-4 Permissionless Deployment - Now Live on Hyperliquid Mainnet

Hyperliquid

Outcome Markets Have Gone Permissionless on Mainnet

Update, August 31, 2026: permissionless HIP-4 deployment is live on mainnet. Hyperliquid's weekly update confirmed the rollout, and the API backs it up. The mainnet template catalog, empty for the whole testnet period, now returns seven approved templates, and one deployer outside the protocol is already running markets under the venue name skew. The deployer actions API that had only worked against testnet now answers on api.hyperliquid.xyz.

The section below covers what the mainnet launch looks like in the data. The rest of this article documents the deployer rules, which carried over from testnet largely unchanged.

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 the Mainnet Launch Looks Like in the Data

Two API calls settle the question of where things stand. {"type":"outcomeTemplates"} against the mainnet info endpoint returns the approved catalog, and {"type":"outcomeMeta"} returns every live outcome, question and deployer. Both were free of any permissionless activity through July and August. Here is what they returned on August 31, 2026.

Seven Templates on Mainnet, and No Sports

Two things about that list repay a second read.

The mainnet catalog is a fraction of the testnet one. Testnet carried 55 templates on the same day, including seven separate sports families covering head-to-head fixtures, tournaments, draws and scalar sports markets. None of them made the mainnet cut. Validators approved price markets and central bank rate decisions for real money and left everything sporting on the test network. If you were planning a business on HIP-4 sports markets, the deployment machinery is live but the templates you need are not.

Mainnet template IDs carry no version suffix. Testnet has iterated up through binaryPrice6 and sportsContestWinner7; mainnet approved plain binaryPrice, priceTouch and scalarPrice. The numbering did not carry across, so code ported from testnet cannot assume the IDs match. Nor are the specifications the old ones: mainnet's binaryPrice takes seconds and priceDescription keywords, which is the explicit TWAP window and price source that testnet only introduced at binaryPrice4. The mainnet catalog shipped the matured specification under the clean name.

The First Deployer Outside the Protocol

outcomeMeta lists two deployers on mainnet. One runs under the venue name out and holds the validator-deployed markets. The other is a third party running under the venue name skew, with seven live markets, all of them binaryPrice standalone outcomes.

Their choice of underlying is the part worth noticing:

Six of the seven reference xyz: markets, which is the prefix for trade.xyz, a HIP-3 builder-deployed DEX. The first permissionless outcome markets on Hyperliquid mainnet are therefore built on top of permissionless perpetuals: a HIP-4 deployer instantiating a template against a Nasdaq 100 and S&P 500 index perp that a HIP-3 deployer listed. Neither market required a validator to approve it.

Every one of the seven carries a deployerFeeScale of 1.0, the neutral setting where traders pay twice the base rate and the deployer keeps half. Nobody reached for the ceiling on mainnet the way testnet deployers did. Across the whole mainnet set, outcomeMeta returns 42 outcomes and 2 questions, 33 of the outcomes instantiated from templates.

Fees Are Switched On

The mainnet outcomeMeta response now carries a top-level feeScale of 1.0, a field that did not exist while outcome markets traded free. That is the network upgrade this article previously flagged as the gate on permissionless deployment: a deployer's fee share needs a fee to take a share of. Hyperliquid's stated target for the base rate is an average of half ordinary spot trading, charged on closes and settlements rather than on opening a position, with no maker rebates. See the HIP-4 outcome markets guide for how that charging model works in practice.

The Deployer Lifecycle

The deployer API is a working lifecycle, not a preview. Seven 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.

Rate Limits, Testnet Through Mainnet

Two caps apply, and the docs write both as variables with per-network values attached:

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

The August 14 announcement put numbers on the mainnet side of that ahead of launch. Mainnet is a staged rollout starting at 100 concurrent outcomes and 500 outcome deployments per day per deployer, and Hyperliquid expects those to move up "quickly" to 1,000 concurrent and 5,000 per day once the tech is stable. A design for further increases comes after that, based on feedback.

The daily deployment cap is the number worth sitting with, because it is the one the original July proposal never mentioned. A concurrency cap of 100 says how big a book you can carry. A cap of 500 deployments per day says how fast you can churn it, and churn is the whole business model for recurring markets. A deployer running daily binaries on 100 assets burns 100 deployments every 24 hours just to keep the lights on. At the 5,000 target that becomes a rounding error, but at 500 it is a fifth of the budget, so the first wave of mainnet deployers will have to choose between breadth and turnover.

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:

Every value is capped at 100 characters and cannot contain {, }, or |, since those are the characters the protocol uses to encode the instantiation into the outcome's description string.

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.

shortString and Why Side Names Matter

The shortString hint looks like a trivia detail until you see where it is used. It caps a value at 10 characters, and templates put it in the side names, the labels for the two halves of a market. The live sportsContestWinner3 template on testnet declares its sides as {shortNameA} and {shortNameB} rather than the usual Yes and No.

That gives front-ends something they could not reliably do before. A market on a football fixture can render buttons that say the two team names instead of Yes and No, and an interface can trust that whatever comes back fits in a button, because the type hint guarantees it. Hyperliquid's own framing is that the hint "appears in templated side names so that interfaces can make useful assumptions about the respective fields." Ten characters is a UI constraint written into the protocol, which is an unusual place to put one, and it tells you the team is thinking about how these markets get displayed rather than only how they settle.

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.

Settlement Details No Longer Live Onchain

One change in the August 14 release will only bite people running infrastructure. Settlement details are now pruned from L1 state. The details field on settleOutcome has to be empty, and the announcement is direct about the consequence: applications depending on node API servers or read precompiles "could separately index settlement details if needed in perpetuity."

Read that as a warning rather than a footnote. If your product shows a user why a market resolved the way it did, or a HyperEVM contract reads settlement data through a precompile, that information is no longer guaranteed to be sitting in chain state when you go looking for it. You have to capture it at settlement time and keep your own copy. State growth is a real constraint for a chain that expects thousands of outcomes per day, so pruning is the right call, but it moves the archival burden onto everyone building on top.

Questions Can Now Grow After They Launch

The single biggest change on August 14 is the new registerAndAssociateNamedOutcomeFromTemplate action. Until then, a question's outcome set was frozen at creation, which this article flagged in July as the awkward gap in the design. An election question deployed before the candidate list was final could not absorb a late entrant, so a deployer had to either wait or settle the market and start over.

Now a deployer can hand a live question a new named outcome, and the fallback mechanism does the accounting.

What Happens to Existing Holders

Every HIP-4 question carries a fallback outcome, the "none of the above" bucket that pays out when the result is not one of the named ones. When a new named outcome is attached, the protocol gives holders of fallback YES tokens an equal balance of the new outcome's YES tokens. The announcement puts it as "the initial balances of the new named outcome match the outstanding fallback balances."

That is the correct answer rather than a convenient one. Before the addition, the fallback covered the new candidate plus everything else, so a fallback YES holder already owned the claim that pays out if that candidate wins. Splitting the candidate out of the fallback and handing those holders the matching new tokens preserves exactly the exposure they bought. Nothing is minted against the collateral pool, nobody's position is diluted, and no repricing event is forced on the book.

What It Does Not Change

Two constraints survive. The new outcome inherits the question's deployerFeeScale rather than setting its own, so a deployer cannot quietly attach an expensive outcome to a cheap question. And each added outcome consumes another slot from the deployer's concurrency allocation, so growing a question is not free against the 100-outcome mainnet cap.

The Deployer Fee Scale

The July release shipped without configurable fees, and this article listed them as a follow-up. They arrived on August 14. Every template instantiation, for both questions and standalone outcomes, now carries a deployerFeeScale: a decimal string bounded between 0 and 10.

The formula is the same shape HIP-3 uses for builder-deployed perps. Traders pay:

base fee x (scale + max(scale, 1))

and the deployer keeps the scale component of that. Below a scale of 1 the deployer's cut is scale / (1 + scale); at 1 and above it settles at a flat 50%, with the extra multiplier going to the protocol alongside the deployer.

The scale applies uniformly to a question and all of its outcomes, so a deployer picks one number per market rather than tuning each bucket.

Why the Ceiling Is 10 and Not 3

HIP-3's scale caps at 3 and has a floor of 0.1. HIP-4's runs from 0 to 10. Same formula, very different range, and the reason is that the two are multiplying different base numbers.

Outcome trading charges a fee only when a position is closed or settled, never when it is opened, and the base rate itself is set to average half of ordinary spot trading. A perp taker fee starts at 0.045% and gets charged on the way in and the way out. So a 10x multiplier on the outcome base and a 3x multiplier on the perp base end up closer together in dollar terms than the raw numbers suggest. The wider range also gives deployers room at the bottom: a scale of 0 is legal on HIP-4 and impossible on HIP-3, which lets a front-end run a market at pure protocol cost to bootstrap it.

Testnet deployers are already using the range. Pulling the live outcome metadata on August 14 showed instantiated scales of 1.0, 5.0, 7.6, and 10.0 across the markets deployed since the upgrade, so at least one operator went straight to the ceiling. That is a sandbox with no real users on it, and I would not read a mainnet pricing strategy into it, but it does confirm the whole range is callable.

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.

The Template Catalog, and How It Versions

The July release shipped with price templates and little else. Querying the live catalog on August 14 ({"type":"outcomeTemplates"} against the testnet info endpoint) returns 14 templates, and the additions go well beyond price.

scalePrice is the one to notice. Long tokens pay $1 if the price finishes at or above the high, $0 at or below the low, and a pro-rata fraction in between, with Short paying the remainder. That is a genuinely scalar payoff rather than a binary, and it is the first template that matches the "bounded options-like instrument" language in the original HIP-4 spec. The policyRateDecision family is the other notable one, because a Fed or ECB decision resolves against a published number from an official source rather than an onchain price, which is the class of market that used to require canonical validator deployment.

Templates version by numeric suffix, and old versions are deprecated. The announcement states the rule plainly: template IDs are suffixed with an index, and all but the largest index in each series count as deprecated. So binaryPrice4 supersedes binaryPrice2 and binaryPrice, and sportsContestWinner3 supersedes the two before it. Interestingly binaryPrice3 does not appear in the catalog at all, so the series is not guaranteed to be contiguous. Always read the current highest index rather than assuming the numbering.

The version bumps are not cosmetic. binaryPrice typed its threshold as a free-text string; binaryPrice2 tightened that to uDecimal; binaryPrice4 added an explicit TWAP window and a price-source description, so settlement now reads "according to the 300-second TWAP of mark price before settlement time" instead of leaving the reference implicit. Template versioning is how Hyperliquid patches ambiguity in settlement language without touching markets that are already trading. Descriptions also now end with a metadata=category:...|subCategory:... tag, which is how a front-end sorts markets into Crypto, Sports, and Economics tabs without parsing the question text.

What Happens to Canonical Markets

Under the validator-deployed model that ran until August 2026, canonical outcome markets - deployed and settled directly by validators - were the main event. Permissionless deployment flips that. 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

A 50% Ceiling on the Deployer's Cut

HIP-4 deployers keep at most 50% of the fees their markets generate, the same ceiling HIP-3 builders hit on perps. The deployer fee scale is how they choose where to sit under it: anything from 0, taking nothing, up to 10, where traders pay twenty times the base rate and the deployer still keeps half of it. This is the core economic incentive, and since August 14 it is configurable rather than a promise.

That prerequisite has cleared. Outcome markets on mainnet charged nothing at all until the network upgrade that enabled fees on validator-deployed markets, which Hyperliquid framed at the time as preparation for deployer fee scales. The plumbing that collects an outcome fee had to exist before there was anything for a deployer to take a share of, and mainnet outcomeMeta now returns a top-level feeScale confirming it does.

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, and since the September 3, 2026 announcement of HIP-3* they will also be able to opt into an onchain allowlist over who trades on them. HIP-4 has no equivalent control announced. 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.
• The deployer fee scale. This is the newest item on the list and the easiest to overlook. The scale runs from 0 to 10, and at the top end you are paying twenty times the base outcome fee. Two deployers running the same template can price it an order of magnitude apart.
• Which template it instantiates, and which version. Confirm the market is built on a validator-voted template and read the exact settlement question. Check the suffix too: binaryPrice4 spells out its TWAP window while the original binaryPrice left the reference price implicit, and only the highest index in a series is current.
• 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.
• Fee scales are set by the deployer, not the protocol. A market can legally charge twenty times the base outcome fee. The scale is visible in the market's metadata, so this is checkable rather than hidden, but nothing caps it below the maximum.
• The mainnet market set is very young. Seven permissionless markets from one deployer is not a marketplace yet, and six of them settle on the same afternoon. Early markets on a new venue tend to trade thin, and a binary that settles in four days gives you little room to wait out a bad entry. Treat the current lineup as a first cohort rather than as a liquidity pool.

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
• Second feature drop: August 14, 2026 - adding outcomes to a live question, the 0 to 10 deployer fee scale, the shortString type hint, settlement details pruned from L1 state, sports and policy-rate templates, and the staged mainnet limits published
• Outcome fees enabled on mainnet: the network upgrade that switched fees on for validator-deployed markets, the stated prerequisite for deployer fee scales
• Permissionless deployment on mainnet: week ending August 31, 2026 - seven approved templates, deployer actions callable against api.hyperliquid.xyz, first outside deployer live
• Next: the allocation-expansion auction, and whatever the validator vote adds to the mainnet template catalog

Adoption is worth watching on both networks, because they say different things. Querying outcomeMeta on August 31, 2026 returned 78 deployers, 486 outcomes and 73 questions on testnet against 2 deployers, 42 outcomes and 2 questions on mainnet. Testnet is where deployers stress the feature set; mainnet is where validators have so far let a narrow, price-focused slice of it out. The gap between those two numbers is the best available read on how cautiously this is being rolled out.