> ## Documentation Index > Fetch the complete documentation index at: https://docs.renesis.fi/llms.txt > Use this file to discover all available pages before exploring further. # Methodology > Exactly how NAV, returns, and fees are computed in every LP report # Overview This page documents the math behind every cell on an LP report. If you're an LP reconciling a statement against your own books, or a manager debugging why a fee number looks off, this is the source of truth. All formulas here match the renderer code one-to-one. The Renesis LP Report Studio (the engine behind the PDF) is the canonical implementation, if a future computation disagrees with what the report shows, the report wins. *** # NAV Two NAV concepts appear on a report. They are **not** interchangeable. | Concept | What it represents | Sign | | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- | | **NAV (raw)** | The actual market value of the portfolio: `Σ balance_i × price_i` across every asset. This is what your wallet / exchange tells you you're worth right now. | Always ≥ 0 | | **Gross NAV** | NAV neutralized for capital flows: `nav_raw − total_deposits + total_withdrawals`. Used as the performance numerator, since deposits aren't profit. | Can be negative | The strategy mini-card's **Net Asset Value** tile shows **NAV (raw)**, the real account value. The **Period PnL** tile shows the change in **Gross NAV** over the period, the part of the move that came from market performance, not flows. **FX conversion to reporting currency**: NAV is computed natively first (BTC for a BTC strategy, USD for a USDC strategy), then converted to the reporting currency using the end-of-period exchange rate. For fiat pairs we use ECB month-end reference rates; for crypto pairs we use on-chain spot at the snapshot block. *** # Returns All return percentages on the report are **time-weighted**, flows in / out don't distort them. For a single period `[t0, t1]`: ``` return = NAV_native(t1) / NAV_native(t0) − 1 ``` We use the **native NAV** path (BTC for a BTC strategy) rather than the reporting-currency NAV. This isolates strategy yield from BTC↔EUR FX noise: a BTC strategy that earned exactly 1% in BTC reports +1% ITD even if BTC moved relative to EUR during the period. ### Time horizons | Acronym | Meaning | Start anchor | | ---------- | ------------------------- | ---------------------------------------------------------------- | | **MTD** | Month-to-date | First day of the report's end month | | **QTD** | Quarter-to-date | First day of the report's end quarter | | **YTD** | Year-to-date | January 1 of the report's end year | | **ITD** | Inception-to-date | The strategy's inception (or first day of data, see clamp below) | | **Period** | Selected reporting period | Report's `period_start` | ### Annualized return ``` annualized = (1 + ITD)^(365 / days_held) − 1 ``` `days_held` is the number of calendar days between the strategy's effective start (see clamp) and the period end. For periods shorter than 30 days the annualized figure is shown but should be read with appropriate skepticism, small windows magnify noise. ### Inception clamp (data-start override) A strategy's contractual inception (from the editor) might predate the first day we actually have NAV data, e.g. the manager signed the LP agreement Feb 2025 but the on-chain wallet was only registered on Renesis in October. In that case the renderer uses the **later of** (contract inception, data start) so the ITD math has data to measure. The strategy card's subtitle ("since 2025-10-22") reflects the clamped date, not the contractual inception. The percentage is honest, it's measured over the window we actually have data for. If you need contractual inception to surface alongside the data-start window, ask your Renesis contact. *** # Risk metrics Computed from the daily native-NAV series over the **period window**. | Metric | Formula | | --------------------------- | ---------------------------------------------------------------------------------- | | **Volatility (annualized)** | `stdev(daily_returns) × √365` | | **Sharpe** | `(mean(daily_returns) × 365) / (stdev × √365)`, risk-free rate set to 0 by default | | **Sortino** | Same as Sharpe but `stdev` uses only negative daily returns | | **Max drawdown** | `min((NAV_t − peak_NAV_t) / peak_NAV_t)` over the period | | **Downside deviation** | `stdev` of negative daily returns only, annualized | Daily granularity is the reconcile cadence. Strategies that hold positions reconciling less often (e.g. some illiquid vaults) inherit the cadence of their slowest leg. *** # Fees The fee table on page 3 is the part LPs scrutinize most. Here's the exact math. ### Per-month decomposition For each month `M` that falls inside the reporting period: ``` days(M, period) = number of calendar days of M that fall inside [period_start, period_end] (a full month: 28-31; a partial month: only the in-period days) AUM_native(M) = end-of-month native NAV (default: current EOM basis) PnL_native(M) = native NAV change over month M, excluding flows mgmt_native(M) = AUM_native(M) × mgmt_pct / 100 × days(M, period) / 365 perf_native(M) = max(0, PnL_native(M) − mgmt_native(M)) × perf_pct / 100 total_native(M) = mgmt_native(M) + perf_native(M) ``` Then for each month we convert to reporting currency using the **month-end** FX: ``` mgmt_rep(M) = mgmt_native(M) × FX_native→reporting(eom of M) perf_rep(M) = perf_native(M) × FX_native→reporting(eom of M) total_rep(M) = total_native(M) × FX_native→reporting(eom of M) ``` Per-month FX (not period-end FX) is used so that a fee earned in March is converted at March-end rates, preserving the value the manager actually charged in that month even if the FX moved later in the period. ### Period totals ``` period_mgmt_native = Σ mgmt_native(M) over all months in the period period_perf_native = Σ perf_native(M) period_total_native = period_mgmt_native + period_perf_native ``` Same for the reporting-currency column. The grand total at the bottom of the fee table is the sum of `period_total_native` (or `_rep`) across every strategy. ### Reconciling the performance fee The performance fee is computed **after** the management fee on the same monthly bucket. The intuition: > *"I charge 15% on what's left after I pay myself the management fee."* So if `PnL_native(M) = 100`, `mgmt_native(M) = 12`, `perf_pct = 15`: ``` perf_native(M) = max(0, 100 − 12) × 0.15 = 88 × 0.15 = 13.20 ``` A common LP error: computing perf = `100 × 0.15 = 15` ignores the mgmt deduction. The report's number will be **lower** than the naive calc. Also note the `max(0, …)`, performance fee is **never negative**. A losing month accrues no performance fee, but the management fee still applies (the manager still gets paid for managing the AUM, regardless of performance). ### AUM basis, current vs prior EOM The `AUM_native(M)` term above uses the **current EOM** convention by default, fee for month K is computed on the AUM at end of month K. Many institutional mandates use **prior EOM** instead: fee for month K is computed on the AUM at end of month K−1 (the AUM the manager already had under management when the month started). Set this in the Report Workspace under **Reporting → AUM Basis**. The two conventions produce different monthly fee numbers, the difference can be material in fast-growing months. Check what your management agreement specifies. ### High-water mark and hurdle rate The 4-page LP report does **not** apply HWM or hurdle rate to performance fees today. If your fee schedule includes a hurdle (e.g. *15% over SOFR + 200 bps*), the displayed performance fee is computed on full positive PnL, you may need to manually deduct the hurdle in a [manual adjustment](#manual-adjustments) until HWM support ships. HWM **is** supported in **LP Portal V1** (the multi-LP share-accounting feature, separate from the 4-pager). If you need per-investor HWM tracking with capital events, that's the path. ### Per-month visual / period total reconciliation The fee table shows up to 3 month columns. For periods longer than 3 months, the **first 3 months** are displayed; the period total column still sums across all months in the period. So a 5-month report's column total = sum of months 1-5, while the visible cells only show months 1-3. Sub-unit native fees (e.g. 0.0134 BTC on a small ellenBTC mandate) can render as `0.01` at 2dp precision and stop adding visually to the period total. Bump **Crypto Fee Precision** in the Report Workspace to 4 to see the full magnitude. Even smaller values (below the precision threshold) render in subscript notation (`0.0₂459 BTC` means `0.00459`) so the LP can read the real number. *** # Holdings table The top-10 holdings table on page 3 lists positions sorted by reporting-currency value, descending. | Column | Definition | | ---------------- | ---------------------------------------------------------------------------------------------- | | **Holding** | Asset symbol as reported by the underlying ledger | | **Strategy** | Which configured strategy the holding rolls into. Holdings with no matching strategy show ", " | | **Allocation %** | `value_reporting / total_AUM_reporting × 100` | | **PnL** | Asset-level realized + unrealized PnL since the strategy's effective start | The donut chart on page 1 uses the **strategy** roll-up, not individual holdings, so if your ellenUSDC strategy holds 5 different vaults under the symbol `ellenUSDC`, they're aggregated as one wedge. *** # Manual adjustments The Adjustments section in the Report Workspace lets you apply per-period overrides that don't touch the underlying ledger. Typical uses: * **Portfolio NAV adjustment**, bump or trim total AUM (e.g. to include an off-chain holding the ledger doesn't track). * **Per-strategy NAV adjustment**, same, scoped to one strategy. * **Per-strategy fee delta**, add or subtract a specific fee amount (e.g. apply a hurdle deduction manually). * **Portfolio fee delta**, same, scoped to total fees; distributes proportionally across strategies. Adjustments are presentation-only. They appear in a disclosure footer on the report ("Adjustments applied: …") so the LP can see the manager's intervention. *** # Currency conventions * **Native currency**: the strategy's denomination (BTC, ETH, USDC, USD, EUR, …). Drives the strategy card's "≈" cross-reference line. * **Reporting currency**: the single currency every chart, NAV card, and fee total is expressed in. Set per report. * **FX**: ECB month-end rates for fiat pairs, on-chain spot at the snapshot block for crypto. The recon job pulls these once per day; the report uses the values cached at the period end. Display precision: * **Fiat headline** cells (NAV, Period PnL, fund total AUM, grand-total fee): 2dp by default; toggle **Round Fiat Decimals** in the Report Workspace to drop cents. * **Per-month fee cells**: 2dp for fiat strategies (keeps row arithmetic exact); per-report configurable for crypto strategies (2 / 4 / 6 dp). * **Sub-precision crypto cells**: subscript notation (`0.0₂459`) for values that would round to "0.00" at the chosen precision. *** # Common reconciliation questions ### "Your AUM is different from my vault dashboard" The LP report aggregates **every wallet attached to the report's portfolio** under the symbol roll-up. If two wallets both hold Onyx USDC under the symbol `ellenUSDC`, they sum into one strategy NAV. Your vault dashboard shows just one wallet. To reconcile, list the wallets in your Renesis portfolio and confirm the AUM is the sum across all of them. ### "Your performance fee is lower than I expected" The performance fee is computed on PnL **after** the management fee is deducted (same month). If you computed `perf = PnL × perf_pct` directly, you'll be high, see [Reconciling the performance fee](#reconciling-the-performance-fee). ### "Your NAV chart starts later than my inception date" The inception date on the strategy card is clamped to the first day we have NAV data. The percentage is honest for that window, it's just shorter than your contractual mandate length. Backfilling earlier data requires reconciling history with the wallet's earlier transactions; talk to your Renesis contact if you need this. ### "Your AUM basis disagrees with my management agreement" Set **Reporting → AUM Basis** to `Prior EOM` if your agreement specifies that management fees are charged on the AUM you walked into the month with. The default `Current EOM` charges on what you ended the month with. *** Step-by-step walk through the Report Workspace, from creating a report to rendering the PDF.