Have you ever watched a trading venue try to stay open to everyone and still satisfy people who cannot, legally or internally, sit in the same room? That tension is not theoretical anymore. Hyperliquid has floated a preliminary HIP-3 testnet upgrade that lets independent deployment teams decide who may enter their perpetual futures markets, using deployer-managed on-chain allowlists rather than a central gatekeeper. I have found that the most interesting upgrades are rarely the flashy ones. They are the quiet switches that change who is allowed to click buy.
What This HIP-3 Upgrade Actually Changes
The headline is simple. A deployer can now choose whether a market is open or restricted. If restricted, access lives on-chain as a list of approved participants. The deployer can manage that list directly or appoint a sub-deployer to do the screening. Markets that do not need a guest list keep the current HIP-3 setup. No forced migration. No surprise lock on books that already exist.
That last point is easy to skip and should not be. Optional features fail when they quietly rewrite old products. This one is framed as additive. Existing HIP-3 markets stay as they are because permissioning is a choice, not a new default. In my experience, that is how you avoid a revolt from operators who already built flow on an open book.
Hyperliquid co-founder Jeffrey Yan described the intent in a testnet proposal. Deployers would create permissioned markets and manage participant lists without handing those decisions to the core development team. That sentence is doing a lot of work. It draws a line between infrastructure and market access. The chain stays shared. The door policy becomes local.
In a future network upgrade, HIP-3 will support optional deployer configuration for permissioned markets. This would, for example, allow U.S. investors to access certain markets, or institutional investors that have strict rules.
Notice the examples. U.S. investors. Institutions with internal policy. Those are not the same problem. One is legal perimeter. The other is risk committee language. An allowlist can serve both, but it does not magically solve either. Software can say yes or no to an address. It cannot file a form for you.
HIP-3 Was Already A Delegation Story
Before this testnet drop, HIP-3 already let outside teams deploy perpetual futures on HyperCore without begging the core developers for a product green light. Each deployer picks the assets, the oracle inputs, the leverage bounds, and the fee schedule. Responsibility follows the listing. If the product is messy, the operator owns the mess.
That model is closer to a landlord-and-tenant setup than to a single house brand. Hyperliquid supplies the building and the pipes. Independent teams furnish the rooms and answer the complaints. Permissioning extends the same toolkit. It does not pull the rooms back under one manager.
A perpetual futures contract has no fixed expiry. Funding payments tug the contract toward the reference price. Traders can hold as long as margin holds. Through HIP-3, independent teams decide how those contracts are wired. Oracle choice shapes the mark. Leverage rules cap how far a book can stretch. Fees decide who pays for the lights.
- Deployers pick listed assets and reference markets.
- Oracle inputs stay under operator control.
- Leverage limits and fees are local settings.
- Settlement and incident response sit with the listing team.
- Permissioning is now another optional control on that same stack.
I’ve sat with enough product notes to know that “optional” is the word people underestimate. Optional is how you let a compliance-heavy shop and a wide-open shop share one chain without forcing them into the same customer policy. It is also how you create two cultures on one venue. That can be healthy. It can also confuse users who think every book is the same book.
How On-Chain Allowlists Would Work In Practice
Under the preliminary design, a deployer keeps an on-chain list of approved participants or names a sub-deployer to handle access. That split matters. A trading firm might want engineering to own the market parameters and legal ops to own the guest list. Sub-deployer roles make that split explicit instead of burying it in a spreadsheet.
The first version is on testnet so developers can poke the design before anything hits production. Yan has been clear that the specs are still preliminary. Feedback can still change the shape. That is the right posture. Access control looks tidy on a whiteboard and gets ugly when accounts, permissions, and sub-roles collide in live flow.
During this stage, teams can study how allowlists talk to trading accounts, market permissions, and appointed operators. There is no public mainnet date. Anyone treating testnet as a launch calendar is guessing. Guessing is fine for curiosity. It is a poor basis for a product roadmap.
Perhaps the most interesting aspect is how little this changes for teams that want nothing to do with screening. They keep the current HIP-3 structure. They do not have to learn a new access primitive. They do not have to justify an open book. Open remains a first-class option, not a leftover mode.
Why Permissioning Is Not The Same As Compliance
An allowlist is a door. Compliance is the building code. Mix those up and you get a dangerous kind of confidence. The proposal does not claim that turning on a list makes a deployment legal in any given country. Legal duties still depend on the asset, the customer, the operator, and the jurisdictions in the mix.
For U.S.-facing operators, derivatives access generally sits under Commodity Futures Trading Commission rules and the licenses held by the venue, the clearing organization, and any intermediary. Permissioning software does not replace registration. It does not replace customer-protection rules. It does not replace reporting. It does not replace surveillance.
That sounds obvious. It is not obvious to every team that hears “on-chain allowlist” and starts drafting a U.S. go-to-market slide. I’ve seen that leap before in other corners of crypto. A filter is not a license. A whitelist is not a rulebook. If a market needs a regulated wrapper, it still needs the wrapper.
On-chain screening can limit who enters a book. It cannot stand in for the duties a regulator places on a licensed venue, a clearer, or an intermediary.
In July, policy groups tied to the Hyperliquid ecosystem asked for tailored rules around decentralized trading systems. The argument, in plain terms, is that software developers and non-custodial wallet providers should not automatically be treated like intermediaries that hold customer assets. That debate is older than this testnet patch. Permissioned markets will not end it. They may give the conversation a sharper example.
A later filing from the same policy circle, working with an independent operator, floated energy perpetuals linked to West Texas Intermediate crude, Brent crude, and Henry Hub natural gas. That operator said it had run third-party perpetual markets on Hyperliquid since October 2025 and cited more than $500 billion in cumulative volume across several asset classes. Those numbers are part of the public pitch. They are not a substitute for product approval.
The filing itself stressed that any regulated U.S. operator would still need to meet rules on customer protection, market integrity, and recordkeeping. It also sketched asset-specific leverage limits, plain-language funding disclosures, and controls around benchmark quality and manipulation risk. That is the grown-up version of this story. Tools first. Obligations still attached.
Those energy products have not been cleared. Review in this area typically covers price reliability, surveillance, position limits, margin, clearing, and the knock-on effects of continuous derivatives trading on physical commodity markets. Anyone who thinks an allowlist short-circuits that review is not reading the same file.
Independent Operators Still Carry The Operational Risk
HIP-3 was built so third parties could launch markets instead of waiting for a single internal product team. Deployers can list perpetual contracts tied to crypto assets and other reference markets, as long as they accept the technical and operational load. That load is not decorative.
Oracle quality can make or break a book. A sloppy feed turns funding into a fight. Leverage settings can turn a quiet session into a liquidation cascade. Settlement procedures decide whether a bad hour becomes a bad week. Access management, if used, becomes another place where a missed address or a stale list can lock the wrong people in or out.
Under the structure described by Yan, those choices sit with the operator, not with a central development group. That is attractive if you want a neutral base layer. It is less comforting if you are a trader who assumes every market on a brand-name chain has the same adult supervision. Brand and operator are no longer the same person. Users will need to learn that distinction the hard way if education does not come first.
- Confirm whether a market is open or permissioned before sending size.
- Check who the deployer is and whether a sub-deployer owns access.
- Review oracle sources, leverage caps, and fee settings as operator choices.
- Treat incident response as a deployer duty, not a chain-wide promise.
- Do not confuse an allowlist with a regulatory seal.
That list is not legal advice. It is hygiene. Permissioned markets will tempt people to assume a book is “safer” because someone had to approve the wallet. Safer for whom? A screened book can still have a weak oracle. An open book can still be tightly engineered. Access and quality are different axes. Keep them separate in your head.
A Neutral Chain With Local Door Policies
Hyperliquid describes itself as a neutral infrastructure provider rather than the operator of every market on its systems. Permissioning is consistent with that story. The network remains shared. Each team decides whether to turn on a list and who qualifies. Governance of the rails stays distinct from governance of a single book.
I like that separation on paper. In practice, users still see one interface and one ticker tape. The risk is reputational bleed. If a permissioned book stumbles, some of the heat will still land on the chain brand. If an open book becomes a circus, the same thing happens. Neutrality is a legal and architectural claim. Public memory is less precise.
Still, the design is cleaner than forcing every deployer into one access model. Institutions that cannot touch an unrestricted book get a path that does not require the whole network to become a walled garden. Open-market teams are not asked to collect questionnaires they do not want. That coexistence is the point.
HIP-3 control stack, simplified: Chain and matching infrastructure -> shared Asset list, oracles, leverage, fees -> deployer Optional participant allowlist -> deployer or sub-deployer Legal and license burden -> still the operator’s problem
Read that last line twice. The upgrade gives operators a new lever. It does not pick up their legal bag. If a team wants U.S. flow, the list may help them implement a policy they already have. It will not write the policy. It will not obtain the license. It will not end a classification fight happening in another building.
The Separate Track Toward Regulated U.S. Perpetuals
Away from the testnet notes, there is another conversation that keeps getting bundled into the same headline. Talks involving Hyperliquid Labs and Payward, the parent behind Kraken, could place selected crypto perpetual futures on Bitnomial, a regulated U.S. derivatives exchange. Payward has presented a structure to the CFTC. Authorization has not been confirmed.
Under the discussed arrangement, eligible Bitnomial customers could trade selected crypto-linked futures using Hyperliquid technology. Bitnomial would remain the regulated venue. Technical and operating roles would depend on whatever final map the companies and the regulator accept. That is a different animal from a deployer flipping an allowlist on HyperCore.
Payward already owns Bitnomial, which holds U.S. exchange, clearinghouse, and brokerage licenses. Kraken launched regulated perpetuals for eligible American clients through Bitnomial in June, letting users manage spot, margin, conventional futures, and perpetual contracts from a Kraken Pro account. The proposed Hyperliquid arrangement is about selected contracts using its technology. It is not the same product set.
Any launch would depend on the CFTC’s view of the contracts, the market structure, and the safeguards on the table. There is no confirmed date, no approved contract list, and no final eligibility grid for Bitnomial customers in that proposed structure. Treat rumors of a start date as marketing until a filing becomes an order.
A separate legal fight could still reshape how such products reach American customers. CME Group has challenged the CFTC’s treatment of perpetual contracts, arguing they should be governed as swaps under the Dodd-Frank Act rather than listed as ordinary futures. That dispute heated up after the CFTC cleared a Bitcoin perpetual contract from Kalshi in May. The agency has argued that federal law does not require a futures contract to carry a fixed expiry date.
If that classification fight lands one way, the wrapper changes. If it lands the other way, the current path stays more intact. HIP-3 permissioning does not referee that case. It only changes how an independent book on Hyperliquid can screen wallets. Keep the two tracks on two whiteboards.
| Track | What it is | Who decides access | Status |
| HIP-3 permissioned markets | Optional on-chain allowlists for independent perpetual books | Deployer or appointed sub-deployer | Preliminary testnet design |
| Open HIP-3 markets | Existing third-party perpetual deployments | No new access list required | Unchanged by the optional feature |
| Bitnomial discussions | Selected crypto perpetuals using Hyperliquid technology on a licensed U.S. venue | Regulated venue eligibility rules | Awaiting regulatory clearance |
| Energy perpetual proposal | WTI, Brent, and Henry Hub style products in a requested U.S. framework | Would still sit under CFTC duties | Not approved |
If you only remember one row, remember the first two. Most traders on Hyperliquid will meet HIP-3 as a product surface, not as a Washington process. The third and fourth rows matter if you care about regulated U.S. distribution. They are related by theme. They are not the same upgrade.
What Institutions Quietly Want From A Book
Institutions talk about liquidity first and policy second, until policy blocks the account. Then policy becomes the whole meeting. Strict mandates can forbid interaction with unrestricted venues, even when the tech is fine. An allowlist gives a deployer a way to say: only these wallets, only these counterparties, only this program.
That can look like a club. Sometimes a club is the only way a mandate can show up. I’ve found that desks do not always want exclusivity for its own sake. They want a paper trail that matches an internal memo. An on-chain list is a blunt instrument for that, but it is an instrument. Off-chain spreadsheets do not settle disputes the same way.
U.S. investor access is the other example baked into the proposal language. That is a hotter potato. Geography is not a wallet attribute unless someone maps it. An allowlist of addresses is only as good as the process that put those addresses there. If the process is sloppy, the list is theater. If the process is rigorous, the list is still not a license.
So why bother? Because some operators will not list a market at all unless they can restrict it. Optional permissioning may unlock products that would never have shipped as fully public books. That is the bull case. The bear case is fragmentation: liquidity split across a public book and a private book that cannot talk to each other in a clean way.
Will that split be worth it? Depends on the asset. A long-tail reference market might only exist if a specialist operator can keep the room small. A major crypto perpetual might suffer if flow is carved into too many rooms. There is no universal answer. Anyone selling one should be asked which book they mean.
How Traders Should Read A Permissioned Ticker
If this design reaches mainnet in something like its testnet form, the user experience question becomes practical. How does a trader see that a market is gated? How is a rejected wallet explained? How are sub-deployer changes disclosed? Those details will decide whether this feels like professional market structure or like a silent error code.
Price discovery also changes when some addresses cannot enter. A permissioned book can print a clean mid and still be a thin mid. Open interest can look respectable and still represent a small circle. Compare funding, depth, and liquidation behavior against the open sibling market if one exists. Do not assume the ticker with the same asset name is the same organism.
There is a social piece too. Crypto culture still treats open access as a moral default. A gated book will attract suspicion even when the reason is boring and institutional. Operators who use the feature should explain the reason in plain language. “We have a mandate” is clearer than “this is the future of markets.” People can live with a mandate. They hate a sermon.
A gated book is not automatically higher quality. It is a book with a door. Check the hinges, the oracle, and the people holding the key.
I would also watch how allowlists are updated. Additions are easy to celebrate. Removals are where disputes start. If a wallet is dropped mid-position, what happens to the risk? If a sub-deployer rotates, who attests that the new list matches the old policy? These are unglamorous questions. They are the questions that matter after the announcement thread cools down.
What Stays The Same On Purpose
It is worth repeating because launch coverage often buries it. Existing HIP-3 markets are not rewritten by this feature. Operators who like the current structure keep it. Hyperliquid is not, in this design, appointing itself as the access committee for every independent book. That restraint is the difference between a platform upgrade and a platform grab.
HIP-3 already pushed product creation outward. This patch pushes access policy outward as well, but only for teams that opt in. The chain still provides matching and settlement rails. The deployer still owns listing choices. The new piece is a list that can live on-chain and be delegated. That is a narrow change with wide political meaning in this industry.
Why political? Because “permissionless” is a brand as much as a technical property. Optional permissioning lets the brand keep saying the base layer is open while some rooms upstairs require a name at the door. Purists will hate that sentence. Institutions will like it. Both reactions are predictable. The useful question is whether users can tell which room they are in.
- Open HIP-3 markets can keep running without the new control.
- Permissioned markets are an opt-in configuration, not a network-wide mandate.
- Core developers are not positioned as the access desk for every listing.
- Testnet exists so the design can still change before production.
- Regulatory conversations about U.S. perpetuals remain a separate process.
The Energy Market Sidebar Is A Stress Test
Commodity-linked perpetuals make the stakes clearer than another long-tail token book. Oil and gas benchmarks already live inside a thick web of physical markets, inventory prints, and incumbent derivatives. A continuous on-chain contract that references those benchmarks will be judged on manipulation surface, leverage, and whether funding language is honest.
The August filing that sketched WTI, Brent, and Henry Hub style products tried to meet that judgment halfway. It talked about leverage limits by asset, clearer funding disclosures, and controls around benchmark reliability. It also admitted the obvious: a regulated U.S. operator would still need to live inside CFTC rules on protection, integrity, and records.
That is the grown-up posture. Ask for a product. Show the guardrails. Do not pretend a wallet list is the guardrail. If those energy markets ever appear in a cleared U.S. form, they will do so because the review accepted the market design, not because HIP-3 grew a new flag.
Until then, treat commodity perpetuals on an independent deployment as operator products with operator risk. The chain can be excellent and the benchmark process can still be the weak joint. Permissioning might limit who can trade. It will not make a poorly designed reference robust.
A Few Opinions I Will Not Dress Up As Facts
I think optional allowlists are a reasonable engineering answer to a real distribution problem. Some capital cannot touch an open book. Pretending otherwise just keeps that capital on licensed islands. Giving deployers a switch is better than forcing the entire venue to become an island.
I also think the industry will oversell the switch. People will say permissioned markets “bring Hyperliquid to the United States.” They do not, by themselves. They may help a particular operator implement a particular policy. The United States still has a regulator, licensed venues, and an unfinished argument about what a perpetual even is.
And I think user education will lag the feature. It always does. Ticker symbols are short. Governance footnotes are long. If two markets share an asset name and only one has a door, someone will size the wrong one. Interfaces should make the door visible. If they do not, the feature will create avoidable pain.
None of that makes the testnet work unserious. Preliminary specs that invite feedback are how you avoid shipping a clever lock that nobody can operate under stress. The team left room to change the design. Use that room. Push on account mapping, sub-deployer powers, removal mechanics, and how a trader learns they are locked out before they learn it from a failed order.
What To Watch Between Testnet And Anything Live
First, watch whether the final spec keeps permissioning fully optional. If that promise slips, the story changes from toolkit to regime shift. Second, watch how public the allowlists are. A fully visible list is auditable and also commercially sensitive. A hidden list is tidier for some operators and worse for outsiders trying to understand market quality.
Third, watch the sub-deployer model. Delegation is useful until it becomes a maze. Who can add. Who can remove. Who can pause a market. Who can rotate the list admin. Those permissions should be boring and explicit. Cute flexibility here becomes an incident report later.
Fourth, keep the Bitnomial and classification fights in a separate column on your notes. They will keep appearing in the same weekly wrap. They answer a different question: how selected contracts might be offered to eligible U.S. customers through a licensed venue using Hyperliquid technology. That question lives with the CFTC and with whatever structure Payward ultimately defends.
Fifth, listen to independent deployers, not only to the core announcement. HIP-3 only matters if operators use it. Some will ignore the feature and keep hunting open flow. Some will treat the list as the product. The mix of those choices will tell you whether this was a niche compliance widget or a new market type.
Read the upgrade as:
optional access control
+ unchanged open markets
+ operator-owned risk
- not a regulatory approvalThat little block is the whole article if you are in a hurry. If you have time, sit with the tension underneath it. Open infrastructure wants reach. Regulated capital wants fences. HIP-3 is trying to let both exist without making the core team the bouncer. That is an ambitious social design dressed up as a testnet note.
The Quiet Meaning Of A Guest List On A Public Chain
Public chains spent years treating the guest list as the thing you were supposed to abolish. Then the money got larger, the products got closer to traditional derivatives, and the guest list came back wearing better shoes. Call it allowlisting. Call it permissioned markets. Call it institutional access. The function is old. The implementation is new because the list can live next to the order book instead of in a broker’s CRM.
Does that make the system less free? At the base layer, not necessarily. Freedom at the base and policy at the application are supposed to be compatible. The test is whether open markets remain first-class and easy to launch. If they do, the guest list is a room setting. If they do not, the guest list was a pretext.
Right now the design says they remain first-class. Believe that until the spec or the social pressure says otherwise. Then re-read the room. Markets change their minds. Protocols do too. The useful habit is to keep asking who holds the key, who wrote the oracle, and who answers the phone when funding goes sideways.
Hyperliquid’s preliminary HIP-3 work does not settle the U.S. perpetual debate. It does not bless energy contracts. It does not turn an independent deployer into a licensed exchange. It does give those deployers a way to restrict a book when their model, their counsel, or their limited partners require it. That is a smaller sentence than the hype cycle will use. It is also the accurate one.
If you trade these markets, start practicing the habit of reading the operator, not only the ticker. If you build these markets, start writing the access policy before you write the announcement. If you just like watching market structure evolve, this is one of those upgrades that looks minor in a changelog and major in a year-end essay. The door is optional. The questions behind it are not.
