Sub-accounts & multiple wallets: one owner, one record
updated october 2026 · ~4 min · not tax advice
Splitting strategies, not ownership
Hyperliquid traders split activity constantly: sub-accounts under a master address, separate wallets for separate strategies, vault deposits, builder-dex front ends. Every one of these produces its own address-level activity on the ledger.
The tax record doesn't care about that structure. Sub-accounts and wallets under the same beneficial owner are one taxable record — their gains, losses, funding and fees aggregate onto one return. What the tooling has to get right is recognizing that structure instead of treating each address as a stranger.
What single-address tools get wrong
Read addresses one at a time and your own transfers become phantom disposals. USDC moved from wallet A to wallet B looks like a withdrawal from A (possibly a send to someone else — a gift, a payment) and a deposit into B. A naive importer can book the A-side as a disposition or flag the B-side as unexplained income. Neither happened — you moved your own money.
Inventory basis strands. Spot bought on address A, transferred to B, then sold — the acquisition cost lives in A's history. A tool that only sees B reports an unknown basis; a tool that merges naively may pair B's sale against B's own fills and never see A's lot at all.
Perp positions are the boundary case in the other direction: a perp position can't be transferred between addresses, so each address's perp books must be computed independently — merging fills before closing lots produces wrong pairing. Correct merging is compute-per-address, aggregate-after.
What a merged report requires
Internal-transfer classification: sends, internal transfers and sub-account moves between grouped addresses are tagged internal and excluded from external flow totals — no invented disposals, no unexplained income.
Independent books per address: perp lots, fills, funding and fees computed separately, then aggregated — matching how the venue actually segregates positions.
Known limits disclosed: spot inventory moved between your own addresses doesn't automatically carry its basis to the receiver — reconstructing that chain needs the sending lot's cost, which is exported for your preparer rather than guessed.
The paid report supports a primary address plus up to eight more, prices on combined fill count, and marks every internal transfer explicitly in the evidence manifest.
Common questions
?Is moving USDC between my own wallets taxable?
A transfer between addresses you control is not a disposal — no sale occurred. The problem is tooling: single-address importers can't see that and may report it as income, a gift, or a disposition. The transfer has to be classified internal, which requires declaring the group of addresses up front.
?Do sub-accounts need their own tax records?
They produce separate address-level activity, but they aggregate onto the same owner's return. Each needs its own lot computation (perp positions can't move between accounts), and transfers among them need internal classification — then the results merge into one record.
?What about a wallet I use on multiple chains or venues?
Cross-venue basis is a different problem — an asset bought on Kraken and deposited to Hyperliquid carries its exchange cost. The paid report ingests Kraken/Coinbase exports to carry that basis in; intra-group Hyperliquid transfers are handled by the merged-address logic.
?Can I just export each wallet separately and add the numbers?
Partially — perp PnL and funding do sum across addresses. What breaks is the edges: inter-wallet transfers misclassified, and spot lots whose acquisition history lives on a different address than the sale. Those rows need the group context, not another CSV.
One report across your addresses
Add up to eight extra addresses at order time. Each gets its own books, transfers between them are classified internal, and the merged result ships as one PDF + CSV set.