# HIP-4 Permissionless Deployment - Now Live on Hyperliquid Testnet

> HIP-4 permissionless deployment is live on testnet. Deployer actions, the 0-10 deployer fee scale, validator-voted templates, settlement rules, and the staged mainnet limits.

*Source: https://hyperliquidguide.com/ecosystem/hip-4-permissionless-deployment*

## 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](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/hip-4-deployer-actions) 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.

> **Note:** **Update, August 14, 2026.** The follow-up features Hyperliquid promised have landed on testnet, and they are substantial. Deployers can now add named outcomes to a question that is already trading, every template instantiation carries a configurable `deployerFeeScale` bounded between 0 and 10, a `shortString` type hint lets templates name the two sides of a market something other than Yes and No, and settlement details are pruned from L1 state. The template catalog also grew past price markets into sports and central bank rate decisions. Most importantly for anyone planning a business on this, the mainnet limits are now public: **100 concurrent outcomes and 500 deployments per day per deployer at launch**, expected to rise to 1,000 and 5,000. Each of these is covered in its own section below.

That moves [HIP-4 outcome markets](/ecosystem/hip-4-outcome-trading) 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."

> **Key takeaway:** HIP-4 permissionless deployment is **live on testnet as of July 31, 2026**. Deployers stake HYPE and instantiate validator-voted templates to launch outcome markets with no gas cost and no auction. It is the outcome-market analog of [HIP-3 builder-deployed perps](/ecosystem/hip-3-builder-codes): the same 500k HYPE bond, the same 50% fee share, the same 6-month stake lock. Mainnet follows once the testnet feature set fills out.

![Hyperliquid Outcomes page showing the validator-deployed daily binary markets on BTC, HYPE, ETH, and SOL alongside a multi-outcome BTC price range question](/images/ecosystem/shared/hyperliquid-outcomes-page.webp)

*The Outcomes tab on **[app.hyperliquid.xyz](https://app.hyperliquid.xyz/join/Concept211)** today. Every market shown here was deployed by validators. Permissionless deployment is what lets anyone else add to this list.*

> **Warning:** **Testnet parameters are not mainnet parameters.** The docs label the current rate limits as testnet values, and the 500k HYPE stake comes from the original mainnet proposal rather than from what runs on testnet today. The August 14 announcement did firm up two things: fees are now configurable and the mainnet concurrency and daily deployment caps are published. Everything else can still move before the mainnet upgrade.

---

## What Shipped on Testnet

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

| Action | What it does |
|---|---|
| `activateOutcomeDeployer` | Register as an outcome deployer under a venue name |
| `deactivateOutcomeDeployer` | Step down as a deployer |
| `registerStandaloneOutcomeFromTemplate` | Deploy a single YES/NO market from a template |
| `registerQuestionFromTemplate` | Deploy a question with several named outcomes |
| `registerAndAssociateNamedOutcomeFromTemplate` | Add a named outcome to a question that is already live (added August 14, 2026) |
| `settleOutcome` | Settle one outcome |
| `settleQuestion2` | Settle every remaining outcome on a question at once |

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](/ecosystem/hyperliquid-auctions-explained). 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 testnet 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 finally put numbers on the mainnet side of that. Mainnet launches as a staged rollout with **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.

| Limit | Testnet today | Mainnet launch | Mainnet target |
|---|---|---|---|
| Concurrent outcomes per deployer | 10 | 100 | 1,000 |
| Outcome deployments per day | 50 | 500 | 5,000 |

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:

| Keyword type | Accepts |
|---|---|
| `dateTime` | A timestamp as `%Y%m%d-%H%M`, within the next year |
| `date` | A calendar date as `YYYYMMDD`, within the next year |
| `string` | Free text |
| `shortString` | Free text of at most 10 characters (added August 14, 2026) |
| `hlPerp` | A Hyperliquid perp market, such as `BTC` |
| `uInt` | A nonnegative integer |
| `uDecimal` | A nonnegative decimal |

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](/ecosystem/hyperliquid-multi-outcome-markets) 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](/ecosystem/hyperevm-explained) 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.

