> ## Documentation Index
> Fetch the complete documentation index at: https://docs.railnet.org/llms.txt
> Use this file to discover all available pages before exploring further.
# Accounting — NAV proposals and settlement
> Operational guide for running NAV update cycles — propose, settle, and verify
## Overview
A NAV update cycle is the process that keeps the vault's share pricing current and settles pending deposits and redemptions. Each cycle has two steps:
1. **Propose** — The Valuation Manager proposes a new `totalAssets` value on-chain
2. **Settle** — The Strategy finalizes the NAV and processes pending request queues
This page is the operational guide for running these cycles. For the underlying mechanics of how NAV updates and settlement work at the contract level, see [Vault 7540 mechanics](/strategies/advanced/vault).
## NAV update step-by-step
### Step 1 — Check NAV validity
Call `isTotalAssetsValid()` on the vault:
* **`true`** — NAV is still valid. Sync deposits and sync redemptions are enabled. The Valuation Manager **cannot** propose a new NAV until the current one expires.
* **`false`** — NAV has expired. The Valuation Manager can propose a new NAV.
### Step 2 — Force expiration (if needed)
If you need to run a NAV cycle immediately but the NAV is still valid, the Strategy can call `expireTotalAssets()` to force expiration. This immediately disables sync operations and enables the Valuation Manager to propose.
### Step 3 — Prepare liquidity
Before settling, ensure the Strategy wallet holds enough liquid assets to cover pending redemptions.
The NAV will be confirmed and deposits will be settled even if the Strategy lacks liquidity for redemptions. Redemption settlement simply won't execute — it does not revert the transaction.
### Step 4 — Propose NAV
The Valuation Manager calls `updateNewTotalAssets(newTotalAssets)` with the new total assets value.
This function:
* Snapshots all pending requests and creates an epoch boundary
* Validates the proposed NAV against [guardrails](/strategies/advanced/vault#nav-guardrails) (if active)
* Stages the value for the Strategy to confirm
This call reverts if the NAV is still valid (`ValuationUpdateNotAllowed`) or if guardrails are active and the price-per-share change exceeds the configured bounds (`GuardrailsViolation`). If guardrails block a legitimate update during an extreme market event, the Security Council can call `securityCouncilUpdateTotalAssets()` to bypass them.
**Operational requirement:** Your tooling must persist the exact `newTotalAssets` value used here — the Strategy must pass the identical value in the settlement call.
### Step 5 — Finalize NAV and settle
The Strategy calls one of two settlement functions, passing the **exact same** `newTotalAssets` value that was proposed in Step 4.
| Function | Settles deposits | Settles redemptions | When to use |
| ------------------------------- | ---------------- | ------------------- | ------------------------------------------------- |
| `settleDeposit(newTotalAssets)` | Yes | Yes (best-effort) | **Recommended** — handles both queues in one call |
| `settleRedeem(newTotalAssets)` | No | Yes (best-effort) | Only when you want to skip deposit settlement |
What happens during settlement:
1. NAV is finalized to the proposed value
2. Management and performance fees are taken (shares minted to fee receivers)
3. Current entry and exit fee rates are recorded for the epoch
4. Deposit queue is settled (if using `settleDeposit`) — assets move from the Silo to the Strategy
5. Redemption queue is attempted — assets move from the Strategy to the vault for claiming (only if the Strategy has enough liquidity)
You cannot call settlement twice in the same cycle. Once the NAV is finalized, the staged value is cleared. If redemption settlement fails due to insufficient liquidity, you must wait for the next NAV cycle — you cannot retry without re-running the full propose-and-settle flow (which also re-runs fee logic).
### Step 6 — Post-settlement verification
After settlement, verify:
* `totalAssets()` equals the NAV you finalized
* `isTotalAssetsValid()` returns `true` (sync window is now open)
* If sync redeem is enabled, check that the Strategy still holds sufficient idle liquidity for potential sync redemptions during the lifespan window
## Sync redemption liquidity
When sync redeem is enabled, each settlement opens a sync window (the `totalAssetsLifespan` period) during which shareholders can instantly redeem directly from the Strategy wallet — without waiting for the next settlement.
This creates an additional liquidity planning requirement on top of async redemptions:
* **Async redemptions** require liquidity at the **next settlement** — the Strategy has time to unwind positions if needed
* **Sync redemptions** require liquidity **immediately and continuously** during the entire sync window — there is no grace period
### Emergency levers
If the Strategy's idle balance runs low during the sync window:
1. **`expireTotalAssets()`** — immediately closes the sync window and forces all new redemptions to async. This also enables a new NAV cycle.
2. **`setSyncMode(SyncDeposit)` or `setSyncMode(None)`** — disables sync redeems while optionally keeping sync deposits open. Unlike `expireTotalAssets()`, this does not expire the NAV.
3. **Do nothing** — let the lifespan expire naturally.
## Using a third-party valuation service
Instead of having the Asset Manager handle both the NAV proposal and the settlement, the valuation proposal can be delegated to a third-party NAV computation service that calculates the vault's net asset value and pushes it on-chain automatically.
This decouples the two steps of the NAV cycle:
| Step | Self-managed | With valuation service |
| ----------------------------------------------------- | ------------------------------------- | ----------------------------------------------------------------------------------- |
| **NAV proposal** (`updateNewTotalAssets()`) | Asset Manager proposes | Valuation service pushes automatically |
| **Settlement** (`settleDeposit()` / `settleRedeem()`) | Asset Manager settles | Asset Manager settles (unchanged) |
| **Frequency** | Both tied to Asset Manager's schedule | NAV updates can be daily (automated), settlements at the Asset Manager's discretion |
### Key benefits
* **Fresh NAV for sync operations** — automated daily NAV updates keep the sync window refreshed, ensuring sync deposits and redeems use a current valuation
* **Settlement can batch** — the Asset Manager can let multiple NAV updates pass before settling, processing all pending requests at the latest NAV
* **Separation of concerns** — valuation and settlement are handled by different parties, reducing single-point-of-failure risk
Each `updateNewTotalAssets()` call overwrites the previous staged value. Only the most recent staged NAV can be used for settlement. There is no timeout — the staged NAV remains until a settlement call consumes it.
### Setup
1. **Update the valuation manager** — The vault owner calls `updateValuationManager(serviceWalletAddress)` to set the service's wallet as the valuation manager
2. **No access control needed** — The `updateNewTotalAssets()` function is gated by the `onlyValuationManager` modifier, not by allowlist/blocklist checks. The service wallet does not need to be whitelisted
## What to read next
How the vault handles deposits, redemptions, settlement, fees, and access control at the contract level.
How the Policy Engine enforces on-chain permissions, spending limits, and guardian governance.
Day-to-day operations — execute transactions through the policy engine.
High-level overview of the Advanced Strategy architecture.