There is no single winner between HIP-3 builder-deployed perps and HIP-4 outcome markets, and you can meet the same 06:00 UTC BTC publication two ways. On a HIP-4 fully collateralized binary you buy dated Yes, and HyperCore's BTC mark writes the conversion, while on a HIP-3 levered builder perpetual the deployer writes the oracle and a dislocation can liquidate you beyond posted collateral.
Suppose you post 100 USDC for Yes on the protocol-run daily series: you do not select the target, and you do not publish the mark. On the other instrument you post 100 USDC isolated on a builder BTC perpetual someone listed against a similar settlement time, where the deployer defined that oracle and still publishes prices. The HIP-4 claim is the collateralized outcome in HIP-4 outcome markets.
Those two instruments share a published settlement time and split on the liquidation path.
How HIP-3 and HIP-4 compare
HIP-3 and HIP-4 both clear on HyperCore, and the choice between them is which contract you opened: oracle authorship, the loss path, how the market ends, and who is allowed to list remain separate obligations. The comparison table describes those axes as product facts, and it withholds a winner.
| Axis | HIP-3 | HIP-4 |
|---|---|---|
| Matching | HyperCore onchain book | Same HyperCore book |
| Oracle writer | Deployer defines and posts | Protocol BTC mark, first series |
| Loss beyond posted | Maintenance can wipe equity | Posted claim only |
| How it ends | HaltTrading settles to mark | Dated Yes/No conversion |
| Listing | Staked mainnet deployer | Deployer API still testnet |
| Official 500,000 HYPE stake | Yes, expected to decrease | Official spec names none |
| Fees | User tier plus deployer share | Close or settle when charged |
| Funding | Perp funding path | No funding |
What both products share on HyperCore
HIP-3 builder-deployed perpetuals and HIP-4 outcome markets both clear on HyperCore's onchain order book, so neither product is a hosted matcher and neither lives on HyperEVM gas. Sharing that venue is the start of the comparison, because oracle authorship and the loss path remain separate contractual obligations.
Independent research notes the overlap in one line: both share the same matching engine and order types, and HIP-4 uses fixed-range settlement, with no funding and no liquidation engine (source: Galaxy, HIP-4 research). Galaxy also publishes a HIP-4 builder-stake figure of 1,000,000 HYPE that the official deployer specification does not state, so keep the structural split and treat that 1,000,000 figure as Galaxy's research number, not as a protocol parameter.
What Hyperliquid is separates HyperCore from HyperEVM, and both of these products occupy the order-book half, so a fill still waits on the same HyperBFT sequencing that a validator-operated BTC perpetual waits on. Matching, rest, and cancel-before-GTC inside a batch are the same HyperCore mechanics, and the deeper explanation of that order book sits in how HyperCore works. Price-time priority on a rest stays in place when the ticker is a builder perpetual or a Yes token, and what changes is who is authorized to define the market and what the contract does when the mark moves against you.
A generic primer on spot versus perpetual futures still helps if open-ended mark-to-market is unfamiliar, and it still will not identify which HyperCore primitive you opened. Spot is holding the asset, and a perpetual is an open-ended contract with funding. HIP-4 is a dated collateralized claim, and HIP-3 is a builder perpetual that inherits that perpetual path, including borrowed notional, so mixing those four is how a centralized HYPE instrument gets treated as a daily binary.
The same order book and the same chain still host two contracts, so if an interface pastes a builder BTC perpetual next to the 06:00 Yes without naming the dex, determine which instrument you are on before you size it. How a rest is matched, including the second margin verification if the mark moves while an order sits, sits in how the Hyperliquid book works.
Who writes the oracle on each market
You do not author either oracle publication: on a HIP-3 builder-deployed perpetual the deployer defines the oracle and then publishes prices, and on the protocol-run HIP-4 BTC binary HyperCore's BTC mark writes settlement, so the same 06:00 UTC time is a shared event with two authors.
The HIP-3 specification locates that author on the listing operator. Market definition includes the oracle definition, and market operation includes publishing prices and settling if needed. You can determine who published the oracle, and you cannot override it from your isolated-margin bucket. The 500,000 HYPE listing stake, expected to decrease, is that deployer's slashable stake, and it is a listing requirement, not a rewrite of the oracle you are reading. The listing explanation sits in HIP-3 builder-deployed perps, because mixing those authors is how a builder publication gets blamed for a conversion it left unsigned.
Native HyperCore perpetuals still carry a validator publication path that HIP-3 leaves in place. The validators are responsible for publishing spot oracle prices for each perp asset every 3 seconds (source: Hyperliquid Docs, oracle). Those publications feed funding and mark on validator-operated books, and both of those facts hold together: validators still publish native marks, and a HIP-3 deployer still defines and publishes the oracle on that dex. The first HIP-4 series settles to HyperCore's BTC mark at 06:00 UTC, which is a protocol conversion instead of a deployer publication, so the first series asks you to read the protocol mark instead of a builder's definition.
Galaxy describes HIP-3 as a continuous oracle and HIP-4 as a single settlement publication, which should be treated as a shape and not as a 1% deviation rule, because the official HIP-3 specification does not state that band. On the builder perpetual you are reading a publication the deployer still has to operate. On the daily Yes you are reading a mark the protocol already publishes, so a page that says the oracle as if Hyperliquid had one author for every ticker has already lost the comparison.
The signer of the observation that can liquidate you is the operational split: a HIP-3 adverse dislocation can liquidate you on a deployer mark, while a HIP-4 adverse dislocation can only change whether Yes later converts to quote.
Who can lose more than posted collateral
Borrowed notional is how HIP-3 can take more than the collateral you thought you posted on that trade, and a HIP-4 Yes cannot, because the claim was already fully collateralized. The operational fork is whether a maintenance obligation exists on the tokens in your wallet.
Walk the 100 USDC as a liquidation path. On the HIP-4 instrument you still hold 100 USDC of Yes through a 02:00 UTC selloff. Each outcome market consists of two sides, each with a token (source: HIP-4: Outcome markets). Settlement converts those tokens without sending a market close to the order book to restore a maintenance ratio. If you are wrong at 06:00 you can lose the 100 USDC without being liquidated on the way there, because size is the Yes you hold instead of a larger BTC notional that expanded because the mark moved.
On the HIP-3 instrument the 100 USDC isolated is initial margin on borrowed notional, so the position is larger than the collateral in that bucket. If equity falls through maintenance, HyperCore attempts an order-book-first close, and if that is insufficient and a cross position hits backstop, remaining account equity can transfer with it. "In particular, if the trader has no isolated positions, the trader ends up with zero account equity." (source: Hyperliquid Docs, liquidations) Isolated confinement keeps the damage inside that bucket, whereas cross margin shares remaining account equity, so either way the loss can exceed the 100 USDC you pointed at this trade, because the contract had no cap at that post.
You can still be wrong on Yes and lose the posted claim, which is a different event from an order-book-first liquidation. A page that says both products use collateral and stops there has skipped the only quantity that changes your overnight path: collateralized claim versus borrowed notional.
The operational maximum-loss bound is the comparison: HIP-4's ceiling is the quote you posted, while HIP-3's ceiling, on cross, can be remaining account equity.
How each market ends: HaltTrading and dated conversion
A HIP-3 HaltTrading cancels that asset's order book and settles positions to the then-current mark, and a HIP-4 instrument ends when the protocol converts Yes and No on the dated settlement, so a stop on the market is two events. Your 06:00 Yes keeps waiting when a builder recycled a perpetual.
HaltTrading is the settling obligation on that HIP-3 asset. Market definition, including the oracle definition and contract specifications, is the listing obligation, and market operation, including setting oracle prices, leverage limits, and settling the market if needed, is the operating obligation. When that settling obligation fires as HaltTrading, "This cancels all orders and settles positions to the current mark price." (source: HIP-3: Builder-deployed perpetuals) Cancel, settle to mark, and optionally resume recycles the asset without a fresh auction. A halt on that dex leaves validator-operated BTC running and leaves a HIP-4 Yes unconverted, so your isolated builder perpetual can be settled to mark while your Yes still waits on 06:00 UTC, because the protocol-run series is not that dex's inventory. If you wanted a dated HIP-3 contract, halt-and-recycle is how some deployers list one, whereas if you wanted the daily binary you wanted the conversion, not a mark snapshot the deployer chose to call a halt.
The HIP-4 close is conversion, and a perpetual HaltTrading is a settle-to-mark. Yes becomes a settle fraction of quote and No becomes the remainder, and for the daily binary that fraction is 1 or 0. You can sell Yes before 06:00, which is a close on the order book, or you can hold through conversion, and neither path is HaltTrading, so an interface that shows settled on both instruments is using one verb for two state machines.
The 500,000 HYPE listing stake still leaves you uncompensated if the HaltTrading mark is a quantity you reject, because slashed deployer stake is burned. The trader residual of that burn sits in HIP-3 deployer slashing risk. Venue risk, token risk, and deployer risk are still three categories in whether Hyperliquid is safe, because a halt is a mark publication and not an insurance indemnity.
You do not need the auction-recycle hyperparameters, because the split is operational: HIP-3 can be ended by the deployer at mark, and HIP-4 is ended by the protocol at the dated settlement.
Listing rights and the 500,000 HYPE stake
The official 500,000 HYPE mainnet stake is HIP-3's listing requirement, expected to decrease, and the HIP-4 deployer API is still labeled Testnet-only, so a live daily binary is not proof that you can permissionlessly list a new outcome on mainnet.
HIP-3's 500k publication is current official text, with the specification's own hedge that the requirement should fall as the infrastructure matures, plus a 183-day maintain floor after dex deploy. Validators slash by stake-weighted vote, slashed HYPE is burned instead of being paid to traders, extra above the latest requirement can be unstaked, and the remaining required stake stays slashable through the 7-day unstaking queue, none of which is a HIP-4 parameter. The HIP-4 deployer page names a staking requirement that combines with other deployer stakes and does not double-count HIP-3 collateral, and it does not state 500k. Galaxy's 1,000,000 HYPE HIP-4 builder stake is the same class of collapse from the other direction, so follow the official silence.
Permissionless HIP-4 listing is still a testnet API, and HIP-4 deployer actions are labeled Testnet-only (source: Hyperliquid Docs, llms.txt). A frontend that shows the daily BTC market is not a deploy control. To keep markets high quality and well-defined, validators vote on outcome templates, which HIP-4 deployers use as the basis for permissionless deployments (source: Hyperliquid Docs, HIP-4 deployer actions). Templates are a quality gate for later permissionless listing, and they are not a claim that mainnet deploy is already open. Multi-outcome questions are named on the HIP-4 specification and are still outside the initial mainnet release, and a later changelog can move that line, but the line on the specification today has not moved.
One explainer treats HIP-4 as the same 500k HYPE bond, the same 50% fee share, and the same 6-month stake lockup (source: Hyperliquid Guide, HIP-4 permissionless deployment). Official deployer text does not state that quantity. Some explainers copy HIP-3's 500k onto HIP-4 as if one allocation listed both, or they treat a live Yes book as a listing right, which official text does not do. If you came to list a market, you wanted a testnet API and a template vote. If you came to trade the daily BTC binary, you wanted the protocol-run series. If you came to trade a builder perpetual, you wanted a staked HIP-3 dex and that dex's oracle.
The operational fence is the living official quantity: 500k is HIP-3's, and HIP-4's permissionless deploy control is still testnet.
Fees a holder actually meets
HyperCore users have one fee tier across perps, HIP-3 perps, and spot, and HIP-4 does not inherit that including-list as a charge event, so a perpetual taker card pasted onto a Yes instrument is the wrong schedule. Read the live fee line on the day you trade, because a testing waiver and a standing rule can both be true simultaneously.
For each user, there is one fee tier across all assets, including perps, HIP-3 perps, and spot (source: Hyperliquid Docs, fees). HIP-3 then adds deployer share on that book, including a 0-300% scale (0-100% in growth mode), and growth mode can cut protocol fees, rebates, and volume contributions by 90% on that HIP-3 perpetual. That reduction is a HIP-3 privilege with its own disjoint-market rule, and HIP-4 keeps its own fee event. HIP-4's own specification still says outcome fees are currently zero for initial testing, while the same fees page describes charging when you close or settle, not when you open, so do not bake a 97% fee claim onto either product.
Builder codes can still take a cut on HIP-4 sell orders that name a builder, the same way they do on spot, which is fee-on-flow, a separate invoice from a third market type and from the 500k listing stake. Do not treat a zero testing rate as a promise that close-or-settle stays off, and do not treat growth mode on a builder perpetual as a rebate on your Yes.
Suppose you buy 100 Yes while the testing line still reads zero, and in the same hour you pay taker on the HIP-3 BTC perpetual: those are two invoices. The Yes path, when fees apply, is a close or a conversion, whereas the perpetual path is the tier card plus whatever deployer share that dex configured, so a launch post that posts one schedule on both instruments is reading the wrong row.
Which product fits which use
Which product fits depends on the instrument you actually wanted: borrowed notional on a builder oracle, a posted dated claim on a protocol mark, or a HYPE instrument on an exchange book, and there is no winner among those three.
If you wanted overnight notional on a custom underlying, HIP-3 is the product, with the deployer stake and the liquidation path that come with it. If you wanted a bounded view on the daily BTC settlement, HIP-4 is the product, with conversion instead of maintenance. If you wanted HYPE exposure at an exchange, you wanted neither native order book, because those three do not convert into each other. A generic dated-future versus open-ended perpetual split still lives in perpetuals versus futures, and it will not identify which HyperCore instrument you opened.
BloFin HYPEUSDT is live at 75x, listed December 19, 2024 11:30 UTC. In the public instruments JSON the swap key is HYPE-USDT (source: BloFin instruments API, SWAP). BloFin does not list HIP-4 outcomes. A HYPEUSDT instrument is a centralized listing, not a HIP-3 builder perpetual and not a daily Yes, and HYPERUSDT on BloFin is still Hyperlane, so you cannot deposit a HyperCore Yes into that instrument, and you cannot treat 75x on HYPE as indemnity on a builder dex.
You do not need the template keyword list, the HaltTrading JSON, or every slash guideline, because the decision is operational. Weigh the author of the observation that can liquidate you, and whether an adverse mark dislocation can take more than you posted, then decide whether that is a market you wanted or whether you only wanted HYPE.
Frequently asked questions
If HaltTrading posts a mark at 02:00 UTC, does HIP-4 convert Yes against that figure?
No. A HaltTrading mark is the settlement figure on that HIP-3 asset's order book, not an input the protocol-run binary is documented to read. The first HIP-4 series still converts against HyperCore's BTC mark at 06:00 UTC, even if a builder settled a nearby BTC perpetual four hours earlier, so treat those as two publications on the same calendar day and do not assume the halt snapshot is interpolated into the daily target. If your interface shows one BTC number after a halt, determine which book produced it.
If a HIP-3 deployer is slashed, does that pay my HIP-4 loss?
No. Slashed HIP-3 stake is burned instead of being paid to users, including users who skipped that dex, and a HIP-4 conversion is quote in or quote out on the posted tokens, which ignores the burn. A wrong Yes still settles to zero quote even if a HIP-3 deployer on a nearby ticker gets slashed the same day, because the burn is a listing penalty, not a cross-product insurance pool, so a loss on Yes is still the collateral you posted on Yes.
Can I post a HIP-4 Yes as isolated margin on a HIP-3 perp?
No. Isolated margin is a perpetual-rest control on borrowed notional, whereas a Yes token is a posted outcome claim, so adding USDC to a HIP-3 isolated-margin bucket does not attach to a Yes you already hold, and transferring Yes into that bucket is not a documented top-up. Portfolio margin is named as a primitive HIP-4 can compose with, which is no promise that today's Yes offsets a HIP-3 maintenance obligation, so if you wanted one bucket to survive both instruments, you wanted a documented account mode, not a wallet coincidence.
Does a BloFin HYPEUSDT funding payment top up HIP-3 isolated margin?
No. Funding on HYPEUSDT SWAP is credited or debited on BloFin's centralized perpetual, and it does not post to a HyperCore isolated-margin bucket, so you can be profitable on that listing and still fail a HIP-3 maintenance check on a builder dex you opened in another wallet. Moving the PnL onto HyperCore requires a withdrawal and a deposit the protocol actually recognizes as margin, which is not a documented auto-sweep, and a 75x CEX funding line is not a HIP-3 top-up instruction.
Is a builder-code cut on a HIP-4 Yes sell the same as HIP-3's 0-300% deployer share?
No. A builder-code cut is fee-on-flow on a named sell, the same way it can attach to spot, and it is not the HIP-3 deployer-share scale that can run 0-300% (0-100% in growth mode) on that dex's perpetual. HIP-4's standing outcome rule still charges on close or settle when testing waiver is off, which is a different invoice than a HIP-3 taker card plus deployer share, so read the builder field on the Yes sell separately from whatever share that HIP-3 dex configured, because those two cuts do not net.
Does disableDex on a HIP-3 book cancel the next protocol 06:00 binary?
No. disableDex is a HIP-3 dex operating action on that builder venue, and the protocol-run daily binary is not inventory on that dex, so turning off a builder BTC perpetual can remove that listing's trading rights without minting, retargeting, or skipping the next 06:00 Yes/No series the protocol already schedules. You can see a HIP-3 book go dark and still see the following day's binary listed, because listing control on one product is not a kill switch on the other.
Can two HIP-4 recurring BTC series run for the same period at once?
No. Official contract specifications guarantee at most one recurring series for each series type, underlying, and period combination, and there is guaranteed to be at most one recurring series for each such tuple (source: Hyperliquid Docs, contract specifications). A second daily BTC binary with the same period would violate that uniqueness line, and the live instance still lives in the outcomeMeta description, so do not invent a second strike beside it, and read the current description instead of assuming a parallel series.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Updated August 2026. Primary sources include the Hyperliquid HIP-3 and HIP-4 specs, oracle, liquidations, fees, contract specifications, deployer actions, and docs index, plus Galaxy's HIP-4 research and BloFin's public instrument API. Protocol and listing facts independently verified against cited sources current as of August 2026.
This article is educational and general in nature, not financial or investment advice. Cryptocurrencies like HYPE carry real risks, including price volatility, deployer and oracle risk on builder markets, liquidation of borrowed size, dated settlement risk on outcome markets, venue risk, and the chance of losing funds. Nothing here is a recommendation to buy, sell, hold, deploy, or trade any HIP-3 or HIP-4 market. Do your own research, and consider speaking with a licensed professional before making financial decisions. BloFin does not provide investment advice.