How Does the Token Know What the Asset Is Worth? NAV, Oracles, and Reporting in On-Chain RWA

Bifu Research · 2026-07-16 · 13 min read


Table of contents

Every RWA token points at an asset that lives off-chain, so its value has to be reported onto the chain by someone. This article explains who computes NAV and how often, how values reach the token layer through manual updates, oracles, and attestations, what proof-of-reserves reports do and do.

A token that represents a real-world asset has a problem no crypto-native token has: the thing it points at lives off-chain. A tokenized fund share, a tokenized bond, a tokenized treasury position — none of these can be valued by looking at the blockchain. The loans, shares, or securities sit in custody accounts and legal registers somewhere else. So the value you see next to the token is not discovered by the chain. It is computed off-chain by people, and then reported onto the chain through some channel.

That reporting pipeline — who computes the number, how often, how it gets on-chain, and who checks it — is one of the most important and least examined parts of any RWA product. This article walks through it end to end: how net asset value (NAV) is produced, the three main ways values reach the token layer, what proof-of-reserves and attestation reports actually verify, the gap between a displayed price and a price you can transact at, and the failure modes to watch for.

Why On-Chain RWA Has an Off-Chain Data Problem

Start with the basic asymmetry. For a crypto-native asset, the chain is the source of truth: balances, transfers, and (on liquid venues) prices are all observable. For an RWA token, the chain only records who holds the token. Everything that determines what the token is worth — the underlying loans, the fund's portfolio, the bond issuer's ability to pay — exists in the off-chain world of custodians, fund administrators, and legal contracts.

This means every RWA token depends on a data bridge. Someone off-chain must periodically answer the question "what is this worth?" and push that answer to wherever holders see it: the token's smart contract, the platform's product page, or both. The blockchain can guarantee that the reported number has not been tampered with after it was published. It cannot guarantee the number was right in the first place. In the industry this is called the oracle problem: a chain can verify signatures, not facts about the outside world.

If the underlying is a non-listed asset — private credit, pre-IPO equity, a private fund — the problem is compounded, because there is no market price to report in the first place. The value itself is an estimate produced by a valuation process, which we cover in how non-listed assets get priced without a ticker. Here we focus on the next step: once a value exists, how it travels to the token.

Who Computes NAV, and How Often

For fund-type products, the standard value measure is net asset value (NAV): the value of everything the fund holds, minus its liabilities, divided by the number of shares or units. NAV is not computed by the blockchain and, in a well-governed structure, not solely by the manager either.

The key roles:

  • The investment manager runs the portfolio and usually proposes valuations for hard-to-value holdings, since it knows them best. This creates an obvious conflict: the manager's fees and track record often depend on the marks.
  • The fund administrator is an independent service firm that maintains the fund's books, calculates the official NAV, and processes subscriptions and redemptions at that NAV. Independent administration is the standard control against a manager marking its own homework.
  • The auditor examines the fund's financial statements — typically once a year — and opines on whether they fairly present the fund's position, including whether the valuation methodology was reasonably applied.
  • The custodian holds the actual assets and can confirm they exist and are titled correctly, though it does not opine on what they are worth.

These are the same parties that appear throughout an RWA structure; for the full map, see who the parties are in an RWA product.

Frequency matters as much as authorship. A tokenized money market fund may strike NAV every business day because its holdings have observable prices. A private credit fund may strike NAV monthly. A pre-IPO or private equity vehicle may only revalue quarterly, and even then large parts of the portfolio may be held at the price of the last funding round until a new event forces a re-mark. Whatever the token layer displays between official NAV dates is, at best, the last computed number carried forward — not a live price.

Hypothetical example (for illustration only). A tokenized private credit fund strikes NAV on the last business day of each month. The administrator computes NAV per share of $10.42 on March 31 and the number is published to the token contract on April 3 after review. For the next month, every interface shows $10.42. If several borrowers in the portfolio missed payments in mid-April, the displayed value would not reflect that until the April NAV is struck and published in early May. Nothing malfunctioned — this is simply what a monthly cadence means.

How the Value Reaches the Token Layer

