Hyperliquid has introduced a preliminary HIP-3 testnet upgrade that lets independent deployment teams control access to perpetual futures markets through deployer-managed on-chain allowlists.
Summary
- HIP-3 deployers can choose whether to restrict access to their independently operated markets.
- On-chain allowlists can be managed by deployers or sub-deployers appointed by them.
- Existing HIP-3 markets will remain unchanged because the permissioning feature is optional.
- Separate talks involving Hyperliquid Labs, Payward and Bitnomial remain subject to CFTC clearance.
Hyperliquid co-founder Jeffrey Yan said in a testnet proposal that deployers will be able to create permissioned markets and manage their participant lists without handing access decisions to Hyperliquid’s core development team.
Hyperliquid HIP-3 adds optional on-chain allowlists
Under the preliminary design, a deployer can maintain an on-chain list of approved participants or appoint a sub-deployer to handle access. Market operators that do not need permissioning can continue using the existing HIP-3 structure without changing how their markets work.
Hyperliquid has made the first version available on the testnet, where developers can examine the design before any production release. Yan said the specifications remain preliminary, allowing the team to adjust the system after receiving technical feedback.
HIP-3 already allows outside teams to deploy perpetual futures markets on HyperCore without seeking approval from Hyperliquid’s core developers. Each deployer selects the assets offered through its market and controls several operating terms, including oracle inputs, leverage limits, and fees.
Responsibility also remains with the deployment team. Independent operators manage their markets, oversee settlement, and address problems tied to the products they list, while Hyperliquid supplies the underlying blockchain and trading infrastructure.
Adding permissioning extends the tools available to the same operators rather than transferring market control to Hyperliquid. A team could use an allowlist when its business model, legal obligations, or internal policies require it to limit participation, while another deployer could keep its market open under the present framework.
The design also separates infrastructure governance from market-level access. Hyperliquid would maintain the underlying network, but each participating team would decide whether to activate an allowlist and who qualifies to enter its deployment.
Independent deployers retain operational responsibility
HIP-3 was built to support markets launched by third parties instead of limiting product creation to Hyperliquid’s own team. Deployers can list perpetual contracts linked to crypto assets and other reference markets, provided they manage the technical and operational duties attached to their products.
A perpetual futures contract does not carry a fixed expiry date. Recurring funding payments help keep its price close to the referenced asset, while traders can maintain a position as long as they meet the applicable margin requirements.
Through HIP-3, independent teams can determine how those contracts are structured. Oracle selection affects the reference price used by the market, leverage rules determine how much exposure traders can take, and fee settings establish what participants pay for trading.
Permissioned deployments would add participant screening to that list of controls. Hyperliquid has not said that all HIP-3 operators must use the feature, and the testnet release does not change existing markets automatically.
Such separation is consistent with Hyperliquid’s description of itself as a neutral infrastructure provider rather than the operator of every market built on its systems. Deployers remain responsible for the products they introduce and the access rules they choose to apply.
Operational control can also leave deployment teams responsible for failures linked to their own market configuration. Oracle quality, leverage settings, settlement procedures and access management sit with the operator rather than Hyperliquid’s central development group under the structure described by Yan.
During the testnet stage, participating developers can assess how allowlists interact with trading accounts, market permissions and sub-deployer roles. Hyperliquid has not announced a date for moving the feature to mainnet, and feedback could alter the final specifications.
Permissioned markets could support compliance controls
On-chain allowlists provide a technical method for restricting participation, but the proposal does not state that activating one makes a deployment compliant with any particular jurisdiction. Legal obligations depend on the assets, customers, operator, and countries involved, while an allowlist only controls which blockchain accounts can enter a market.
For U.S.-facing operators, derivatives access is generally tied to Commodity Futures Trading Commission rules and the licenses held by the venue, clearing organization, and intermediary. Permissioning software by itself does not replace registration, customer-protection, reporting, or market-surveillance requirements imposed by the regulator.
In July, the Hyperliquid Policy Center and Phantom requested tailored rules for decentralized trading systems. As crypto.news reported, the groups argued that software developers and non-custodial wallet providers should not automatically face the same registration duties as traditional financial intermediaries that control customer assets.
An Aug. 26 filing from the Hyperliquid Policy Center and trade[XYZ] later proposed energy perpetuals tied to West Texas Intermediate crude, Brent crude, and Henry Hub natural gas. The filing said trade[XYZ] had operated third-party perpetual markets on Hyperliquid since October 2025 and recorded more than $500 billion in cumulative volume across several asset classes.
According to the filing, any regulated U.S. operator would still need to comply with CFTC rules covering customer protection, market integrity and recordkeeping. The groups also proposed asset-specific leverage limits, plain-language funding disclosures and controls addressing benchmark reliability and manipulation risks.
The CFTC has not approved the requested energy products. Its review covers price reliability, surveillance, position limits, margin, clearing, and the possible effects of continuous derivatives trading on physical commodity markets.
U.S. perpetual futures plans require regulatory clearance
Separate discussions involving Hyperliquid Labs and Kraken parent Payward could place selected crypto perpetual futures on Bitnomial, a regulated U.S. derivatives exchange. Payward has presented the proposed structure to the CFTC, according to the supplied report, but no authorization has been confirmed.
Under the discussed arrangement, eligible Bitnomial customers could trade selected crypto-linked futures using Hyperliquid technology. Bitnomial would provide the regulated venue, while the proposed technical and operating roles would depend on the final structure accepted by the companies and the CFTC.
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, allowing users to manage spot, margin, conventional futures, and perpetual contracts from a Kraken Pro account.
The proposed Hyperliquid arrangement concerns selected contracts using its technology and remains distinct from Kraken’s existing Bitnomial products. Any launch would depend on the CFTC’s assessment of the contracts, market structure and safeguards presented by Payward.
A separate legal dispute could also affect how such products reach American customers. CME Group has challenged the CFTC’s treatment of perpetual contracts, arguing that they should be governed as swaps under the Dodd-Frank Act rather than listed as ordinary futures.
The perpetuals classification dispute began after the CFTC cleared Kalshi’s Bitcoin perpetual contract in May. CME’s position would place the products under a different regulatory framework, while the CFTC has argued that federal law does not require a futures contract to carry a fixed expiry date.
Payward’s proposal involving Hyperliquid technology remains before the CFTC, with no confirmed launch date, approved contract list, or final eligibility requirements for Bitnomial customers.
