Documentation Index
Fetch the complete documentation index at: https://docs.moralis.com/llms.txt
Use this file to discover all available pages before exploring further.
Who it’s for
Teams building portfolio apps, wallets, and dashboards — anything that shows what a wallet holds right now and what it’s worth. The goal is a current-holdings view you own: every token balance, native-asset balance, and NFT, each marked in USD, refreshed live at the chain head.The recipe bundle
This use case combines three balance recipes — one per asset class — with Token Prices for valuation. Each balance recipe is keyed by wallet, so “everything wallet Y holds” is a single prefix scan.| Recipe | Role in the portfolio |
|---|---|
| Token Balances by Wallet | Every ERC-20 / SPL token a wallet holds, with its current balance — the core fungible-holdings table, keyed by wallet. |
| Native Balances | The wallet’s native-asset (gas-token) balance — ETH, BNB, SOL, etc. — tracked separately from tokens. |
| NFTs by Wallet | Every NFT a wallet holds — collection address, token ID, and ERC-721 / ERC-1155 type. |
| Token Prices | The valuation join target — the latest USD/native mark per token used to value fungible holdings. |
Balances are tracked as post-balance observations: each recipe records the holder’s balance after every transfer it was part of, so the latest observation per
(wallet, asset) is the current balance. No periodic re-scan of the chain is needed.How the pieces fit
- The three balance recipes each unpivot every transfer into per-wallet
(from, post-balance)and(to, post-balance)observations. The latest observation per(wallet, asset)—argMaxover(block_number, log_index)— is the live holding. Token and NFT balances are keyed by(chain_id, wallet_address, token_address[, token_id]); native balances droptoken_addressand tiebreak onnative_seq(native transfers carry nolog_index). - Token Prices is the connective tissue: join each fungible balance to its token’s latest mark to value the holding. The recipe ships a carry-forward
latest_token_price_dict, so even quiet tokens keep their last on-chain mark — a singledictGetper token.
Valuing a wallet’s fungible holdings
Read the current non-zero token balances for a wallet, then value each against the latest USD mark from the Token Prices sync:current_balance by 10^token_decimals before multiplying by usd_price to get a fully-scaled dollar value; source decimals from a Token Metadata sync. The native balance follows the same pattern against the Native Balances fact (tiebreak on native_seq), valued against a native-price feed.
Notes and considerations
- Read canonical state. All three balance facts and Token Prices use the collapsing log-table pattern. Read with
FINAL(thenargMax) or a sign-aware aggregate — never a bareWHERE sign = 1, or unmerged reorg counter-rows will skew balances. - Decimals. Balances are raw integer strings. Scale by
10^token_decimalsbefore displaying or valuing — pull decimals from a Token Metadata sync. - Chains. Token Balances and Token Prices are chain-parametrized (EVM + Solana); set the chain env vars per sync. NFTs by Wallet is EVM (ERC-721 / ERC-1155).
- Native vs token. The native asset is not an ERC-20 and is tracked by its own recipe — don’t expect it in the token-balances table. Value it against a native-price mark, not the token-price dictionary.
- Pair with other recipes. Add Wallet History for the chronological feed behind a holding, and Token Approvals to surface outstanding allowances in a wallet’s security view.
- Run mode. Run the ClickHouse path in
hybridmode so balances backfill history and then stay current, reorg-safe, at the chain head.
Get started
Data Feeds is in early access.Request Early Access
Build a live, valued portfolio view on your own infrastructure with the Moralis team.

