What “non-custodial” actually means with agent approvals

A word that is doing less work than people think

“Non-custodial” has become a trust signal rather than a technical statement, which is unfortunate, because the technical statement is genuinely useful and the trust signal is not. Read as marketing, it suggests safety in general. Read precisely, it makes one specific claim: no third party ever holds your funds, so no third party can withdraw them, freeze them, lend them out, or lose them in an insolvency.

That claim is worth having. It removes an entire category of failure — the category that took down centralised platforms whose users' balances turned out to be liabilities on someone else's balance sheet rather than assets in their own accounts. It is also strictly bounded. Non-custodial says nothing about whether a strategy is sound, whether positions can be liquidated, whether execution will match the leader, or whether you can lose money. You can lose your entire balance in a fully non-custodial system. Custody and risk are different axes, and conflating them is the most common mistake in this area.

So the question worth asking of any copy trading product is not whether it calls itself non-custodial. It is: what exactly is this system permitted to do with my account, and how do I withdraw that permission.

Custody versus trade-only permission

Custody means someone else controls the keys that can move your funds. You deposit to an address they own, your balance becomes an entry in their ledger, and every action you take is a request they choose to honour. Withdrawal is a permission they grant. If they are compromised, insolvent, or simply decide to halt withdrawals, your recourse is legal rather than technical.

Trade-only permission is a different structure. The funds remain in an account whose ownership key you hold. What you delegate is not control of the assets but authority to perform a specific class of actions on them — in this case, trading. The delegated party can change what your capital is exposed to. It cannot change where your capital is.

That distinction has a concrete consequence in the failure case. If a system with trade-only permission is compromised, the attacker inherits the ability to trade your account badly. That is a real loss vector and should not be minimised — a hostile actor with trading authority can open reckless positions and lose funds through the market. What they cannot do is send your balance to an address they control. The worst case is bounded by market outcomes rather than by theft, and it does not depend on anyone's solvency but your own.

What a Hyperliquid agent approval actually grants

Hyperliquid implements this delegation natively through its agent system, sometimes called API wallets. You sign a one-time approval, using your own wallet, that authorises a named agent address to submit signed actions on behalf of your account. The approval is an action on Hyperliquid itself, signed by the account owner, and it identifies exactly which address is being granted authority.

Once approved, the agent can sign the trading actions Hyperliquid exposes to agents: placing orders, cancelling orders, modifying orders, opening and closing positions, and adjusting leverage or margin settings on the positions it manages. In our case that authority is what allows mirrored trades to be executed in each isolated sub-account without you signing every individual order — which is the only way a copy trading system can function at all, since leaders trade continuously and manual approval per order would guarantee the exposure never matched.

Two properties of the approval are worth being precise about. It is address-scoped: authority belongs to the specific agent address you approved, and no other address inherits it. And it is separate from ownership: the agent key is not your account key, cannot derive it, and holds no claim on the account beyond the action set Hyperliquid permits agents to sign. Approving an agent does not hand over your wallet — it registers a second, deliberately weaker signer.

There is also a separate approval most users encounter alongside it: the builder fee. That authorises a fee of 0.1% on mirrored notional, and it is a distinct permission with a distinct cap, not a component of the trading authority. Two approvals, two purposes, both signed explicitly by you.

What the agent cannot do

The security argument rests on the exclusions, so they are worth stating plainly rather than gesturing at.

What remains inside the agent's authority is exactly what a copy trading system needs and nothing beyond it: the ability to place and close trades. That is not a small permission — losses through the market are entirely possible — but it is the minimum viable permission for the function, which is the right standard to hold a system to.

• It cannot withdraw. Withdrawals from Hyperliquid to an external chain address require the account owner's signature. Agent authority does not extend to withdrawal actions, so no agent — ours or a compromised one — can move funds off the account.
• It cannot transfer funds to another address. Sending your balance to a third party is not in the agent action set. Capital can be moved between your own account and your own sub-accounts as part of allocation, but it cannot leave the ownership boundary you control.
• It cannot change ownership or take over the account. The account key stays with you. An agent cannot rotate it, replace it, or lock you out.
• It cannot approve further agents. Delegation does not compound. Only the account owner can approve an agent, so an agent cannot widen its own permissions or create a second signer.
• It cannot prevent you from acting. Your own key retains full authority the entire time. You can trade the account yourself, close mirrored positions manually, or withdraw, at any moment, without asking us and without waiting for us.

Why revocability matters

A permission you cannot withdraw unilaterally is not really a permission; it is a transfer. Revocability is what keeps the delegation reversible, and it is the property that most distinguishes this model from custody in practice rather than in principle.

Because approval is an on-chain action on your own account, so is removing it. You revoke agent authority with your own key. You do not need our cooperation, our uptime, or our agreement — and critically, you do not need to move funds to exit. Under custody, leaving means requesting a withdrawal and waiting for someone else to process it, which is precisely the step that fails when a platform is in trouble. Here, revocation stops future trading authority immediately while your balance stays exactly where it already was.

Two things worth being honest about. Revoking does not close positions: any open mirrored positions remain open, with their own margin and liquidation prices, until you or the system closes them — so if your intent is to be flat, revoke and then close, or close and then revoke. And revocation is not retroactive. It ends authority going forward; it does not reverse trades already executed. Revocability limits the duration of exposure to a delegated signer, not the consequences of what that signer already did.

How this compares to the alternatives

Exchange API keys are the closest analogue and the comparison is instructive. A trade-only API key with withdrawals disabled achieves a similar separation of powers, and it is a reasonable model. The differences are in enforcement and verifiability: the API key's permission scope is a setting in a centralised exchange's system, applied to funds that exchange already custodies, and you verify it by trusting their interface. A Hyperliquid agent approval is an on-chain action against an account you own, with the action set enforced by the protocol rather than by a permissions table. If the operator of an API-key system is compromised, your key is exposed but your funds also already sit with a custodian; here there is no custodian in the path at all.

Custodial copy trading platforms are a straightforwardly different risk category. You deposit, they hold, they trade, and you hold a claim. That adds counterparty risk, insolvency risk and withdrawal-halt risk on top of every market risk you already carry, and none of those additional risks are compensated by anything. They exist purely as a consequence of the architecture.

Pooled and fund-style structures go further: your capital is commingled with other users' in a shared account or vehicle. Beyond counterparty exposure, that removes the independence of your position — your entry price, your liquidation risk and your realized outcome are entangled with other participants' flows and, in a netted account, with their opposing positions. Our model is the opposite structure by design: capital sits in your own account, mirrored into your own isolated sub-accounts, one per leader, each with separate margin and a separate liquidation price. Your positions are yours, individually attributable, and unaffected by anyone else's behaviour.

Permission design is a risk decision

Every automated trading system requires you to delegate something, because automation without delegation is a contradiction. The only real question is how much, enforced by what, and how quickly you can take it back. That is a design decision, and it belongs in the same conversation as leverage limits and position sizing rather than in a marketing paragraph.

The model here is deliberately narrow: trading authority only, scoped to one approved agent address, enforced by Hyperliquid rather than by our promises, revocable by you at any time, with funds never leaving accounts you own. It removes custody risk and counterparty risk from the picture. It does not remove market risk, liquidation risk, execution slippage or the possibility that a leader performs badly — and a system that implied otherwise would be misrepresenting what a permission model can do.

If you want the full picture, the documentation sets out the approval steps and the isolation model in detail, and the risk disclosure states plainly what this architecture does not protect you from.