Once a value exists off-chain, there are three common channels for getting it on-chain or in front of token holders. They differ in automation, latency, and — most importantly — in what can go wrong.

Channel How It Works Typical Use Key Limitation / Risk
Manual or permissioned update The issuer or administrator signs a transaction that writes the new NAV into the token contract, or updates the product page Funds with periodic NAV (monthly, quarterly) Fully trust-based; stale between updates; a wrong or delayed push goes uncorrected until the next cycle
Oracle feed An oracle network (a service that relays off-chain data to smart contracts) pulls the value from the administrator or a data source and posts it on-chain, often with multiple independent nodes Tokenized treasuries and funds with daily NAV; assets with reference market prices The oracle relays data, it does not create truth — if the source is wrong or stale, the feed is wrong or stale with extra confidence attached
Attestation / report An accounting firm or agent periodically publishes a signed report confirming holdings or NAV as of a date; sometimes anchored on-chain as a hash Proof-of-reserves for asset-backed tokens; periodic investor reporting Point-in-time snapshot only; says nothing about the period between reports or about value going forward

Two things are worth underlining. First, an oracle is a messenger, not a valuer. Even a decentralized oracle network with many nodes is decentralized about delivery, not about origination: if all nodes read the same administrator file, the feed is exactly as reliable as that file. Second, these channels are usually layered. A serious tokenized fund might use an administrator-computed NAV, delivered by oracle, checked annually by an auditor, with quarterly attestations in between. Each layer covers a different failure, and no combination covers all of them.

What Proof-of-Reserves and Attestations Verify — and What They Do Not

"Proof of reserves" and "attestation report" appear in many RWA and stablecoin disclosures, and they are routinely over-read. It helps to be precise about the engagement type. An attestation is typically an agreed-upon-procedures or examination engagement: an accounting firm performs specified checks — for example, confirming with a custodian that certain assets were held in a named account on a given date — and reports what it found. That is narrower than a full financial statement audit, which covers an entire reporting period, tests internal controls, and results in an opinion on the statements as a whole. For the fuller breakdown of how audits, attestations, and proof-of-assets differ, see that dedicated article.

What a typical reserve attestation establishes:

  • The stated assets existed in the stated accounts on the snapshot date.
  • The quantity of assets matched (or did not match) the stated liabilities or token supply on that date.

What it does not establish:

  • Value going forward. A snapshot of holdings is not a guarantee of what those holdings will be worth tomorrow, or of any return. Whether a product delivers a return depends on the source of that return (interest, coupons, asset appreciation), the term you hold it for, whether you can exit when you want to, and the risks in the underlying — none of which an attestation addresses.
  • Legal claim. Confirming that assets sit in an account does not by itself prove that token holders have an enforceable claim on those assets in an insolvency. That depends on the legal structure — the SPV, trust, or fund wrapper and its documents — not on the accounting snapshot. See what an SPV is and the structure behind RWA products.
  • Encumbrances and the in-between. A point-in-time check may not reveal whether assets were borrowed for the snapshot date, pledged elsewhere, or moved the day after.

None of this makes attestations useless. A product that publishes regular attestations from a named, reputable firm is disclosing more than one that publishes nothing. The point is to read them as what they are — periodic existence checks — rather than as a substitute for an audit, a valuation opinion, or a legal guarantee.

Displayed Price vs. Executable Price

Even a correct, current NAV answers only one question: what is the estimated per-unit value of the underlying? It does not answer the question most holders actually care about: what can I transact at, and when?

The displayed number and the executable number can diverge for structural reasons:

  • Redemption mechanics. Fund-type products usually redeem at NAV, but only at set intervals (say, monthly), often with notice periods, and sometimes with gates that limit how much can be redeemed at once. The NAV on your screen today may be executable only at next month's NAV, whatever that turns out to be.
  • Secondary market spread. If the token trades on a secondary venue, the market price can sit below or above NAV depending on demand, and thin liquidity means large orders move the price. A displayed NAV of $10.42 coexisting with a best bid of $9.80 is not a data error — it is the market pricing in illiquidity, uncertainty about the marks, or urgency of sellers.
  • Stale marks. For infrequently valued assets, the displayed value lags reality by design, so the executable price on any venue that does trade continuously will lead or trail it.

