Skip to main content
What you’ll build:
  • Fetch a wallet’s total PnL (realized, unrealized, fees, external flows)
  • Batch-query PnL for up to 100 tokens in one call, with per-token breakdowns
  • Compare the same token’s performance across different chains
  • Use time-range filters for period-specific PnL
  • Handle edge cases (503 bootstrap, airdrops)
Time: ~10 minutes

Prerequisites

  • A Zerion API key (get one here)
  • Node.js 18+ (for native fetch) or any HTTP client

How PnL is calculated

Zerion uses FIFO (First In, First Out). It matches earliest purchases against earliest sales. This is the most common standard for tax reporting.

Response fields

When you add token filters (fungible_ids or fungible_implementations), the response also includes a breakdown object with per-token stats like average_buy_price, average_sell_price, and gain percentages.
The resource type in the response is wallet_pnl (not pnl).

Steps

1

Portfolio-level PnL

Fetch overall PnL for a wallet across all tokens and chains.GET /v1/wallets/{address}/pnl?currency=usd
2

Batch PnL for specific tokens

Pass up to 100 tokens in a single request to get a per-token breakdown. There are two filtering modes:Option A: fungible_ids (cross-chain)Aggregates PnL for a token across all chains. Best for portfolio-level token views where you don’t care which chain the activity happened on.
Example response (breakdown.by_id):
When you filter by token, the top-level fields (realized_gain, net_invested, etc.) reflect only the filtered tokens, not your entire wallet.
Option B: fungible_implementations (chain-specific)Tracks PnL per chain deployment. Use chain:contract_address pairs. Best for comparing the same token across L1s and L2s, or when you need chain-level precision.
Native chain tokens use chain: with an empty address after the colon: ethereum: for ETH, base: for Base ETH, polygon: for MATIC, solana: for SOL.
Per-token breakdown fields:Each entry in the breakdown object (whether by_id or by_implementation) contains:
3

Time-range PnL

Scope PnL calculations to a specific time window using the since and till parameters. Values are Unix timestamps in milliseconds.
Standard time ranges (1 day, 1 week, 1 month, 1 year, and annual recap from the beginning of the current year) benefit from pre-computed snapshots and return in under 200 ms at p99. Custom ranges may take longer depending on wallet history size.You can combine since/till with token filters.
Unrealized gains are always calculated using current market prices, regardless of the till parameter. If you set till to a past date, realized gains reflect that period, but unrealized gains use today’s prices.
4

Filter by chain

Scope PnL to specific chains using filter[chain_ids].GET /v1/wallets/{address}/pnl?currency=usd&filter[chain_ids]=ethereum,base
Useful when your app is chain-specific (e.g., a Base-only wallet) or you want to compare PnL across different L2s.
Zerion ignores filter[chain_ids] when you use fungible_implementations. The chain is already embedded in each implementation string.
5

Full working example

Save as pnl-dashboard.mjs and run with node pnl-dashboard.mjs:

Edge cases & operational notes

For wallets that haven’t been queried before, or wallets with long transaction histories, the first request may return a 503 with a Retry-After header while PnL is being bootstrapped. This is non-billable. Retry after the indicated delay (usually a few seconds). Once bootstrapped, subsequent requests are fast: under 200 ms for basic PnL queries without a breakdown. Building a breakdown adds 150–300 ms depending on the number of tokens. Snapshots are retained for ~1 month; after that, a re-bootstrap may be triggered.A 503 always carries a Retry-After header. If you get an error without one, retrying is not the answer. See the next two entries.
Wallets with more than 1 million actions are too large for PnL to be calculated, and return 422 with no Retry-After header:
Don’t fold this into your 503 retry loop. The helper above only recurses on 503, so a 422 surfaces to the caller instead. Don’t cache it against the address either: the same wallet can return 503 again later if its cached state is rebuilt.
Zerion only calculates PnL for addresses that behave like user wallets. Zerion rejects contract addresses that aren’t recognized smart-contract wallets, burn addresses, and high-volume addresses such as exchange hot wallets before doing any work:
Smart-contract wallets are fine: Safe, Coinbase Smart Wallet and ERC-4337 accounts all work. See Error handling for the full rule.
Tokens without reliable price data are omitted from breakdown calculations rather than erroring. They won’t appear in the breakdown object.
Tokens received as “pure mints” (from the zero address or a token contract with no payment beyond gas) are assigned zero cost basis. However, many airdrops are actually distributed from a non-zero address, which causes them to be misclassified as purchases at the market price at the time of receipt. Keep this in mind when reviewing cost basis data for airdropped tokens.
Native chain tokens use chain: with an empty address after the colon: ethereum: for ETH, base: for Base ETH, polygon: for MATIC, solana: for SOL.
16 options via the currency param: usd, eur, gbp, btc, eth, krw, jpy, aud, cad, inr, nzd, try, zar, cny, chf, rub.
Max 100 tokens per request for either fungible_ids or fungible_implementations. For larger portfolios, paginate with multiple calls.

Next steps

  • Combine with wallet positions to fetch current holdings, then batch those token IDs into PnL for a complete dashboard
  • Add balance charts to visualize portfolio value over time alongside PnL
  • Set up webhooks to trigger PnL recalculations when new transactions land