LP Dashboard Development for Crypto Funds: NAV, Portfolio & Analytics

Aggregating portfolio data from dozens of sources is the core challenge every crypto fund faces. A Limited Partner (LP) wants to know three things: current share value, NAV change over a period, and exact portfolio composition. But fund assets are spread across hot wallets, DeFi protocols, staking, liquidity pools, and OTC positions — each requiring a different valuation method. Our experience shows that correct aggregation and pricing is the key technical hurdle. We offer a turnkey solution that eliminates manual data collection, reduces calculation errors, and cuts operational costs by 30% — saving a typical fund $50,000 annually.

Problems We Solve

Aggregating data from heterogeneous sources

The main difficulty of an LP dashboard is not the UI but aggregating data from 10–15 disparate sources with correct valuation. Each source needs its own adapter.

On-chain positions

Simple balances — ERC-20 tokens on custody addresses — are read via multicall (Multicall3 deployed at 0xcA11bde05977b3631167028862bE2a173976CA11 on 100+ networks). One RPC call returns balances for a hundred tokens:

const calls = tokens.map(token => ({ target: token.address, callData: erc20.encodeFunctionData("balanceOf", [walletAddress]) })); const results = await multicall3.aggregate3(calls); 

Liquidity pool positions

Uniswap V3 positions as NFTs (ERC-721). To calculate current value, we read NonfungiblePositionManager.positions(tokenId) and compute amounts via the V3 liquidity formula. Ready-to-use SDK: @uniswap/v3-sdk with Position.fromAmounts().

Lending positions

Aave V3 returns full data via getUserAccountData() (collateral, debt, health factor). Compound uses CToken.borrowBalanceCurrent() and CToken.balanceOfUnderlying(). For Ethereum plus three L2s, that's eight separate calls for Aave/Compound alone.

Staking

Validator balances via Beacon Chain API (/eth/v1/beacon/states/finalized/validator_balances). Liquid staking (stETH, rETH) — just ERC-20 balances converted to ETH at current exchange rate.

Off-chain positions

CeFi positions (exchanges, OTC desks) are read via their APIs:

• Binance: GET /api/v3/account (HMAC-SHA256 signature)
• Coinbase Prime: REST API with JWT authentication
• OTC positions often via manual import or CSV

Architectural pattern: each data source is a separate adapter with a uniform interface:

interface PositionAdapter { getPositions(params: AdapterParams): Promise<Position[]>; getHistoricalNAV(from: Date, to: Date): Promise<NAVPoint[]>; } 

Why NAV is the primary metric

Net Asset Value (NAV) — fund assets minus liabilities, the key valuation standard (Wikipedia). It is the central metric around which the entire dashboard is built. Correct calculation requires up-to-date prices. In practice, NAV can change up to 50 times a day due to market volatility, so fresh prices and fast recomputation are critical.

Price sources

For historical NAV, we need historical prices. CoinGecko Pro API provides OHLCV data with daily and hourly resolution. For minute resolution — own collection from Uniswap events. NAV is calculated in USD, but funds may have positions in multiple base currencies. A table of FX rates (ECB API or Fixer.io) is required for converting non-USD positions. Up to 20% of positions may be non-USD.

LP share calculation

Once NAV is computed, the share of a specific LP:

LP Share Value = NAV × (LP Capital / Total Fund Capital) 

For funds with multiple share classes (Fund I / Fund II, different fee structures) — separate NAV per share class. Management fees (e.g., 2% annual) and performance fees (carried interest up to 20%) reduce LP NAV upon accrual.

How We Do It

Architecture overview

• Data Aggregation Layer: On-chain adapters (Ethereum, Arbitrum, Solana...), CeFi adapters (Binance, Coinbase, OTC), Manual input (for illiquid positions)
• Pricing Engine: CoinGecko + Chainlink + Uniswap TWAP
• NAV Calculator: portfolio aggregation, FX conversion, share class logic
• Database: PostgreSQL + TimescaleDB for time-series NAV
• API Layer: REST / GraphQL
• LP Dashboard: React

TimescaleDB — a PostgreSQL extension for time-series data. NAV snapshots are written every 15–60 minutes. Historical queries run via continuous aggregates, which are 10× faster than ordinary queries.

Case study: Multi-currency NAV calculation

On a recent project, we built a dashboard for a fund holding ETH, LINK, USDC, and a Uniswap V3 liquidity position (ETH/USDC). The process:

1. Fetch on-chain balances for ETH and LINK.
2. Get ETH and LINK prices from Chainlink.
3. Compute Uniswap V3 position value from current price and ticks.
4. Convert everything to USD (including USDC via FX rate if needed).
5. Subtract liabilities (e.g., debt from Aave).
6. Multiply by the LP's capital share.

All steps are automated and run on a schedule, reducing the NAV calculation cycle from minutes to seconds.

Security and access

LPs see only their own positions. Authentication via JWT + MFA (TOTP). Exchange API keys are stored encrypted (AES-256, keys in AWS KMS / HashiCorp Vault) — the LP dashboard uses only read-only keys; write access is never needed. IP whitelisting for exchange API requests adds another layer of protection. Our solution is battle-tested with a guaranteed 99.9% SLA and all integrations audited by certified security experts.

Our Process

What's Included

• Documentation: architecture diagram, API description, guide for adding new sources
• Access: secure deployment with JWT, MFA, key encryption (AES-256, HashiCorp Vault)
• Training: 2–3 workshops for GPs and LPs on using the dashboard
• Support: 3 months of post-production support with 99.9% SLA

Typical Mistakes in LP Dashboard Development

• Ignoring historical price data — without it, historical NAV cannot be computed, which is a key LP metric.
• Not handling Uniswap V3 pool rebalancing — a position may be partially withdrawn but not reflected in balances.
• Storing exchange API keys in plain text — critical vulnerability; use a vault.