Zapper portfolio balances grouped by network

Zapper portfolio data grouped wallet tokens and supported decentralized finance (DeFi) positions by network, helping users understand the location of their displayed holdings. Token amounts, application positions, and monetary estimates answered different questions within that breakdown. Zapper announced an orderly wind-down, with its website, mobile apps, and API scheduled to shut down on August 3, 2026. Historical portfolio records remain useful for understanding allocation, provided their network scope, included addresses, and balance dates stay attached to the figures. A displayed total alone leaves those distinctions unresolved.

Last updated · October 11, 2026

The selected networks defined the visible portfolio

While the service operated, looking up an address across relevant supported networks was the ordinary way to inspect its portfolio. A network-specific view isolated holdings on that chain. An apparently missing asset could also sit outside the selection, so widening the network scope offered a reversible way to examine an omission. Changing the selection didn’t move tokens between networks or alter a protocol position.

Portfolio scope also included the queried addresses. An aggregate for a wallet bundle and a single-address view could legitimately describe different holdings.

Position labels separated holdings from liabilities

Application positions described how assets participated in a protocol, while direct token balances described holdings at the wallet address. A supplied position represented an asset deposited into an application; a borrowed balance represented an obligation. Staked holdings and liquidity pool interests had their own application context. Within a network subtotal, the same monetary unit could describe an asset, a liability, or a protocol interest’s valuation. A reconstructed net total also needed to account for debt without subtracting it twice from an already net figure.

Zapper’s older Curve balance endpoint included underlying token amounts for supported pool positions. Those amounts described the assets represented by the pool interest. Where the underlying tokens explained that same interest, adding their value to the full position value would count it twice. A pool share and its underlying tokens described the holding at different levels. The pool token amount also used its own unit, so it wasn’t interchangeable with an underlying token amount.

A position’s displayed value didn’t establish its immediate withdrawal value. The underlying protocol’s withdrawal conditions still governed access to the assets.

Network totals described allocation and valuation

Network breakdowns showed where the displayed value sat across the selected chains. Zapper’s portfolio data also separated tokens, DeFi positions, and non-fungible tokens (NFTs), and supported account-level breakdowns. A network subtotal could include several asset types; an asset-type subtotal could span several networks. Adding a chain subtotal to a DeFi subtotal could count the same position twice. The grouping labels therefore belonged beside every subtotal retained for comparison.

Monetary estimates combined a balance with a token price or a position valuation. Token amounts could remain unchanged while the monetary total moved with prices. Transfers and new deposits could also change the value a wallet showed without demonstrating investment returns. A performance calculation needed transaction history and a consistent treatment of contributions and withdrawals. Network allocation described the distribution of the displayed holdings, so it couldn’t settle whether a position had earned a profit.

Correcting a filtered subtotal in a saved portfolio

In this hypothetical example, a saved Zapper dataset includes a wallet’s supported liquidity pool position, but a local network filter excludes it from the review. The reader wants to include the position in its network subtotal while preserving the original record. An apparent omission alone doesn’t justify moving funds, deleting a balance row, or treating the position as closed. The smallest change is to widen the local filter without editing the dataset.

Open full-size image

The position then appears in the network group recorded for it. Before accepting the revised subtotal, the reader matches its account, network, and position identity to the retained data. The underlying token details describe the matched position’s composition. When those details agree, the reader accepts the corrected network subtotal and retains the original file. If the identifiers disagree, the entry stays separate until the reader can identify it.

This correction restores the position to the filtered network subtotal. Its present balance still requires current data.

Integration coverage and price data limited the total

Zapper’s DeFi adapters supplied balance data for integrated applications. Network support and application support described different layers of coverage. Reading ordinary token holdings on a chain didn’t establish that every lending, staking, or liquidity position would appear. A recognized wallet token could represent an application interest the portfolio hadn’t decoded. Coverage depended on the integration’s ability to read that holding and its underlying assets. An incomplete application view could therefore understate the displayed exposure even when the network itself appeared in the portfolio.

Price data added a separate limitation. A token amount described a holding in its own units; its monetary estimate needed a corresponding price. An unavailable estimate didn’t turn an existing token balance into zero. Conversely, a displayed price couldn’t establish how much a particular sale would receive. A liquidity pool position required interpretation of its underlying assets, while an NFT’s estimated value remained distinct from available sale proceeds. These distinctions affected how far a portfolio total could support a valuation of the holdings.

Coverage gaps and valuation gaps had different consequences. One could omit a holding entirely; the other could leave a known balance without a monetary estimate.

Record freshness mattered too. In Zapper’s 2023 REST balance interface, ordinary reads could return cached balances, and the records included a calculation timestamp. That behavior belonged to those endpoints; it shouldn’t be assumed for every later data product. A saved record described balances at its calculation date. A retrieval date or recently saved screenshot didn’t make its contents more recent than the underlying calculation.

Retained records and the announced service shutdown

Old portfolio records can preserve an address’s network allocation after a tracking interface disappears. Their practical value comes from keeping balance units, valuation currency, and calculation dates beside the holdings. A screenshot showing only a grand total loses much of that context. A retained balance response can carry more detail, although the returned fields depend on the API interface used. When Zapper’s services are unavailable, continuing portfolio tracking requires another functioning data source. Its totals may differ if it covers different positions or values the same holdings differently. Checking the included positions and valuation dates is necessary before comparing those totals with a historical record.