# Canonical: https://www.uddalak.xyz/hyperliquid-academy/article/20-subaccounts-api-wallets
# Author: Uddalak Das
# Last source: https://www.uddalak.xyz/hyperliquid-academy/article/20-subaccounts-api-wallets

---
title: "Subaccounts and API Wallets"
description: "How professional users separate strategies and authorize automated trading on Hyperliquid."
track: "Trading & Risk"
level: "Advanced"
primary_icp: ["builder", "trader"]
secondary_icp: ["institutional decision-maker"]
reading_time: "5 min"
last_reviewed: "2026-09-07"
---

# Subaccounts and API Wallets

Subaccounts and API wallets solve different operational problems. A subaccount separates trading state under one master account. An API wallet, also called an agent wallet, is an authorized signing key that can submit supported actions for the master account or a subaccount.

Used together, they let a trading operation separate strategies while keeping the master private key away from day to day execution processes.

```mermaid
flowchart LR
    A[Master account] --> B[Subaccount A]
    A --> C[Subaccount B]
    A --> D[API wallet 1]
    A --> E[API wallet 2]
    D --> F[Signs supported actions for A]
    E --> G[Signs supported actions for B]
```

## Subaccounts separate positions and balances

A subaccount creates a distinct trading state under the same master relationship. Strategies can therefore hold different positions, orders, and balances without creating completely unrelated master wallets.

This is useful for separating market making from directional trading, isolating teams or strategies, simplifying accounting, or enforcing different internal risk limits.

Subaccounts still inherit parts of the master account relationship, including fee tier behavior under the current rules. They are therefore a trading organization tool rather than independent identities in every respect.

## API wallets separate signing authority

An API wallet is a key authorized to sign supported actions. The trading process can hold that key without holding the master account's private key.

This is a major security improvement for automated systems because the most sensitive key does not need to sit on every trading server.

It is not complete isolation. An authorized API wallet can still perform the actions its authorization permits. Key storage, monitoring, revocation, process isolation, and expiry management remain part of the security model.

## Account identity and signer identity are not the same

A common integration mistake is to treat the API wallet address as if it were the trading account itself.

The API wallet is the signer. The master account or subaccount is the state whose positions and balances are being changed. Querying state for the agent address can therefore return information about the signer rather than the intended trading account.

Production systems should carry both identities explicitly throughout order submission, account queries, logging, and reconciliation.

## Nonces are designed for concurrent trading

Hyperliquid's nonce system differs from a simple strictly sequential Ethereum transaction nonce. The protocol tracks a window of recent nonces per signer, which allows multiple actions to be in flight without forcing every trading process through one global sequential queue.

The operational consequence is still important. Two processes using the same API wallet can collide if they generate overlapping nonce values or fail to coordinate timing.

Hyperliquid's documentation recommends separating API wallets across independent processes where appropriate. [Nonces and replay protection](/hyperliquid-academy/article/88-hyperliquid-nonces-replay-protection) covers the deeper mechanics.

## A practical institutional structure

A fund might keep the master key in a highly controlled signing environment, create subaccounts for strategies, and authorize different API wallets for each execution process.

That structure creates several boundaries at once. Strategy PnL is separated by subaccount, execution keys can be rotated independently, and compromise of one API wallet does not require placing the master key on the affected server.

The design should still include withdrawal controls, monitoring, kill switches, and reconciliation around every signer.

## Continue reading

Read [Designing API Wallets for Hyperliquid Trading Systems](/hyperliquid-academy/article/89-designing-api-wallets-for-trading-systems) for production key architecture and [How Funds Can Structure Hyperliquid Subaccounts and API Wallets](/hyperliquid-academy/article/125-funds-subaccounts-api-wallets) for an institutional implementation.

## Sources

- https://hyperliquid.gitbook.io/hyperliquid-docs/trading/sub-accounts
- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/nonces-and-api-wallets
- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint