# Sub-accounts

Lighter supports native sub-accounts: additional accounts under the same L1 owner, each with its own `account_index`, positions, and independently registered API keys. This recipe doesn't implement sub-accounts — it trades a single account — but the mechanism is worth knowing if you're isolating strategies or clients under one wallet.

## How sub-accounts work

A sub-account is created with a plain **account-creation transaction type** (`create_sub_account` in `lighter-go`) that presupposes a main account already exists. Per `lighter-go`'s source, creating one doesn't carry an L1 signature the way `ChangePubKey` and deposits do — so unlike registering the main account, opening a sub-account doesn't require a fresh `personal_sign` from your Openfort wallet. It's signed the same way an order is, with a registered API key.

:::info
This recipe's vendored WASM signer supports the underlying `SignCreateSubAccount` and `SignUpdateLeverage` bindings — both are covered by `lighter-go`'s own test fixtures — but `server/signer/signer.ts` doesn't currently wrap them, since the demo only ever trades one account. Wrapping them follows the same pattern as `signCreateOrder` in [Executing trades](/docs/recipes/lighter/trading).
:::

## What each sub-account needs

* Its own `account_index`, assigned when the sub-account creation transaction is processed.
* Its own registered API key(s) — following the same [`ChangePubKey` flow](/docs/recipes/lighter/api-keys) as the main account, since API keys are scoped to a single `(accountIndex, apiKeyIndex)` pair.
* Its own funding. Lighter's accounts don't share margin; moving funds between the main account and a sub-account is a transfer, not an automatic allocation.

## Use cases

* **Strategy isolation** — run independent trading strategies with separate margin, so a liquidation in one doesn't touch the others.
* **Client segregation** — if your server trades on behalf of multiple end users under one L1 owner, a sub-account per user keeps their positions and API keys independent.
* **Risk tiering** — keep a conservative, always-on strategy separate from an experimental one without needing a second L1 wallet (and a second deposit).

## Before implementing

Since this recipe doesn't exercise sub-accounts end-to-end, treat the above as a starting point, not a verified integration:

* Confirm the exact `CreateSubAccount` transaction fields and required nonce/signature scheme against `lighter-go`'s `types/txtypes/create_sub_account.go` before wiring it up — the same way [`docs/lighter-signing-notes.md`](https://github.com/openfort-xyz/recipes-hub/blob/main/lighter/docs/lighter-signing-notes.md) does for `ChangePubKey`.
* Extend `server/signer/signer.ts` with a typed wrapper for `SignCreateSubAccount`, following the existing wrappers' pattern of named parameters over the WASM binding's raw positional arguments.
* Each sub-account still needs its own [Openfort policy](/docs/recipes/lighter/policies) scoping if you fund it directly from the Openfort wallet.