SEO target: "Hyperliquid PnL calculation" / "Hyperliquid portfolio tracking" / "how to track Hyperliquid performance"

KD: 5–10 (Very High — technical builder content on HL is almost nonexistent)

Funnel stage: Mid-funnel — HL builders, quant traders, fund analysts, infra teams evaluating data providers

Hook: Technical deep-dive. The methodology article. Targets builders and quant-oriented traders who want to understand how the numbers should work — and why most tools get them wrong.

The Calculation Problem No One Talks About

Hyperliquid has grown fast. Its trading volumes are real. Its user base is sophisticated. And the tooling for actually analysing what's happening in a wallet — properly, with correct methodology — is almost nonexistent.

This is not a criticism of the Hyperliquid team. Building a high-performance perpetuals exchange is a hard problem. Building the analytics layer on top of it is a different hard problem, and it's not one that exchange teams are optimally positioned to solve.

We've spent the last almost 2 years building exactly this layer — first for institutional fund clients who need auditable, LP-reportable performance data, and now as a free consumer tool at trckr.xyz. Along the way we've worked through every calculation problem that Hyperliquid's structure creates.

This article is the technical record of what those problems are and how we solved them.

Problem 1: Separating Funding PnL from Mark-to-Market PnL

This is the most common error in Hyperliquid PnL calculators, and it matters because the two types of return have completely different characteristics.

Mark-to-market PnL is what you'd expect: the change in value of your position based on price movement. If you're long 1 BTC perp at $80,000 and the price moves to $85,000, your unrealised MTM PnL is $5,000.

Funding PnL is a continuous cash flow that accrues between your position and the counterparty holding the opposite side. On a crowded long, funding is positive for shorts and negative for longs. On a crowded short, the reverse. Funding rates on Hyperliquid can be substantial — during high-volatility or highly imbalanced periods, annualised funding rates on some assets exceed 100%.

The correct treatment: funding is income or expense that accrues to your account separately from the mark-to-market movement of the position. It should be reported separately in any performance attribution framework, because it has different risk characteristics (it's relatively predictable for carry traders, and it's a significant drag or tailwind that needs to be isolated to understand the underlying strategy).

The common error: many wallet tools compute realised PnL as (exit price - entry price) × size, and treat any remaining account balance change as "other income." This works for spot. It doesn't work for perps, where the funding stream runs continuously and the settlement mechanics mean your effective entry price changes with each funding event.

Our implementation: we pull full position event history from the Hyperliquid API — not just current state. For each position, we reconstruct the funding payment stream by timestamp, calculate the total funding income or expense over the holding period, and report it as a separate P&L component. MTM PnL is calculated net of funding effects, so the two components sum to total return without double-counting.

Problem 2: Cost Basis Across Partial Entries and Exits

Cost basis sounds simple. In practice, with partial fills, multiple entry legs, and partial exits, it requires careful implementation.

Consider a wallet that:

• Bought 2 ETH perp at $3,000

• Added 1 ETH at $3,200

• Sold 1.5 ETH at $3,400

• Currently holds 1.5 ETH at current market price

The cost basis of the remaining 1.5 ETH position is not simply $3,000 or $3,200. It's the weighted average entry price of the lots that remain after the partial exit, which requires knowing which lots were consumed by the exit (FIFO, LIFO, or average cost) and applying that consistently.

Our implementation: we use average cost basis (AVCO) methodology, which is both the most common institutional standard and the most stable for portfolio analytics. Each position entry is logged with size and price. Exits are applied against the running average. The resulting cost basis is used both for realised PnL calculation on closed positions and for unrealised PnL on open ones.

This matters particularly for Hyperliquid traders running partial position management — scaling in and out of positions as conviction changes. A tool that doesn't handle this correctly will show cost basis numbers that don't correspond to any defensible accounting treatment.

Problem 3: Vault Position Valuation

