Loading prices…
🔥BULLISH

Hyperliquid Tests HIP-3 Wallet Allowlists on Builder Perps

HIP-3* lets a single builder gate its own perpetuals venue while the rest of Hyperliquid stays permissionless, a structural onramp for firms with KYC or jurisdictional constraints.

Hyperliquid is testing HIP-3*, an optional extension to its builder-run perpetuals framework that lets individual market deployers impose wallet allowlists on their own venues. The feature was published to a Sept. 3 developer update on the Hyperliquid API Announcements channel and is currently live only on testnet, with no mainnet date announced. A HIP-3* deployer can act on a user's behalf in five bounded ways: add or remove allowlist approval, cancel specified resting orders, bulk-cancel resting orders and TWAPs on the venue, place reduce-only orders, and move collateral to another account on the same venue. Proxied orders must be reduce-only, so an operator can shrink a position but not enlarge one through the proxy function.

Why it matters

HIP-3* is the first piece of access-control tooling Hyperliquid has shipped for its builder-deployer model, and the framing matters as much as the feature. Deployers running a HIP-3 market already bear the economic and operational burden: they define contracts, maintain oracles, set leverage limits, settle markets, and must stake 500,000 HYPE, which validators can slash for irregular inputs that jeopardize protocol correctness, uptime, or performance. HIP-3* layers wallet gating on top of that operator model without shifting venue responsibility to the core protocol or forcing KYC on the rest of the network. Hyperliquid's stated intent is to help independent deployers meet requirements applicable to them, not to act as a compliance layer itself.

That separation is what makes the feature legible to institutional counterparties. A firm with client onboarding, sanctioned-jurisdiction exclusions, or partner-flow restrictions now has an onchain tool to gate its own venue, while open deployers keep running permissionless books. It is not regulatory approval, and it is not a mainnet launch, but it is the kind of plumbing a treasury desk or prime broker would ask for before routing flow to a builder-deployer DEX.

Market impact

The immediate read is structural rather than reactive.

Related tokens
$HYPE

Frequently asked questions

  1. What is HIP-3*?

    HIP-3* is an optional Hyperliquid testnet extension to its builder-deployer perpetuals framework. It lets a single market deployer impose a wallet allowlist on its own venue without affecting other Hyperliquid markets.

  2. Does HIP-3* add KYC to Hyperliquid protocol-wide?

    No. The feature is optional and isolated to a single venue. Hyperliquid has not announced protocol-wide KYC, and the deployer, not the protocol, bears responsibility for compliance on a gated venue.

  3. What powers does a HIP-3* deployer have over allowlisted users?

    Five bounded actions: add or remove allowlist approval, cancel specified resting orders, bulk-cancel resting orders and TWAPs, place reduce-only orders, and move collateral. All proxied orders must be reduce-only.

  4. Is HIP-3* live on mainnet?

    No. As of the Sept. 3 developer update, HIP-3* is testnet-only with no announced mainnet date. Existing Hyperliquid markets are unchanged.

  5. How much HYPE does a HIP-3 deployer need to stake?

    A mainnet HIP-3 deployer must stake 500,000 HYPE. Validators can slash that stake for irregular inputs that jeopardize protocol correctness, uptime, or performance.

Source attribution
Aggregated from CryptoSlate · Verified · Last refreshed 1h ago
Open original →