Crypto Fund Infrastructure: Smart Contracts, NAV, Key Management

Developing a crypto fund infrastructure extends far beyond a simple multisig and trading account. Every day we face the need to organize a transparent and auditable process: real-time NAV calculation, LP asset isolation, automatic redemption execution. For example, a recent project: a fund with $50M AUM required integrating 15 different price sources. Without a proper NAV oracle and circuit breaker, price manipulation could have led to a $2M loss in a single transaction. We implemented a TWAP aggregator and flash loan protection, reducing risk to zero. Our team, with 7+ years of Web3 experience, solves these problems so investors can sleep soundly. Over 7 years we have implemented 50+ projects for funds with AUM from $10M to $500M. We guarantee transparency and security at all levels — from fund smart contracts to off-chain services. Fund management cost reduction reaches 30% through automation of NAV calculator and performance fee calculation. Transaction fee savings — up to 40% thanks to gas optimization and L2 selection. Contact us to discuss your task.

How is the Vault Contract Structured for LP Share Accounting?

A typical crypto fund consists of several technical layers: On-chain layer (smart contracts):

• Vault contract — asset storage, LP share accounting
• NAV oracle — provides current asset value
• Subscription/Redemption contract — manages LP entry/exit
• Fee module — calculates management and performance fees

Off-chain layer:

• NAV calculator — price aggregation, portfolio value calculation
• Trade execution engine — executes orders via CEX/DEX
• Reporting pipeline — reports for LPs and regulators
• Risk monitoring — position monitoring, drawdown, exposure

Operational layer:

• Multi-sig for management — Gnosis Safe with signer policies
• Key management — hardware security modules (HSM) or MPC wallets
• Audit trail — immutable log of all operations

Standard EIP-4626 is the starting point for most on-chain funds. It defines the deposit/withdraw/mint/redeem interface with ERC-20 shares:

// Simplified vault structure contract FundVault is ERC4626, AccessControl { bytes32 public constant MANAGER_ROLE = keccak256("MANAGER_ROLE"); bytes32 public constant NAV_ORACLE_ROLE = keccak256("NAV_ORACLE_ROLE"); uint256 private _reportedNavPerShare; // NAV per share, updated by oracle uint256 public lastNavUpdate; uint256 public constant NAV_STALENESS_THRESHOLD = 24 hours; // Override totalAssets() to account for off-chain assets function totalAssets() public view override returns (uint256) { require( block.timestamp - lastNavUpdate <= NAV_STALENESS_THRESHOLD, "NAV is stale" ); return _reportedNavPerShare * totalSupply() / 1e18; } // NAV oracle updates portfolio value function updateNAV(uint256 newNavPerShare) external onlyRole(NAV_ORACLE_ROLE) { require(newNavPerShare > 0, "Invalid NAV"); _reportedNavPerShare = newNavPerShare; lastNavUpdate = block.timestamp; emit NAVUpdated(newNavPerShare, block.timestamp); } } 

The key complexity: totalAssets() in EIP-4626 assumes assets are inside the contract. For a fund with positions on CEX, DeFi protocols, BTC — assets are distributed. The NAV oracle must aggregate all sources and feed a single value on-chain.

Subscription and Redemption: Liquidity Management

Simple deposit/withdraw from EIP-4626 does not work for a fund with periodic liquidity windows. The real scheme:

Subscription queue. LP submits subscribeRequest(amount) + transfers USDC. The request is queued. At the end of the period (e.g., weekly), the manager processes the queue: calculates shares at the current NAV, mints them to the LP.

Redemption queue. Similarly: redeemRequest(shares), share lockup, payout at period end. A lock-up period (usually 30-90 days) is implemented via timestamp check.

