Operations & Audit
Non-Destructive NAV Adjustments: Correcting Without Rewriting History
Syncrone Team
Protocol mispricings, oracle failures, and accounting policy changes all require NAV corrections. Here is why the correction mechanism matters as much as the correction itself.
Why Adjustments Are Inevitable
No automated NAV engine is perfect. Protocols have bugs that temporarily report incorrect exchange rates. Oracle prices lag or spike during high volatility. A new protocol integration may compute yield correctly but classify it under the wrong category for a fund’s accounting policy.
An institutional fund needs a mechanism to correct these errors — without permanently altering the underlying computed data. The ability to say “the raw computation produced X, we applied adjustment Y for reason Z, and the reported NAV is X+Y” is the gold standard for auditability. It is the same model used in traditional fund administration, where the administrator’s adjustments are tracked separately from the prime broker’s source data.
Types of Adjustments
NAV Corrections: Direct adjustments to the fund’s total NAV on a specific date. Used when an automated value is materially wrong (e.g., a protocol bug temporarily inflated a position’s exchange rate by 10x). The correction records: the original computed value, the correction amount, the reason, the operator who applied it, and the timestamp.
NAV Policy Overrides: Standing rules that apply a consistent treatment across periods. For example, a fund’s accounting policy may require recognizing yield only when it exceeds a minimum threshold, or may exclude a specific token from NAV by policy.
Yield Attribution Corrections: Adjustments that reclassify yield between categories — for example, reclassifying an incentive reward that was auto-categorized as “staking yield” but should be “protocol incentive” for the fund’s reporting.
Coverage Controls: Operator decisions to promote or demote how a specific protocol position is tracked. Promoting a position to full coverage means the engine will compute full PnL history from inception.
The Base Projection vs Adjusted Projection
A non-destructive adjustment system maintains two projections in parallel.
The base projection is the raw computed output of the engine: block data, exchange rates, prices, and balances assembled with no overrides. This is the ground truth that can always be recomputed from public on-chain data. It never changes retroactively.
The adjusted projection is what LPs and auditors receive: the base projection with all approved adjustments applied. It reflects the fund’s accounting policy, any approved corrections, and any coverage decisions.
If a correction is later found to have been incorrect, it is reversed — producing a new adjusted projection — but the base projection remains unchanged. The audit trail shows exactly what was corrected, by whom, and when.
Audit Trail Requirements
For every adjustment, the audit trail must record: the operator who created it, the operator who approved it (if a four-eyes policy is in place), the date the adjustment was created, the date range over which it applies, the type of adjustment, and the reason.
With this record, an auditor reviewing the fund’s NAV can independently verify: starting from the base projection, applying adjustments A, B, and C, the reported NAV is correct. Without this level of traceability, adjustments are a black box that undermines the integrity of the entire NAV.
See exactly where your vault's yield comes from