> **Key takeaway:** Adding an outcome to a live question is not a rewrite of the market. It carves a named bucket out of the fallback and gives fallback holders the carved-out piece, so a question can absorb a late candidate without settling early or diluting anyone. This is what makes election-style and any-of-N markets practical on HIP-4.

### 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](/ecosystem/hip-3-builder-codes) 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.

| `deployerFeeScale` | Trader pays | Deployer keeps |
|---|---|---|
| 0 | 1x base | 0% |
| 0.5 | 1.5x base | 33.3% |
| 1 | 2x base | 50% |
| 5 | 10x base | 50% |
| 10 (max) | 20x base | 50% |

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.

> **Warning:** A scale of 10 means traders pay **twenty times** the base outcome fee on that market. Nothing stops a deployer from setting it. Before you trade a permissionless outcome market, check the market's fee scale the same way you would check the spread, because two instances of the same template can differ by more than an order of magnitude on cost.

---

## 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](/ecosystem/hip-4-outcome-trading), then ETH/HYPE/SOL dailies, then [canonical markets on offchain events](/ecosystem/hyperliquid-canonical-outcome-markets) - 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.

> **Note:** Templates draw a clean line of responsibility. The **template** defines the shape and settlement criteria of a valid market; **validators** decide which templates are allowed. The **deployer** is then responsible for defining and settling each individual market in accordance with the settlement criteria specified in that template's instantiation. Get the settlement wrong and the stake is at risk (see slashing below).

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

| Template family | Role | Covers |
|---|---|---|
| `binaryPrice`, `binaryPrice2`, `binaryPrice4` | Standalone | Will a perp trade above a threshold at a given time |
| `scalePrice` | Standalone, sides named Long and Short | Scalar payout that scales linearly between a low and a high price |
| `sportsContestWinner`, `sportsContestWinner2`, `sportsContestWinner3` | Standalone | Head-to-head result of a single fixture |
| `sportsContestResult` + `sportsContestParticipant` / `sportsContestDraw` | Question + outcomes | Three-way sports result including a draw |
| `policyRateDecision` + `policyRateNoChange` / `policyRateDecrease` / `policyRateIncrease` | Question + outcomes | Central bank rate decisions |

