How root64 calculates NAV: daily batches, forward pricing, and ECL provisioning

How often does root64 calculate NAV, and what is the basic method?

root64 calculates net asset value (NAV) once per day, in a single batch run at a fixed daily cut-off. NAV is the value of everything the pool owns, minus what it owes, divided by the number of units outstanding — the per-unit number an investor would use to value a position.

This article is about the method, not the result. It contains no live NAV, no yield, and no performance figures, and it is not meant to. Where a number appears, it is an illustrative placeholder to show the arithmetic. What follows is how the calculation is structured, why it runs the way it does, and how each input is written down so that someone outside root64 can recompute it.

The pool in question is root64’s first Korean loan pool. root64 is the real-world-asset (RWA) platform built by 8percent, an FSC-licensed online investment-linked finance company (P2P lender) in Korea. A Korean special-purpose company holds the loan assets; for how that holding structure works, see how root64 holds Korean loan assets. This post picks up at the next question: given those assets, how is the pool’s per-unit value computed each day?

What goes into the NAV calculation?

NAV is built from a small, fixed set of inputs: a few asset lines added together, a couple of deduction lines subtracted, and a unit count to divide by. root64 separates the pool’s assets into four distinct lines rather than collapsing them into one “total assets” figure, because each line has a different source and a different way of being verified.

The four asset lines are:

Asset line	What it represents
Loan principal outstanding	The principal balance of the loans the pool holds, net of any write-downs
Accrued interest	Interest that has been earned over time but not yet collected
Cash balance	Cash sitting in the special-purpose company’s bank accounts
Operator-advance claim	The pool’s claim on funds advanced to the originator’s deposit account, carried at face value

Source: root64 pool accounting model, as of June 2026. Line labels are descriptive.

From the sum of those four, two deduction lines are subtracted — an expected-credit-loss allowance (covered below) and other liabilities such as accrued fees and operating costs. The result is the pool’s net value. Dividing by the total number of units outstanding gives NAV per unit.

Two design choices in that list are worth pausing on. First, the four asset lines are kept separate so that a movement of money within the pool — say, cash being advanced and turning into a loan — changes which line holds the value but leaves total assets unchanged. NAV only actually moves on a few events: money entering or leaving the pool, interest accruing with the passage of time, and loss provisions or write-downs being adjusted. Everything else is value changing form, not changing amount. Second, every one of these inputs is recorded on-chain at each calculation, which is what makes the whole figure independently checkable. More on that at the end.

What is forward pricing, and why does root64 use it?

Forward pricing means a deposit or withdrawal is settled at the next NAV that gets computed — not at a NAV that was already known when the order arrived. An investor putting money in today does not get yesterday’s published per-unit price; they get the per-unit price struck at the next daily batch, after that day’s assets have been measured.

The reason is to remove a specific, well-understood unfairness. If units were issued at the last known NAV, someone who could see during the day that the pool’s assets had moved could time a deposit or withdrawal to convert at a stale, advantageous price — diluting everyone else. By deferring the conversion to a NAV that has not yet been computed when the order is placed, forward pricing makes that timing game impossible: you commit before you can know the price.

This is not a root64 invention. It is the same principle behind the U.S. Securities and Exchange Commission’s forward-pricing rule for mutual funds, Rule 22c-1, which requires funds to transact at “the current net asset value… next computed after receipt” of a purchase or redemption order (SEC — Amendments to Rules Governing Pricing of Mutual Fund Shares, accessed June 2026). root64 applies the same logic to an on-chain pool.

Concretely, the two halves of a deposit are handled at different times:

1. The cash is recorded immediately. When money actually moves, the cash transaction is written to the on-chain ledger right away, at the real time of the transfer. The pool’s cash balance reflects it at once.
2. The unit conversion waits for the next batch. The number of units that cash buys is not struck on the spot. It is calculated at the next daily NAV batch, using that batch’s per-unit value.

Between those two moments, the position is shown as “pending” — the cash is in, but the unit count is not yet final. For an investor this means up to roughly a day before units are confirmed, which is an accepted trade-off for an institution-facing product and consistent with how this asset class operates in practice. (At the very first batch, when no units exist yet, root64 strikes units at par value — a per-unit value of 1.0 — matching the standard fund convention of launching at NAV = 1.)

How does expected credit loss get into NAV?

