Crypto fund management system development

Crypto Fund Management System Development

Managing a crypto fund is not just "holding tokens on a wallet". It's an operating system that must simultaneously track positions in dozens of protocols, calculate NAV in real-time, manage keys so no single person can withdraw assets unilaterally, generate regulatory reporting, and prevent mistakes where the cost is loss of investor funds. Existing TradFi solutions don't work here: they don't understand on-chain assets, DeFi positions, staking rewards, LP tokens.

Architecture: key subsystems

Wallet and key management

This is the foundation everything else is built on, and there's no room for compromise.

MPC (Multi-Party Computation) — modern standard for institutional custody. Unlike blockchain-level multisig, MPC wallet looks like a regular EOA, but the private key never exists in full on any single device. Key shares are distributed among participants (e.g., 2-of-3: fund + custodian + backup HSM). Transaction signing requires joint computation.

Solutions: Fireblocks (enterprise, $10k+/mo), Lit Protocol (on-chain MPC, more flexible), tss-lib (Go library for custom GG18/GG20 threshold signature scheme implementation).

Gnosis Safe as multisig — proven solution for on-chain multisig. Scheme for fund:

Investment Committee (3/5 multisig) 
  → Timelock contract (24–48h delay for large operations)
    → Protocol interactions

Operations (2/3 multisig)
  → Routine rebalancing (amount limit per tx)
  → Gas topup for wallets

Role separation is critical: INVESTMENT_ROLE for strategic decisions (protocol deposits, large swaps), OPERATIONS_ROLE for routine (harvest rewards, compound). Each role — separate Safe or separate signer sets.

HSM (Hardware Security Module) — for automated operations (harvest, rebalance) where signature is needed without human. Key in HSM (AWS CloudHSM, Nitro Enclaves, Thales), operations executed automatically but within strictly limited smart contract rules.

Position aggregation and valuation

Crypto fund can have assets in dozens of forms: spot tokens on wallets, LP positions in Uniswap v3 (these are NFTs with price ranges), staked positions (stETH, rETH, cbETH), lending/borrowing in Aave or Compound (aTokens, debtTokens), vault shares (ERC-4626), locked tokens (vesting, veTokens), perpetual positions on GMX or dYdX.

Each type requires separate logic to calculate current value:

Uniswap v3 LP position:

// Simplified — real calculation via TickMath and FullMath
(uint160 sqrtPriceX96,,,,,,) = pool.slot0();
(uint128 liquidity,,,,) = nfpm.positions(tokenId);
(amount0, amount1) = LiquidityAmounts.getAmountsForLiquidity(
    sqrtPriceX96, sqrtLowerX96, sqrtUpperX96, liquidity
);
// + accumulated fees

ERC-4626 vault:

uint256 shares = vault.balanceOf(fundAddress);
uint256 underlyingValue = vault.convertToAssets(shares);

For each protocol you need an adapter. Standardized adapter interface:

interface ProtocolAdapter {
  protocol: string; // "aave-v3", "uniswap-v3", "gmx-v2"
  getPositions(address: string): Promise<Position[]>;
}

interface Position {
  protocol: string;
  type: "lending" | "lp" | "staking" | "vault" | "perp";
  tokens: { address: string; amount: bigint; usdValue: number }[];
  totalUsdValue: number;
  apy?: number;
  healthFactor?: number; // for lending positions
}

NAV calculation

Net Asset Value = sum of all assets − obligations (borrowed funds in lending protocols, outstanding fees).

Problem: prices. NAV needs honest market prices, resistant to manipulation.

• Chainlink Price Feeds — for major assets. Aggregated, resistant to flash loan attacks, but latency ~1–5 min and not all tokens covered.
• Uniswap v3 TWAP — for tokens without Chainlink. IUniswapV3Pool.observe([1800, 0]) gives TWAP for 30 min. Manipulation requires huge capital.
• CoinGecko/CoinMarketCap API — for off-chain NAV reporting. Can't use on-chain (oracle risk), but ok for dashboard and reporting.

NAV is recalculated on schedule (every 5–15 min for internal monitoring, daily for official investor reports) and on each significant operation.

Risk management

Health factor monitoring — for lending protocol positions. Aave: HF < 1.0 → liquidation. Alert when HF < 1.3, automatic partial debt repayment when HF < 1.15 (if allowed by operational policy).

Concentration limits — not more than X% of fund in one protocol, not more than Y% in one token. Checked at each rebalancing.

Liquidation price tracking — for each collateralized position calculate and display liquidation price. Integration with price alerts.

Smart contract risk scoring — protocol TVL, contract age, audit presence, hack history. Integrate data from DeFiLlama (TVL), DefiSafety (audit scores), Rekt.news API (hack history).

Trading execution

Manual operations via multisig — slow for rebalancing. Automation via:

1inch / Paraswap as aggregator — best execution price through routing across all DEXs. API for getting quote + transaction data:

const quote = await fetch(
  `https://api.1inch.dev/swap/v6.0/1/swap?` +
  `src=${tokenIn}&dst=${tokenOut}&amount=${amount}&from=${fundAddress}&slippage=0.5`
).then(r => r.json());

// Transaction via Safe SDK
const safeTx = await safe.createTransaction({
  to: quote.tx.to,
  data: quote.tx.data,
  value: quote.tx.value,
});

TWAP execution — for large positions to avoid moving the market. Split into N equal parts, execute at intervals. Cowswap / UniswapX for MEV protection.

Accounting and reporting

Cost basis tracking

For tax reporting you need to track cost basis for each position. Methods: FIFO, LIFO, HIFO, Specific Identification. Each swap, reward receipt, liquidity addition — is a taxable event in most jurisdictions.

Special complexity: LP fees and staking rewards — usually income when received (harvest), not capital gain. System needs to distinguish these event types.

Investor reports

• Daily NAV + change vs. benchmarks (BTC, ETH, DeFi Pulse Index)
• Monthly P&L per protocol and strategy
• Capital calls and distributions
• Auditor-ready trial balance with full on-chain proof chain

Security and operational procedures

Transaction simulation before each execution — Tenderly or forked mainnet. No transaction is sent without prior simulation and expected result verification.

Allowance management — approve only for specific transaction or use increaseAllowance with minimal amounts. Regular review of existing approvals via Revoke.cash API.

Emergency procedures — documented runbook: how to act on key compromise, liquidation risk, hack discovered in used protocol. Safe Guard contracts for automatic pause on anomalies.

Implementation stack

MVP development timeline (custody + positions + NAV + basic dashboard): 4–6 months. Full system with trading execution, reporting and compliance: 9–14 months.