Hyperliquid's HLP vault and other liquidity vaults are denominated in vault shares, not in USDC or the underlying asset. The share price changes continuously as the vault accrues trading fees, funding income, and realised PnL from its market-making activity.

The naive approach: read the vault balance in shares and multiply by last known share price. This works at a moment in time but produces incorrect historical values because the share price at any historical point must be reconstructed from the vault's own PnL history.

Our implementation: we snapshot vault share prices at regular intervals and reconstruct historical NAV for vault positions using the timestamped share price series. This gives us a continuous valuation curve that correctly attributes vault performance to the periods in which it occurred, rather than marking all vault gains at the current share price.

This is particularly important for TWRR calculation (see below), which requires accurate valuations at every external cash flow event.

Problem 4: TWRR vs. Simple Return — Why the Methodology Choice Matters

Most wallet tools show you a simple return: (ending value - beginning value + withdrawals) / beginning value. This is easy to calculate and intuitive to understand, but it's misleading for any wallet with external cash flows (deposits and withdrawals).

The problem: if a wallet deposits $100K at the start of a good month and $500K at the start of a bad month, the simple return will be dominated by the large deposit into the bad period, making performance look worse than the actual investment decisions warranted. The reverse is also true. Simple returns conflate the timing of capital allocation with the quality of investment decisions.

Time-weighted rate of return (TWRR) eliminates this distortion by calculating the return for each sub-period between external cash flows and then geometrically linking them. The result is a performance number that reflects only the investment decisions, not when capital happened to flow in or out.

TWRR is the standard methodology for institutional fund performance reporting (GIPS compliant) and the correct method for any wallet that has had deposits or withdrawals.

Our implementation: we identify every external cash flow event (deposits and withdrawals to/from the Hyperliquid account) and calculate the sub-period return between each. These sub-period returns are geometrically linked to produce the TWRR for any requested period. For wallets with no external cash flows, TWRR and simple return are equivalent — we handle this as a degenerate case.

Problem 5: Capital Flow Reconciliation

A complete picture of wallet performance requires understanding not just returns but capital flows: how much was deposited, how much was withdrawn, what is the net invested capital, and what is the total value created or destroyed.

On Hyperliquid, deposits and withdrawals are on-chain events that can be read from transaction history. But there are subtleties:

• Transfers between sub-accounts are not external flows — they're internal reallocation

• Bridge transactions may have fees that create apparent discrepancies between deposited and received amounts

• Staking rewards and airdrops to the account are income events, not deposits

Our implementation: we classify every account inflow and outflow into one of four categories: external deposit, external withdrawal, internal transfer, or income event. Only the first two count as external cash flows for TWRR calculation. Income events are attributed as returns in the period they occur. Internal transfers are netted within the account and don't affect performance calculation.

This classification requires reading both the on-chain transaction data and the Hyperliquid internal account event log, and matching them against each other to resolve ambiguities.

What This Means for Building on Top of Hyperliquid Data

If you're building analytics, reporting, or risk tools for the Hyperliquid ecosystem, the above framework is the floor for getting the numbers right. Below it, you're producing numbers that look plausible but don't hold up to scrutiny.

The Hyperliquid API is well-documented and the data is available. The complexity is in the calculation layer — deciding on the right methodology, implementing it consistently, and handling the edge cases (partial fills, vault positions, multi-asset accounts with cross-margined perps) that the naive approach misses.

We've built this once, and it now powers both trckr.xyz (free consumer tool) and the institutional portfolio management infrastructure at Renesis. If you're building something in the HL ecosystem and want to integrate correct wallet analytics rather than rebuilding the calculation layer from scratch, we're open to conversations about data access and API integration.

*trckr.xyz — free Hyperliquid wallet tracker built on this methodology. No sign-up required.*

Renesis provides institutional portfolio infrastructure for liquid crypto funds — NAV calculation, CeFi + DeFi reconciliation, and LP reporting built on the same data layer.