Real‑Time NAV for Asset‑Backed Units: Why “Fair Price” Keeps Moving

October 12, 20267 min read

If a unit is backed by a real asset, the asset’s spot price is only the first layer. Fees, time, and settlement rules keep shifting the “fair” value, so the NAV we see can move—and the traded price can sit above or below it.

This is often the exact confusion in asset‑backed markets: why is NAV different from market price, and why does NAV itself keep changing?

Introduction

NAV (net asset value) is meant to describe what one unit is economically worth based on what backs it. In tokenized or digitally issued asset‑backed units (often discussed under RWA, or real‑world asset tokenization), NAV becomes even more important because it is the common reference point for issuance, redemption logic, and secondary trading.

In this article we build a simple, introductory model of dynamic (real‑time) NAV. The goal is not to turn valuation into a complicated formula, but to make the moving parts legible: underlying price, carry costs, transaction/settlement friction, and timing.

The problem

In day‑to‑day trading, we often expect one “correct” number. But for asset‑backed units, a single static NAV can be misleading.

Two things happen at the same time:

NAV changes as costs accrue and as the reference price changes.
Market price can differ from NAV because trading has its own constraints: liquidity, inventory, and execution risk.

So the right question is not “Which single number is true?” The better question is: What are the layers inside the NAV, and what minimum inputs must be disclosed so we can estimate a fair range?

Dynamic NAV in one sentence

A practical definition is:

Dynamic NAV ≈ underlying asset value ± accrued carry costs ± transaction and settlement frictions ± timing effects.

Even if an issuer publishes one headline NAV, in practice we can think in terms of a band (a buy‑side and sell‑side fair value) rather than one point estimate.

Component 1: Underlying asset price is the first layer

The obvious layer is the asset value per unit: for example, how much gold, commodity, or another real asset backs each unit.

But even here, differences appear quickly:

Which reference market is used (domestic vs international, wholesale vs retail)?
Is the price a last trade, a mid price, or an executable quote?
How often is it updated?

Tokenization infrastructure can make this layer more transparent by time‑stamping the source and publishing an update cadence. Stronger execution comes when the price feed (often called an “oracle” in blockchain systems) is clearly governed and auditable.

Component 2: Carry costs move NAV continuously

Carry costs are the “keeping it real” costs: custody, storage, insurance, audit, and operational controls.

These costs typically accrue over time. Even if we quote a daily number, the economic reality is continuous. That’s why NAV can drift during the day even if the underlying asset price is flat.

In well‑designed products, we can disclose:

what costs are included as carry,
how they accrue (daily, monthly, continuously),
and whether they are taken from the backing asset, charged separately, or reflected as a small drift in NAV.

Component 3: Payment and banking-rail fees are not “noise”

For small-ticket purchases, payment friction can be meaningful. When bank rails and electronic transfer fees are explicit, we can model them instead of ignoring them.

Media outlets have reported updates to Iran’s electronic banking service fee schedules for year 1405, highlighting that payment-rail fees are an enforceable cost layer rather than an abstract assumption.

We do not need exact fee amounts to learn the valuation lesson: if the unit is small, a fixed fee can be a large percentage. Dynamic NAV design becomes stronger when the issuer publishes which rails are supported and how fees are treated in the NAV or in the trade confirmation.

Component 4: Settlement delay creates a timing wedge

Settlement is the time gap between agreeing a trade and completing delivery/ownership transfer and cash finality.

When settlement is not instantaneous:

the underlying price can move,
the issuer/market maker takes execution risk,
and the buyer faces uncertainty about the final delivered cost.

This creates a rational wedge between NAV and market price.

Tokenization can help by making the settlement workflow more programmable and traceable. Its strongest results come when identity checks, custody controls, and reconciliation rules are designed alongside the on-chain record.

Component 5: Market structure explains part of NAV vs market price

Even with a perfect NAV model, the market price can diverge because:

liquidity is uneven,
inventory is limited,
trade sizes are small,
and participants demand compensation for immediacy.

So premiums/discounts can be rational, especially when the unit is hard to create/redeem quickly or when settlement is slow.

This is why better NAV disclosure improves understanding and comparability, but does not guarantee that the market price always hugs NAV.

A practical framework: a real-time NAV checklist (minimum inputs)

To make “real‑time NAV” usable, we need a small set of disclosed inputs. A best‑practice publication set can look like this:

Backing ratio: exactly how much underlying asset backs one unit, and how rounding is handled.
Price source and cadence: reference markets, observation method (last/mid/quote), and update frequency.
Carry-cost policy: which costs exist (custody/storage/insurance/audit), how they accrue, and how they are charged.
Transaction fee map: which payment rails and transfer/withdrawal methods are supported, and whether their fees are included in NAV or applied at trade time.
Settlement window: expected settlement time, cut-off times, and what happens if settlement is delayed.
Reconciliation method: how published NAV is reconciled to actual asset balances and cost deductions over time.

With these inputs, we can estimate a fair buy/sell range even if the market price is temporarily above or below the midpoint.

A simple example (hypothetical)

Assume a unit is backed by a small quantity of a real asset. At 10:00, the reference asset price implies a base value of 1,000,000 (hypothetical currency units) per unit.

Now layer in the moving parts:

Carry costs accrue through the day (small but continuous).
Buying the unit requires a payment rail that charges a fixed transfer fee.
Settlement completes at the end of the day, not instantly.

Even if the base asset price stays at 1,000,000 all day, the economically fair “all‑in” cost to acquire one unit at 10:00 can be slightly above that number. If the settlement delay adds execution risk, the market maker may price a small premium for immediacy and uncertainty.

On the sell side, if withdrawal/transfer friction applies, the fair executable sell value can be slightly below the headline NAV.

This is why in practice we observe a NAV band: a buy‑side fair value and a sell‑side fair value, with the market price moving inside or outside that band depending on liquidity.

Risks and limitations (implementation considerations)

Dynamic NAV modeling is helpful, but it cannot guarantee perfect pricing:

Liquidity constraints can dominate in thin markets.
Data quality matters: stale prices or unclear sources weaken the NAV.
Operational risk (custody controls, reconciliation errors) can create gaps between published NAV and realizable value.
Rule differences (cut‑offs, settlement steps, fee treatment) can make two “NAVs” incomparable unless disclosures are standardized.

The constructive path is to treat dynamic NAV as a published, auditable method rather than a single magic number.

Conclusion

NAV vs market price is not a sign that “something is wrong” by default. In asset‑backed units, fair value naturally moves because the underlying price updates, carry costs accrue, payment fees and trading frictions apply, and settlement introduces timing and execution risk.

When we decompose NAV into these layers, premiums and discounts become interpretable. The minimum disclosure set—price source and cadence, carry-cost policy, fee map, settlement window, and reconciliation method—turns NAV into a practical tool rather than a slogan.

FAQ

1) Is NAV supposed to be one precise number?
In practice, when fees and timing matter, NAV behaves more like a range. A single headline number can still be published, but a buy/sell band often reflects economic reality better.

2) Why can two issuers publish different NAVs for similar asset-backed units?
Because they may use different price sources, update frequencies, carry-cost assumptions, fee treatment, and settlement windows.

3) Does better NAV disclosure guarantee the market price will match NAV?
No. Better disclosure improves transparency and comparability, but market price is also driven by liquidity, inventory, and execution constraints.