Core Guide · Step 4 of 5
TL;DR
Hyperliquid uses a non-custodial model: users interact with the exchange through their own wallets. This means control over access and actions sits with the user, not with a traditional exchange account system.
But control also creates responsibility. If an action is authorized and executed, it should not be treated as a mistake that customer support can later fix.
Core idea
In the previous article, we looked at the trade lifecycle: an order can execute, change a position, and that position continues to exist in the system until it is closed or liquidated.
Now the next question is who controls those actions.
On a centralized exchange, the user works through an account. The platform manages access, internal balances, restrictions, and in some cases may intervene through support. Hyperliquid works differently.
The user interacts with the system through a self-custodied wallet. This means access and action authorization are tied to the wallet, not to a normal exchange account. If the wallet authorizes an action and the system executes it, the result becomes part of the trading history. This is where custody and irreversibility connect.
What non-custodial means
Non-custodial means the user does not give private keys to the exchange. The wallet remains the control point. Through it, the user connects, confirms actions, and manages access to funds.
This differs from a centralized exchange, where the user deposits funds into the platform and sees a balance inside an account. In that model, control over the internal environment remains with the exchange operator.
On Hyperliquid, the user does not operate through a classic CEX account system. The user operates through a wallet. This gives more direct control, but it changes expectations around safety, recovery, and mistakes.
Control happens before execution
The key point is that user control exists before the action, not after it. Before an action is confirmed, the user can stop: refuse to sign, not submit, or cancel an open order if it has not executed yet.
But once an action is authorized and executed, the situation changes. The system does not treat the executed result as a draft or a support request. For the system, it is an event that already happened.
The right frame is:
before execution, the user controls what to authorize; after execution, the user owns the consequence.
This is the practical side of self-custody.
Why there is no normal recovery layer
Many users bring centralized exchange expectations into on-chain systems. On a CEX, users may expect support, account recovery, KYC-based identity checks, error review, or suspicious activity controls. Those expectations do not transfer cleanly to a non-custodial system.
If you lose access to your wallet, the system cannot simply “recover your account” like a normal exchange. If you sign the wrong action, it should not be treated as an interface mistake that the operator can later fix. If a trade executes, the result cannot be rolled back through customer support.
This is not a bug. It is a consequence of the control model. The system gives the user direct access, but it does not add the usual recovery layer on top.
Mistake and intention look the same after execution
For the user, the difference between “I meant to do this” and “I made a mistake” is huge. For the system after execution, the more important question is:
was the action authorized and valid under the system rules?
If yes, the result is treated as valid. A wrong position size, wrong direction, accidental confirmation, or poorly calculated risk can all be mistakes from the user’s perspective. But if the action was validly authorized and executed, the system does not need to distinguish mistake from intention.
This is a hard but important part of self-custody. It matters especially in trading, where fast decisions can immediately create financial consequences.
What this control gives you
The non-custodial model does not only remove the usual safety net. It also gives users the reason many people choose on-chain systems in the first place.
The user is not dependent on a normal exchange account in the same way as on a CEX. Access is not built around a login, password, and internal account database controlled by the operator. Funds and actions are tied to the wallet.
This makes the model more direct: the user authorizes actions and owns the result. That is the meaning of self-custody. It does not make the system “safe by default.” It moves control closer to the user.
What this changes for the user
On Hyperliquid, it is more important to check an action before confirmation than to hope for correction afterward.
Before authorizing an action, the user should understand:
- which wallet is connected;
- what action is being confirmed;
- which market is selected;
- what position size is being used;
- what may happen after execution.
This is not a trading strategy guide. It is the basic responsibility model. If an action is authorized and executed, it should be treated as final for the system.
Hyperliquid in custody context
What this page does not explain yet
This page explains control and irreversibility. It does not explain margin or liquidation in detail.
But the next question is now clearer. If the user authorizes actions directly, and a position continues to exist after execution, what happens when that position becomes too risky? That is the role of the next article: margin and liquidation.
Key idea
You can move on when
- You understand that Hyperliquid uses a self-custodied wallet, not a normal CEX account.
- You can explain why control exists before execution.
- You understand why an executed action should not be treated as a reversible request.
- You understand why mistake and intention look the same to the system after execution.
- You can explain the connection: more direct control means more responsibility.