Crypto Portfolio Tracker Development

Aggregating cryptocurrency portfolio balances is one of the most challenging tasks in Web3 development. A user may hold assets across a dozen networks (Ethereum, Polygon, Arbitrum, Solana), in hundreds of tokens, in DeFi protocols like Uniswap V3 with unique position math, and on centralized exchanges. Each source requires its own approach to data retrieval. If you don't design the architecture from the start, the system will lag, exhaust RPC limits, and produce incorrect PnL. We have gained experience on 30+ such projects and know how to avoid the pitfalls. Multicall3 is one of the key tools that allows aggregating data from EVM networks with minimal overhead.

Key Architectural Decisions

How to Aggregate Balances from Different Networks?

On-chain Balances

EVM networks: native balance via eth_getBalance, ERC-20 balances are more complex — one RPC call returns the balance of one token at one address. With 50 tokens × 5 networks = 250 calls. The solution is Multicall3 (deployed on all EVM networks at address 0xcA11bde05977b3631167028862bE2a173976CA11). One RPC call instead of 50 — that's 50 times faster and reduces infrastructure costs by up to 90%. Multicall3 is a battle-tested contract used in thousands of projects. Multicall3 documentation recommends batch requests to reduce load.

import { createPublicClient, http, parseAbi } from "viem"; import { mainnet } from "viem/chains"; const client = createPublicClient({ chain: mainnet, transport: http() }); const MULTICALL3 = "0xcA11bde05977b3631167028862bE2a173976CA11"; const ERC20_ABI = parseAbi(["function balanceOf(address) view returns (uint256)"]); async function getTokenBalances( walletAddress: `0x${string}`, tokenAddresses: `0x${string}`[] ) { const calls = tokenAddresses.map((tokenAddress) => ({ address: tokenAddress, abi: ERC20_ABI, functionName: "balanceOf" as const, args: [walletAddress], })); return client.multicall({ contracts: calls }); } 

Alternative: Alchemy/Moralis Token API — one request returns all ERC-20 balances with metadata and USD price. Paid, but saves development time. For Solana we use getMultipleAccounts or Anchor for account reading.

DeFi Positions

This is the most complex part of the tracker. A liquidity position in Uniswap V3, collateral in Aave, staked tokens in Curve — each protocol stores data differently. Compare approaches:

For most projects, we recommend a combination: direct calls for major protocols + aggregators for long-tail. For example, for Uniswap V3 we use positions and tick contracts, and for Curve we use get_balances. A PnL calculation error can occur due to price and block desynchronization — we solve this by binding snapshots to block numbers.

CEX Balances

Exchange APIs return balances instantly but require a read-only API key from the user. We use CCXT — a library with a unified interface for 100+ exchanges.

import ccxt from "ccxt"; async function getBinanceBalances(apiKey: string, secret: string) { const exchange = new ccxt.binance({ apiKey, secret, sandbox: false }); const balance = await exchange.fetchBalance(); return balance.total; // { BTC: 0.5, ETH: 2.3, USDT: 1000 } } 

CCXT is a popular open-source library supporting 100+ exchanges.

Why Data Update Strategy Matters

Data needs updating, but don't hammer the RPC every second. Strategy:

Background jobs via Redis + BullMQ with separate queues. Results cached in Redis, frontend reads from cache. For real-time, use Server-Sent Events or WebSocket with push updates.

Storing Historical Data

For P&L tracking, you need portfolio snapshots over time. TimescaleDB (PostgreSQL extension) is ideal:

CREATE TABLE portfolio_snapshots ( user_id UUID, snapshot_at TIMESTAMPTZ NOT NULL, total_usd NUMERIC(20, 2), breakdown JSONB ); SELECT create_hypertable('portfolio_snapshots', 'snapshot_at'); 

Query P&L over a period:

SELECT time_bucket('1 day', snapshot_at) AS day, last(total_usd, snapshot_at) AS end_of_day_value FROM portfolio_snapshots WHERE user_id = $1 AND snapshot_at > NOW() - INTERVAL '30 days' GROUP BY day ORDER BY day; 

How to Set Up Multicall3 in Your Project

1. Install viem: npm install viem.
2. Import createPublicClient and network configuration.
3. Call client.multicall with an array of contracts and functions.
4. Process the result — it returns an array of objects with result and error fields.

This standard approach, described in OpenZeppelin documentation, recommends using Multicall3 for batch requests to reduce RPC load.

What's Included in the Work

We deliver a full set of documentation, commented source code, deployment instructions, access to a Git repository, and one month of support after launch. If needed, we train your team on how to use the system.

Timeline Estimates

An MVP portfolio tracker can be ready in as little as 2 weeks. Full-featured solutions with multiple networks, DeFi integrations, and historical P&L typically take 4–8 weeks depending on complexity. The exact timeline is determined after an initial technical audit.

Typical Mistakes to Avoid

• Using individual RPC calls for each token instead of batching with Multicall3.
• Ignoring block-level timestamps when calculating PnL, causing price mismatches.
• Not caching API responses appropriately, leading to rate limit issues.
• Forgetting to handle edge cases like zero balance tokens or failed contract calls.

We have encountered all these pitfalls in our projects and know how to build robust systems from the start.

Discuss your requirements with our engineers — we'll assess the project in one day and propose the optimal solution. Order a turnkey portfolio tracker with quality guarantee and on-time delivery. Contact us to get started.