A practical habit: whenever you see a value on an RWA product, ask "is this a reporting number or a transacting number?" NAV, oracle feeds, and attestations are reporting numbers. Redemption terms and live order books are transacting numbers. Judging a product requires both, which is the same reason a return figure should never be read without its term, exit mechanics, and risk factors alongside it.

Failure Modes, and What the Documents Tell You

The reporting pipeline can fail in three distinct ways, and they call for different responses:

  1. Stale data. The most common failure. NAV is computed on schedule but the world moved in between, or an update was delayed. The displayed value is honest about the past and silent about the present. Long gaps between updates are not automatically a defect — they reflect the underlying's valuation rhythm — but they mean the number carries a timestamp you should always check.
  2. Wrong data. A valuation error, a bad source file, a compromised update key, or an oracle relaying a corrupted input. Independent administration, multi-source oracle designs, and periodic audits exist to catch this, but each check runs on its own clock, so an error can persist between checks.
  3. Honest data about a deteriorating asset. The pipeline works perfectly and faithfully reports a falling value. No amount of oracle engineering or attestation frequency protects against the underlying itself losing value. Reporting quality and asset quality are separate questions; good reporting makes losses visible, not smaller.

Because you usually cannot inspect the pipeline directly, product documents are your main evidence. Look for:

  • Named parties. Is there an independent administrator, and is it named? Is the auditor named, and is it an established firm? Unnamed or issuer-affiliated parties concentrate trust in one place.
  • Stated cadence. How often is NAV struck, and how often is it published to the token layer? Is there a stated attestation schedule?
  • Methodology. Does the document say how hard-to-value holdings are marked, and who signs off?
  • The gap disclosures. Do the documents explain the difference between reported NAV and redemption terms — notice periods, gates, settlement times?

A document that answers these plainly tells you the issuer has thought about the data problem. A document that displays a value with no source, no cadence, and no named parties tells you something too.

This checklist is also how Bifu suggests reading any tokenized product, including those listed on its own platform. The Bifu RWA page presents each product's information alongside its formal documents and risk disclosures, so you can check who computes the value, how often it updates, and what the exit terms are before deciding whether a product is worth your further evaluation. The token can only know what someone reports to it — your job as a reader is to find out who that someone is.

FAQ

What's the difference between an audit and an attestation for an RWA product?

An audit examines an entity's full financial statements over a reporting period and results in an opinion on whether they fairly present its position. An attestation is narrower: it is typically an agreed-upon-procedures or examination engagement where an accounting firm checks a specific claim, such as confirming that certain assets were held in a named account on a given date. Attestations tend to happen more often, but they only cover what was specifically checked.

Is a daily oracle price more reliable than a monthly NAV update?

Not automatically. Frequency reflects how often the underlying asset can reasonably be revalued, not how trustworthy the number is, and an oracle is a messenger rather than a valuer. A daily feed built on a stale or incorrect source file is only as reliable as that source, no matter how often it updates.

Who is responsible if an RWA token's reported NAV turns out to be wrong?

It depends on where the error entered the pipeline. The investment manager proposes valuations and carries the most direct conflict of interest, the fund administrator is meant to act as an independent check by computing the official NAV, and the auditor reviews the methodology, typically once a year — but each of these checks runs on its own schedule, so an error can persist until the next one catches it.

Can I always redeem an RWA token at its most recently reported NAV?

Not necessarily. Redemption normally happens at NAV, but only on scheduled dates, often with notice periods and sometimes gates that limit how much can be redeemed at once, so the NAV displayed today may not be the NAV actually received at redemption.

See how Bifu presents RWA product information

Every RWA token points at an asset that lives off-chain, so its value has to be reported onto the chain by someone. This article explains who computes NAV and how often, how values reach the token layer through manual updates, oracles, and attestations, what proof-of-reserves reports do and do.

Explore RWA on Bifu

Disclaimer

This content is for educational purposes only and does not constitute financial, investment, legal, tax or trading advice. Digital assets, RWA products, gold-related products and forex products involve risk, including possible loss of principal. Always review product rules and risk disclosures before trading.