Payward, the parent company of Kraken, plans to become the first CFTC-regulated deployer on Hyperliquid’s HIP-3* perpetual markets. The company intends to use Hyperliquid as infrastructure for perpetual futures markets serving U.S. clients, subject to regulatory approval. Perpetual futures are derivative contracts without a set expiration date, a format widely used across crypto trading venues. If realized, the plan would place CFTC-regulated trading, clearing, and client-account functions on top of Hyperliquid’s market infrastructure.

Under the proposed structure, Bitnomial, Payward’s CFTC-regulated exchange and clearinghouse, would deploy and clear the markets. NinjaTrader Clearing, Payward’s CFTC-registered futures commission merchant, would carry client accounts.

Hyperliquid announced the plan in a post on X dated October 26, 2026. The post stated: “Payward will use Hyperliquid as the infrastructure layer to deploy perpetual futures markets for US clients.” The contracts would be offered through regulated entities within the Payward group.

The proposal remains conditional. Regulators have not approved the arrangement, and each step depends on regulatory approval. Until that approval is obtained, the proposed CFTC-regulated HIP-3* deployment remains an intention rather than a live product.

Proposed Roles for Bitnomial and NinjaTrader Clearing

Bitnomial would have the central role in the proposed structure. The firm is a CFTC-regulated designated contract market and derivatives clearing organization. If approved, it would act as the deployer, creating, owning, and administering the markets. Bitnomial would also clear and settle the contracts.

NinjaTrader Clearing would carry client accounts under the plan. As Payward’s CFTC-registered futures commission merchant, it would perform that function within its own CFTC registration. The structure would therefore divide market operation and client-account responsibilities between two regulated Payward entities.

Those registrations correspond to the core functions of a U.S. regulated futures market: the trading venue, the clearing function, and the firm that carries customer accounts. Hyperliquid framed the announcement around Payward’s stated intention to become the first CFTC-regulated deployer on HIP-3* markets. The network would serve as the infrastructure layer, while the regulated entities within the Payward group would provide the applicable market and client-account functions.

HIP-3* Adds Optional Permissioned-Market Controls

HIP-3* introduces additional deployer functions for permissioned markets. Hyperliquid said HIP-3 will support optional configuration for such markets in a future network upgrade, with these capabilities grouped under the HIP-3* designation.

Hyperliquid described the activation process as follows: “At its core, HIP-3* activation involves an onchain allowlist managed by the deployer or its sub-deployers.” An allowlist would enable a deployer to determine which approved participants could access a permissioned market.

The feature does not change existing markets. Hyperliquid said, “The functionality is strictly additive to HIP-3; its use is optional and up to the deployer.” The company also said HIP-3* gives deployers additional functionality to operate in a manner consistent with applicable requirements. HIP-3 itself serves as the network’s framework for deployers to launch perpetual markets, with HIP-3* layering optional permissioned controls on top.

The initial HIP-3* version is live on testnet. Its specifications remain preliminary and may change based on feedback. Hyperliquid described its role broadly, stating: “Hyperliquid is a neutral infrastructure layer with the goal of supporting large of the financial system.”

Deployers, including any CFTC-regulated HIP-3* deployer, remain independent operators and retain control and responsibility over their own deployments. From announcement to operation, the stated path depends on regulatory approvals at each step, the future network upgrade that would activate HIP-3* configuration, and testnet specifications that remain open to revision.

Source: Blockonomi