Non-custodial is not the same as decentralised

Non-custodial is a statement about keys. It means your funds cannot be moved without your signature. That is a real and substantial guarantee, and it is not the same claim as the one the word "decentralised" makes.

Confusing the two is how venues get described in ways their own documentation does not support.

The two properties are separable, and the docs separate them

Uniswap's v4 whitepaper lists three properties, not one: "non-custodial, non-upgradable, and permissionless." The whitepaper treats them as distinct because a system can hold the first and fail the other two.

Hyperliquid uses the word "non-custodial" sparingly, and when the docs do define it, the definition is purely about keys: only your private key or seed phrase can sign on your address.

That is the honest scope of the claim. Your balance is yours in the sense that nobody can move it without you. What the word does not cover is who can pause the venue, who determines the price your margin is measured against, and who decides what is allowed to trade.

ethereum.org draws the line in similar terms: an app "can set its own rules and block certain actions inside that app, but those rules end where the app ends." Custody describes the asset layer. Access to the interface is a separate layer.

What "non-custodial" does not settle

It does not mean nobody can halt trading. Hyperliquid's HIP-3 documents the clearest case in current perp DEX architecture. Builder-deployed perpetuals give the deployer a unilateral action the docs call haltTrading, and the description is unambiguous:

The deployer may settle an asset using the haltTrading action. This cancels all orders and settles positions to the current mark price. The same action can be used to resume trading, effectively recycling the asset.

One party, one action, every position closed at a price of that party's choosing, and trading resumed afterwards. Deployment requires 500k HYPE of stake, which is a high bar. It is still a single party with the power.

It does not mean the oracle is independent. The same proposal documents that on HIP-3-style markets, mark prices are derived from the deployer's own spot oracle price inputs. The price your margin is measured against is then set by the party who can also halt the market. The docs also describe a deployer-designated oracle updater role.

Core Hyperliquid perps do not work this way. Their oracle is a median of external spot venues weighted by volume, published by validators, and then a stake-weighted median across the validators themselves. The distinction between core perps and builder-deployed perps is worth holding on to, because "Hyperliquid" as a name covers both.

It does not mean listings are permissionless. Hyperliquid's validator documentation describes the current state in the future tense: the listing process will feature "a decentralized and permissionless" design. It does not claim to have one today.

It does not guarantee uptime. Hyperliquid's own documentation for its Foundation node states that "no guarantees are made regarding availability, latency, performance, or data completeness."

Validators: what the numbers actually say

Hyperliquid's validator documentation says the active set is the "top twenty-seven by stake."

I queried the public validator API directly. It returns 27 active validators, which matches the documentation.

The distribution is the part worth knowing. Read from the API on this date, five nodes operating under the Hyper Foundation name hold 47.55% of active-set stake, and the top ten hold roughly three quarters. That is a stake-weighted median, so a bloc above a third carries decisive influence over the oracle median.

Two things follow from that, and neither is a criticism. A stake-weighted median is genuinely robust to individual validators going offline or being wrong. And running a validator is permissionless. But a validator set with nearly half its stake in one organisation's nodes is a different structure from a validator set with half its stake dispersed across dozens of unrelated operators, and the docs themselves describe both facts in the same page.

There is also a delegation programme, documented, that is KYC-gated and excludes the US and Ontario. The docs state that Foundation validators "will strongly consider participation in the Delegation Program as a factor for trusting peer validators." Node operation being permissionless and validator trust being shaped by a Foundation programme are two different statements, and both appear in the documentation.

The clearest proof the claims are separate

dYdX documents a chain halt in its own upgrade history: the network stopped at a specific height, v9.2.0 "needed emergency patching," and v9.3.0 was the permanent fix. Later releases carry a "height poisoning fix" and a set of security fixes.

During that halt, user funds remained non-custodial. Nobody could move anyone's balance without their key. The chain also stopped working.

That is the whole argument in one event. Custody held; availability did not. A protocol can be exactly as non-custodial as it claims and still halt.

How to evaluate this without overclaiming in either direction

Ask who holds the key. That answer is verifiable and it matters most. Everything else is second-order.

Ask where the ordering decision is made, and how many parties can overturn it. Then read the current number from the chain rather than from a headline, because validator counts and stake distributions move.

Ask whether the oracle is external or deployer-supplied. For Hyperliquid that differs between core perps and builder-deployed markets.

Ask whether there is a documented exit path that does not require the operator's permission. Some protocols publish one. Others do not.

Keep the two axes separate. Non-custodial and decentralised describe different properties. Conflating them is how a venue ends up described in terms its own documentation contradicts.

The wider point

The honest framing is not that non-custodial venues are centralised. It is that "non-custodial but centralised" is an accurate description of a design in which custody is decentralised and ordering is not, and that most serious venues are somewhere on that spectrum rather than at either end.

Writing it as a gotcha misreads the mechanism. Writing it as a guarantee reads the documentation wrong. Both mistakes cost traders something, because one produces false confidence and the other produces a false sense that a real property has been debunked.

Risk note: cryptocurrency trading and leveraged perpetual futures carry significant risk of rapid and total financial loss. Never risk funds you cannot afford to lose completely. Assess the custody, ordering and governance model of any venue before depositing; non-custodial status addresses asset custody only. Nothing in this article is investment advice, a recommendation, or an offer to sell any product.