struct RedemptionRequest { address lp; uint256 shares; uint256 requestedAt; bool processed; } mapping(uint256 => RedemptionRequest) public redemptionQueue; uint256 public redemptionQueueHead; uint256 public redemptionQueueTail; function requestRedemption(uint256 shares) external { require(shares > 0 && balanceOf(msg.sender) >= shares); // Lock-up: cannot redeem before lockupPeriod expires require( block.timestamp >= subscriptionTimestamp[msg.sender] + lockupPeriod, "Lock-up period active" ); _transfer(msg.sender, address(this), shares); // lock shares redemptionQueue[redemptionQueueTail++] = RedemptionRequest({ lp: msg.sender, shares: shares, requestedAt: block.timestamp, processed: false }); } 

How to Ensure NAV Accuracy?

The NAV calculator is the most complex off-chain component. NAV must accurately reflect the value of all fund assets at the time of calculation. We use data aggregation from multiple sources with protection against manipulation.

Data sources for NAV:

NAV manipulation is a serious threat. If NAV depends on a single price source, a flash loan attack on a DEX pool can temporarily distort the price and give the attacker arbitrage via subscription/redemption. Protection: TWAP instead of spot, aggregation of several sources, circuit breaker on sharp NAV changes. According to Chainlink documentation, using TWAP reduces manipulation risk by 90%.

class NAVCalculator: async def calculate_nav(self) -> Decimal: positions = await self.fetch_all_positions() nav = Decimal('0') for position in positions: price = await self.get_robust_price(position.asset) nav += position.quantity * price # Verification: NAV change must not exceed threshold prev_nav = await self.get_last_nav() change_pct = abs(nav - prev_nav) / prev_nav * 100 if change_pct > self.MAX_NAV_CHANGE_PCT: await self.trigger_circuit_breaker(nav, prev_nav, change_pct) raise NAVCircuitBreakerError(f"NAV change {change_pct:.1f}% exceeds threshold") return nav async def get_robust_price(self, asset: str) -> Decimal: prices = await asyncio.gather( self.chainlink.get_price(asset), self.pyth.get_price(asset), self.cex_api.get_mid_price(asset), ) # Median from three sources — more robust than average valid = [p for p in prices if p is not None] return sorted(valid)[len(valid) // 2] 

Why Should Performance Fee Be Calculated Using High Water Mark?

Performance fee (usually 20% of profit) is calculated via high water mark — the fee is charged only on profit above the previous NAV peak. This protects LPs from double charging after a drawdown and recovery. Without HWM, the manager could charge a fee on volatility even without generating net profit.

uint256 public highWaterMark; // NAV per share at previous peak function settlePerformanceFee(uint256 currentNavPerShare) external onlyRole(MANAGER_ROLE) { if (currentNavPerShare <= highWaterMark) return; // No profit above HWM uint256 profit = currentNavPerShare - highWaterMark; uint256 feePerShare = profit * performanceFeeRate / 10000; // Convert to shares and mint to manager uint256 feeShares = feePerShare * totalSupply() / currentNavPerShare; _mint(feeRecipient, feeShares); highWaterMark = currentNavPerShare; emit PerformanceFeeSettled(feePerShare, feeShares); } 

Key Management and Security

Gnosis Safe is the standard for multi-sig fund management. Threshold policies: 3-of-5 for large operations (withdrawal > $1M), 2-of-3 for daily operations.

MPC wallets (Fireblocks, Copper, Liminal) — an alternative to multi-sig for institutional funds. The key is never assembled entirely, protecting against compromise of a single participant. MPC wallets process transactions 3 times faster than multi-sig due to not needing to collect all signatures on-chain. More importantly: MPC allows integrating approval workflows — each transaction passes a compliance check before signing.

HSM (Hardware Security Module) — for maximum security of hot wallets in the trading engine. AWS CloudHSM or physical HSM (Thales, Utimaco).

Isolation principles:

• Cold storage (multisig on air-gapped devices) — long-term assets, >70% of AUM
• Warm storage (MPC/HSM) — working capital for trading
• Hot wallet — minimum for gas fees and small operations

Reporting and Auditability

LPs expect: monthly NAV statements, trade logs, fee calculations. Regulators in some jurisdictions require independent NAV valuation and annual audit.

All critical operations are written to an immutable event log:

• Every NAV change with data sources and calculation
• Every trade with execution price, fee, counterparty
• Every subscription/redemption with NAV at processing time

Storage: PostgreSQL for operational access + Arweave/IPFS for immutable archive + on-chain hashes of key reports for verification.

What is Included in the Work: Documentation, Access, Training, Support

When ordering crypto fund infrastructure development, you receive:

• Full technical documentation: architecture, smart contract interfaces, off-chain service APIs.
• Access to source code in a private repository with a usage license.
• Team training: 2-3 sessions on working with the vault contract, NAV calculator, and multisig wallet.
• Support during deployment and the first 3 months of operation (included in the cost).
• Smart contract audit by an external team (Ledger, ConsenSys Diligence, or similar).

How to Implement the Infrastructure in 7-10 Weeks?

The development process consists of five phases:

1. Design (1 week): identify asset types, subscription/redemption windows, fee structure, regulatory reporting requirements, threat model.
2. Smart contracts (2-3 weeks): Vault, NAV oracle, fee module. Testing on Foundry (fuzz tests, invariant tests). Formal verification of key invariants.
3. Off-chain infrastructure (2-3 weeks): NAV calculator, trade execution engine, reporting pipeline.
4. Integration and testing (1 week): End-to-end tests on testnet, stress testing NAV oracle.
5. Audit and deployment (1 week): External smart contract audit, gradual rollout with limits.

Minimum viable version (vault + NAV + multi-sig without automation) — 3-4 weeks.

Technology Stack

Contact us to design your infrastructure — our engineers will prepare a solution tailored to your needs. Get a consultation on implementing a fund of any complexity.