Prerequisites
Before this page: create and initialize a Dynamic client (see Creating a Dynamic client, Initializing the Dynamic client), have a connected wallet to read from (see Connecting external wallets), and know which wallet you’ll show balances for (see Connected wallets management).
What you’ll build
Two views most apps need:
- Native balance — how much of the chain’s native asset (ETH, SOL, …) the wallet holds.
- Token list — every token the wallet holds, optionally with USD prices and market values, and with spam tokens filtered out.
Both read from a WalletAccount that your app supplies — the wallet it’s currently acting on.
Native balance
getNativeBalance returns { balance } where balance is a human-readable string (or null while it’s unavailable).
The query refetches automatically when the wallet’s network changes, so the balance stays in sync.
Token holdings
getTokenBalances returns one TokenBalance per token, with symbol, name, logoURI, decimals, a human-readable balance, and (when you opt in) price and marketValue. Pass includePrices for USD figures and filterSpamTokens to drop junk tokens.
balance is already scaled by the token’s decimals for display. When you need the exact integer amount (for a transfer, say), use rawBalanceString — it preserves full precision that a JavaScript number can lose.
Options worth knowing
For a portfolio across chains, pass networkIds (or use getMultichainTokenBalances) instead of calling per network — one request returns every network’s holdings.
Handling errors
See also
- Connected wallets management — pick which wallet to show balances for
- Transaction confirmation & simulation — spend the balance you display
- Network switching & validation — balances are per network