Expected credit loss (ECL) is a forward-looking estimate of likely future losses on the loans in the pool, and root64 subtracts it from gross assets before computing per-unit value. The point is to reflect, in NAV, an allowance for losses that have not yet occurred but are reasonably expected — rather than waiting for a loan to actually default before recognizing any hit.

This mirrors the accounting standard the rest of the financial world has moved to. Under IFRS 9, impairment is measured with a forward-looking expected-credit-loss model in which, in the standard-setter’s framing, “it is no longer necessary for a credit event to have occurred before credit losses are recognised” (PKF Littlejohn — IFRS 9 expected credit losses: an overview, accessed June 2026). IFRS 9 structures this as a three-stage model that escalates the provision as a loan’s credit quality deteriorates. root64’s ECL line is the same idea applied to its pool: a provision that anticipates loss, not one that only books it after the fact.

Mechanically, the ECL figure is produced off-chain, by a credit model, and then committed on-chain as one of the NAV inputs. Two things follow from that:

• It is a deduction, so it lowers NAV. Provisioning reduces reported per-unit value relative to a no-provision figure. That is the intended direction — it is more conservative to carry an allowance than to mark assets as if every loan will be repaid in full.
• The method itself has to be auditable, because the number is a model output. A figure that comes from a model is only as trustworthy as the documented methodology behind it. So each NAV snapshot also records a version tag for the ECL methodology in use. If the model’s method or parameters change, the version is bumped, which lets anyone reproduce a past NAV under exactly the methodology that applied at the time — rather than silently re-scoring history with a newer model.

One honest limitation worth stating: in its current phase, root64 commits ECL as a single combined allowance across the pool rather than breaking it out asset-by-asset. The credit model computes finer-grained components beneath that, but the on-chain figure is the pool-level total for now. A per-asset breakdown is a later-stage refinement, not something the current calculation exposes.

How can an outsider check the NAV calculation?

By recomputing it. Every input to the daily NAV — the four asset lines, the loss allowance, the other-liabilities line, the unit count, and the resulting per-unit value — is written to an on-chain record at each batch. Because the formula is fixed and public (sum the asset lines, subtract the deductions, divide by units), anyone reading those inputs can run the same arithmetic and confirm that the published per-unit figure was produced correctly from them.

That is a deliberately narrow and honest claim. Recomputability proves the math was done right given the inputs. It does not, on its own, prove the inputs are true — that the cash balance really sits in the bank, that the loans really exist, that interest really accrued. Those are separate questions, and they are the job of root64’s verification layer, which checks asset and cash data against independent external channels and logs the result — including mismatches — on-chain. The NAV record tells you the calculation is internally consistent; the verification records tell you whether the numbers feeding it have been checked against the outside world. For how to read both kinds of record field by field, see how to read root64’s on-chain proofs.

This division is the whole reason root64 publishes the inputs and not just the answer. A platform that posts only a single NAV number is asking to be trusted; a platform that posts every input and the formula is asking to be checked. That sequencing — make the assets verifiable first, then build on top — is the principle behind transparency before tokenization.

A few properties of the on-chain NAV record make the recompute practical rather than theoretical:

• The inputs and the output travel together. Each daily record carries the full input set alongside the per-unit value it produced, so a checker never has to reconstruct what numbers went in.
• A capital-erosion case is signaled explicitly. If deductions ever exceed assets, the per-unit value is floored at zero and a distinct on-chain signal is emitted, so an observer can tell “no units issued yet” apart from “the pool’s value has been impaired” — two situations that would otherwise both look like a zero.
• The history is append-only. NAV records are added but never edited or deleted, so a past day’s calculation cannot be quietly restated; a correction goes forward as a new entry, leaving the original visible.

What this method does — and does not — promise

The method above is designed to do three things: value the pool conservatively (forward-looking loss provisioning, par-value launch), price fairly across investors (forward pricing, no stale-price timing), and make the result independently checkable (every input on-chain, a fixed public formula, append-only history).

What it does not do is change the nature of the asset. The underlying instruments are loans, and loans carry credit risk; a careful NAV methodology makes the state of the pool legible and conservative, but it does not remove risk or guarantee any outcome. NAV can fall as well as rise, and an allowance for expected loss is an estimate, not a floor. Nothing in this calculation is a promise of return, and past or modeled figures are not indicative of future results.

That is the point of describing the method in public rather than advertising a number. A figure invites you to trust it. A method invites you to check it — and root64’s NAV is built, line by line, to be checked.