- HIP-3* is a testnet proposal published 3 September 2026 that lets a Hyperliquid market deployer keep an onchain allowlist of which wallets may participate in an individual market, managed directly or delegated to an approved sub-deployer.
- Permissionless bundles three separate rights: custody of your collateral, permission to enter a market, and permission to close a position you already hold. An allowlist separates them at the level of one market, which turns access into a deployer setting rather than a property of the chain.
- The published material specifies who may enter and says nothing about a removed wallet holding an open position, so the question worth asking any venue is what its rules say happens to a live position when your access changes.
You can hold your own keys and still be told no.
Nothing about the way you get into a perpetual DEX prepares you for that sentence. You connect a wallet, sign a message, and the market is there: no email, no approval queue, no photograph of your passport at two in the morning. That missing friction is the product, and it is real. Ask whether a DEX is permissionless and the answer is yes. It is also incomplete. The word has been quietly doing three jobs at once, and you have only been checking one of them.
On 3 September 2026, Hyperliquid co-founder Jeffrey Yan published a testnet proposal extending the venue's HIP-3 framework into something called HIP-3*. FinanceFeeds described the mechanism plainly: market deployers "will be able to maintain onchain allowlists determining which wallets can participate in individual markets." They can manage those lists directly, or "delegate the responsibility to approved sub-deployers." Existing HIP-3 deployments stay as they are. Nothing has reached mainnet. The named users are institutions, regulated brokers and jurisdiction-specific operators. The feature exists so a venue can let in people who arrive with rules attached, without handing those rules to everyone else.
You are working through this one with Ava, Kodex's structural reader. She is precise, unhurried, and more interested in which parts of a promise carry weight than in what the promise is called. She takes you through what a deployer already decides here, what the allowlist adds on top, and which of the rights you assumed travelled together are actually spelled out.
Ava does not start with the proposal. She starts with the word.
What a market deployer already controls
Ava opens the venue's own documentation first. A new setting only means something against the ones already shipped. HIP-3 lets an independent party stand up a perpetual market on Hyperliquid's infrastructure. The documentation is unembarrassed about who owns that market's behaviour. The deployer is responsible for "market definition, including the oracle definition and contract specifications," and for "market operation, including setting oracle prices, leverage limits, and settling the market if needed."
Sit with the second half of that. The oracle price is the number your liquidation gets measured against. A deployer sets it. Leverage limits decide how much rope the market hands you before it stops handing you any. Further down, the documentation lets a deployer configure an additional fee share between 0 and 300 percent. It also hands the deployer a halt action that "cancels all orders and settles positions to the current mark price." Every input to how your position lives and dies already belongs to a party that is not the chain.
That is not a gap in the design. It is the design, and the venue charges for it. A mainnet deployer stakes 500,000 HYPE and keeps it staked for at least 183 days after the market goes live. Validators can slash that stake in the event of malicious market operation. Someone posts collateral before they get the levers. That is a more serious arrangement than the word "decentralized" usually implies.
That pattern holds through the rest of the ledger. A deployer meeting the staking requirement gets one perp DEX, not a portfolio of them. Switching on cross margin for an asset is documented as a choice that cannot be reversed. Those are the constraints of an operator, not of a user: obligations, a clock, and decisions that lock behind you. The venue built a role, priced it, and wrote down what the role is allowed to do.
Ava reads the FinanceFeeds summary of that role from the outside: deployers "determine assets, price oracles, leverage limits, open-interest parameters and other market characteristics." Two descriptions, one from the venue and one from a wire, and they agree. One thing is missing from both. Neither version says a word about who is allowed to be in the market.
Until this month, the answer to that was simply anybody.
What does HIP-3* add to a permissioned perpetual market?
"One list," Ava says. "That is the entire feature."
The list lives onchain. It names which wallets may participate in an individual market. The deployer keeps it, or an approved sub-deployer keeps it instead. crypto.news, which carries the proposal's own framing, gives the intent as letting "U.S. investors access certain markets, or institutional investors that have strict rules." A deployer could restrict a market to wallets that have cleared an identity, jurisdiction or eligibility check. Everyone else finds that market closed.
The delegation clause is the quiet half of it. A deployer can hand list-keeping to an approved sub-deployer. The party deciding whether your wallet belongs in a market is then not necessarily the party whose name is on it. That arrangement is ordinary in finance. A broker does the identity work a venue then relies on, and nobody finds it sinister. It does mean the question "who here can say no to me" has two possible answers on the same market. Only one of them is the answer you looked up.
Take the steelman seriously before you take anything else. A licensed broker cannot route a client into a venue where the counterparty might be anyone at all. A fund with a mandate cannot trade a book it is not permitted to touch. Their choice today is to stay out or to rebuild the same infrastructure somewhere private. An allowlist is how a venue says yes to people who show up carrying obligations, without imposing those obligations on the wallet that showed up carrying nothing. A deployer who wants an open market never switches it on. Existing markets are untouched. The specification is preliminary. Feedback could still change it before a network upgrade carries any of this to mainnet.
Optional is doing real work in that sentence. A market on this framework is its own object with its own parameters. The venue can hold an open market and a gated one side by side. Neither is a compromise for the other. That is the part to understand before the word "permissioned" sets anything off: this is not a policy applied to Hyperliquid. It is a property that now varies from one market to the next.
So the venue has not changed character. What changed is smaller and harder to see. Access stopped being a property of the place and became a setting inside it, adjustable per market, by one party. Nothing about that looks like a gate. It looks like a checkbox, which is what a gate looks like before anybody has had to stand in front of it.
The three rights bundled into "permissionless"
This is the line Ava was walking toward from the first paragraph. She draws it in three parts.
When you call a venue permissionless, you are making three claims and noticing one. The first is about custody: nobody is holding your collateral, your wallet signs for itself, and there is no account to freeze. The second is about entry: nobody decides whether you get to participate, because there is no desk to say no. The third is about exit: whatever happens, you can close what you are already holding.
Exit is the one that sounds least like a right, because closing a position feels like something you do rather than something you are permitted to do. Mechanically it is a fresh order sent to the same market, and something has to accept it before anything closes. Custody gets your collateral out of a venue. It does not get you out of a position. Those are separate operations, and only the first is entirely in your hands. Any rule about who may send an order to a market therefore governs both directions by default, unless somebody writes it to do otherwise.
Those three have travelled together for so long that the word stopped distinguishing them. So which one does an allowlist actually touch, and what does the published material say about each?
| The right | What you are assuming | What the published material specifies |
|---|---|---|
| Custody of your collateral | Your wallet signs, nobody holds the balance for you | The proposal does not touch it. A list governs a market, not your balance |
| Permission to enter | Any compatible wallet can participate | An onchain allowlist, held by the deployer or an approved sub-deployer |
| Permission to exit | If you are in, you can always get out | Nothing. A removed wallet holding an open position is not addressed |
Two of those are answered and one is blank. The blank one is the row you would care about at the worst possible moment.
The custody row deserves a pause, because it is the one that holds up completely. Connect a wallet to a perp DEX and nobody takes your balance into an account of their own, nobody reviews your withdrawal, and no support queue stands between you and your keys. HIP-3* leaves all of that exactly where it was. It is also why the other two rows are easy to walk straight past. The failure you have been trained to fear is a venue holding your money and then not returning it. Against that, a setting which never touches your money reads as harmless by construction. The habit of checking custody is well drilled. The habit of checking access has never had a reason to exist.
A word that bundles three promises is efficient right up until one of them changes hands. Then you find out what you had been quoting. You verified one part of the bundle and cited all three.
Can a DEX block a wallet that already holds a position?
Picture it landing on you, because that is where the question stops being theoretical.
You cleared a check in the spring, your wallet went onto a list, and you have been trading that market ever since. Months later the deployer narrows the list. A jurisdiction changed its mind, or a sub-deployer tightened a rule, and the reason never reaches you. What reaches you is a state change onchain. You are carrying a position when it lands. You can see the list. You can see the position. Every parameter of the market is on a public page you can read in a browser.
What you cannot find is the paragraph that says which of those two facts wins.
That paragraph does not exist yet. Its absence is not an inference, but a documented silence. FinanceFeeds, crypto.news and Hyperliquid's own HIP-3 documentation all describe who may participate in a market. None of them says what becomes of a position held by a wallet that gets removed from the list.
Ava is careful here, and you should be too. Silence is not a denial. It is not evidence that you would be stuck. Anyone telling you the feature traps positions is reading a specification that has not been written. What can be said accurately is narrower and more useful: entry is specified and exit is not. The whole thing sits on testnet, and you can confirm both halves in an afternoon by reading the same two pages she just read.
The gap is easier to see because the framework already documents one exit-shaped power. It is precise about that one. That halt action cancels open orders and settles positions to the current mark price. It is a real answer to "how does this end": everyone in the market at once, by a named action, at a stated price. For one wallet leaving a market that keeps running, there is no equivalent paragraph.
Which makes this a different failure from the two Kodex has already taken apart. When a chain stops, it stops for everyone at once, and the number of validators it takes is public. When a venue winds a contract down, the position ends because the market it lived in ended. Here the market carries on trading and the price keeps printing. One wallet is on the outside of a position it still owns. A right that is written down can be argued over. A right nobody wrote down gets decided later, by whoever is holding the pen when it comes up.
How to check whether a DEX is permissionless for you
Ava turns the whole thing into four questions, in this order, and the order matters.
Who is holding the collateral while the position is open? That is the custody question, and it is the one you already ask. Then: who decides whether your wallet may be in this specific market, the protocol or one deployer? Then: can that party delegate the decision to somebody else, and is that somebody named anywhere you can read? And last, the one that has no answer yet on the venue that prompted all this: what do the rules say happens to an open position if the answer to question two changes?
The first question is the one you were trained to ask. Questions two through four are the ones the word "permissionless" has been answering on your behalf. It was never asked to show its work.
Run them against something you already use and watch how quickly they sort venues apart. On a centralized exchange the first answer is the exchange. That is the whole reason the custody argument for a DEX exists. On an open HIP-3 market the first answer is your own wallet and the second is nobody, because there is no list to be on. On a permissioned market the first answer is still your wallet, the second is a deployer you can name, and the fourth decides whether the second ever matters to you. Same four questions, three different shapes of exposure. The difference is not visible in the interface, but in the rulebook underneath it.
A venue that has thought this through closes it in one sentence. A removed wallet may reduce or close, but not increase. That sentence costs nothing to write. Finding it tells you the question was asked inside the venue before you got around to asking it.
That habit generalises well beyond one venue. The rulebook an asset sits under, not the interface it appears in decides which protections follow your position. A permissioned market is a rulebook change dressed as a configuration. Kodex's read on the DEX share of CEX spot volume tracks where the flow has been going. This is the other half of that story: what conditions travel with it once it arrives.
Those conditions are still being drafted. HIP-3* is optional, preliminary and confined to testnet, so there is nothing here to act on and nothing to flee, which is exactly why it is worth reading now rather than after a position depends on it. The venue published the mechanism openly enough that you can check every claim in this article against its own pages.
Ask the fourth question before you fund anything. If the venue has an answer, it costs you a minute. If it does not, that silence is the answer. You found it while you still had nothing at stake.
Run those four questions on a position that cannot cost you anything before you run them on one that can. Take a trade in the Kodex simulator on its $5,000 simulated balance. Then write out, in your own words, who would be holding that collateral, who could decide tomorrow that you may not be in that market, and what the rulebook says happens to the position if they do. Three answers and one blank space is a result worth having early.