`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](/ecosystem/hyperliquid-canonical-outcome-markets).

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

> **Note:** Mainnet returns an empty template list today. Templates only exist on testnet, which is the cleanest single check that permissionless HIP-4 has not shipped to mainnet yet. When `outcomeTemplates` starts returning entries on `api.hyperliquid.xyz`, the mainnet rollout has begun.

### What Happens to Canonical Markets

Under the current validator-deployed model, [canonical outcome markets](/ecosystem/hyperliquid-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](/ecosystem/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.

> **Warning:** Long-dated outcomes are a double-edged sword for deployers. They can be popular markets, but every open market blocks unstaking and extends slashing exposure. A deployer who fills their allocation with multi-year questions effectively locks their 500k HYPE and their operational obligations until those questions resolve. Size the book accordingly.

### 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](/ecosystem/hyperliquid-multi-outcome-markets)) 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](/ecosystem/hyperliquid-auctions-explained) that governs additional HIP-3 market slots

**Get Ready to Trade Outcome Markets** — Outcome trading is already live on Hyperliquid, and permissionless deployment will multiply the markets on offer. Set up your account now with our referral code and lock in a 4% lifetime fee discount across perps, spot, and outcome contracts. [Create Account with 4% Off](https://app.hyperliquid.xyz/join/Concept211)

---

## 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](#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.

One prerequisite is still pending. Outcome markets on mainnet charge **no fees at all** today, and the announcement says validator-deployed outcome markets will "have fees enabled" on the next network upgrade specifically in preparation for deployer fee scales. The plumbing that collects an outcome fee has to exist on mainnet before there is anything for a deployer to take a share of, so that upgrade is the real gate on permissionless HIP-4 reaching mainnet.

### AQAv2 Quote Tokens Only

As previously announced, **only AQAv2 quote tokens are eligible for HIP-4**. Under the [AQAv2 aligned-quote-asset spec](/ecosystem/aqav2-usdc-aligned-quote-asset), 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.

| Parameter | HIP-3 (Perps) | HIP-4 (Outcomes) |
|---|---|---|
| **Stake requirement** | 500,000 HYPE | 500,000 HYPE |
| **Stake lock** | 6 months | 6 months + settle all markets to unstake |
| **Max fee share** | 50% | 50% |
| **Fee scale range** | 0.1 to 3, set per asset | 0 to 10, set per question or standalone outcome |
| **Fee formula** | `base x (scale + max(scale, 1))` | Identical |
| **Slashing** | Malicious operation | Poorly defined, mis-settled, or unsettled >1 week |
| **What you deploy** | Perp markets on a DEX | Outcome markets from validator templates |
| **Initial allocation** | 3 free markets, then auction | 100 concurrent outcomes and 500 deploys/day, then auction |
| **Quote asset** | Various | AQAv2 quote tokens only (USDC) |
| **Quality gate** | Deployer's oracle + config | Validator-voted onchain templates |

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.

> **Tip:** If you already understand HIP-3, you understand most of HIP-4's deployment economics. Mentally map "builder code" to "deployer stake," "3 free markets" to "100-outcome allocation," and "run your own oracle" to "instantiate a validator template and settle it correctly." The 500k HYPE bond, the 6-month lock, the 50% fee ceiling, and the fee-scale formula itself are all shared. The one number that differs is the scale ceiling, 3 on HIP-3 against 10 on HIP-4.

---

## 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](/ecosystem/what-is-hype-token).** 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](/ecosystem/hip-3-builder-codes) already runs for perps.

> **Key takeaway:** Permissionless deployment is what scales HIP-4 to the full breadth of tradeable events. The template layer keeps quality high, the 500k HYPE bond and slashing keep deployers honest, and the 50% fee share gives them a reason to run good markets. Testnet is live and callable today. Mainnet economics are still a proposal, but the direction is set.

---

## 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](/markets) 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](/guides/trading/hyperliquid-xyz-explained).
- **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.
- **Testnet is not mainnet.** The deployer actions run on testnet with testnet rate limits. The 500k HYPE stake and the slashing terms come from the mainnet proposal and can change before the upgrade. Mainnet outcome markets also charge no fees at all until the network upgrade that switches them on, so today's live economics are not the ones you will trade under.

> **Tip:** Trade the deepest instance of a market, not the first one you find. When the same template is deployed several times, the version with the tightest spread and thickest book usually gives you a better all-in price than a headline fee number suggests.

---

## 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
- **Next**: the network upgrade that enables fees on validator-deployed outcome markets
- **Then**: mainnet permissionless deployment at 100 concurrent outcomes and 500 deploys per day, rising to 1,000 and 5,000, plus the allocation-expansion auction

There is still no firm mainnet date, but August 14 cleared the two items that were blocking one. Configurable fees have shipped and the live-question limitation is gone, which means the remaining gap between testnet and the mainnet proposal is mostly the numbers rather than the feature set.

Adoption on testnet is real enough to be worth watching. Querying `outcomeMeta` on August 14 returned **47 registered deployers across 38 venue names, 321 outcomes and 45 questions**, with 184 of those outcomes instantiated from templates. The same query against mainnet returns 8 outcomes, 1 question, and zero deployers, which is the validator-deployed set and nothing else. That gap is the entire story of where HIP-4 sits right now.

**Start Trading on Hyperliquid Today** — Perps, spot, and outcome markets - all on one composable platform, with permissionless outcome deployment on the way. Use our referral code for a 4% lifetime fee discount across every product. [Claim Your 4% Fee Discount](https://app.hyperliquid.xyz/join/Concept211)

> **Note:** This article is for educational and informational purposes only. It does not constitute financial or investment advice. All HIP-4 permissionless deployment specifications described here are preliminary and subject to change. Staking, deploying, and settling outcome markets carries real financial and operational risk, including slashing of staked HYPE. Always do your own research and never stake or trade with more than you can afford to lose.