Skip to main content

​
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.

​
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 (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.
FunctionSettles depositsSettles redemptionsWhen to use
settleDeposit(newTotalAssets)YesYes (best-effort)Recommended — handles both queues in one call
settleRedeem(newTotalAssets)NoYes (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:
StepSelf-managedWith valuation service
NAV proposal (updateNewTotalAssets())Asset Manager proposesValuation service pushes automatically
Settlement (settleDeposit() / settleRedeem())Asset Manager settlesAsset Manager settles (unchanged)
FrequencyBoth tied to Asset Manager’s scheduleNAV 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

Vault 7540 mechanics

How the vault handles deposits, redemptions, settlement, fees, and access control at the contract level.

Policy engine

How the Policy Engine enforces on-chain permissions, spending limits, and guardian governance.

Operate an Advanced Strategy

Day-to-day operations — execute transactions through the policy engine.

Advanced Strategies

High-level overview of the Advanced Strategy architecture.