ERC-8330: Subject-Linked NAV Snapshot Oracle

We would like feedback on ERC-8330 — Subject-Linked NAV Snapshot Oracle, a draft ERC for publishing and querying provider-attributed Net Asset Value snapshots for application-defined subjects.

Update — July 09, 2026: ERC number has been allocated. The ERC remains in Draft status and may change based on review.

Formal ERC PR: ethereum/ERCs#1858
Spec file: ERCS/erc-8330.md


Periodic NAV for funds, private credit, real estate, infrastructure, commodities, and other illiquid or administratively priced assets differs from a continuous market-price feed. A consumer needs to know what the value represents, its denomination, when the valuation was measured, when it was published, who supplied it, which methodology was used, and whether either time is too old for the intended use.

Each stream is keyed by (subjectId, currency) and has one immutable configured NAV basis: per underlying unit, per share or token, or total subject value. Configuring the basis at stream level prevents providers from submitting incomparable interpretations into the same aggregation set.

The core interface provides:

  • signed NAV with explicit decimal precision;
  • provider and methodology attribution;
  • distinct valuation and publication timestamps;
  • one original provider submission per valuation timestamp;
  • linear correction chains;
  • administrative invalidation that preserves history;
  • stream-wide and provider-specific latest-value queries; and
  • independent publication-heartbeat and valuation-age status.

Invalidation is separate from correction because a compromised, revoked, or unavailable provider may be unable to correct a poisoned terminal snapshot. Invalidating a terminal correction restores its direct predecessor as current and allows a replacement correction, while retaining every historical record and invalidation event.

An optional aggregation interface selects the greatest valuation timestamp that currently satisfies quorum, normalizes provider values to common decimal precision, and returns the deterministic lower median. It also exposes eligible provider submissions and emits deviation alerts. Aggregation does not prove provider independence or valuation correctness.

Scope boundaries

ERC-8330 standardizes publication and query semantics. It does not:

  • calculate or independently verify NAV;
  • credential providers or validate methodologies;
  • establish asset ownership or backing;
  • guarantee liquidity or redemption rights;
  • make NAV an executable market price; or
  • ensure that a consuming contract checks staleness or aggregation results.

latestNAV deliberately exposes the raw latest current snapshot. Staleness-sensitive consumers should use latestNAVStatus, an aggregate, or a controlled adapter and evaluate both age signals.

Questions for review

  1. Is immutable stream-level NAV basis the right safeguard against incomparable provider submissions?

  2. Are provider-and-valuation uniqueness plus linear corrections sufficient for restatement history?

  3. Is administrative invalidation necessary for compromised-provider recovery, and are predecessor-restoration semantics understandable to consumers?

  4. Should publication age and valuation age remain separate mandatory signals?

  5. Is the lower median the appropriate deterministic aggregation rule, especially for even provider counts and signed values?

  6. Should aggregation remain an optional interface, or is it central enough to belong in the core?

  7. Does the term “oracle” communicate the interface accurately given the explicit distinction between reported NAV and executable price?

Implementation status

A Solidity reference implementation and test suite is available in the reference repository.

An example UI suite is also available for non-normative exploration of the interface and its role in the broader titled-asset standards family.

The audited reference commit is caa9b05. It includes unit tests, Medusa property tests, deterministic aggregation, and invalidation coverage. The implementation has also been reviewed in an independent Verichains audit.

ERC-8330 is independently deployable and does not require a particular token or vault standard. It was introduced alongside five other standalone draft ERCs in the architecture discussion, but those interfaces are not dependencies.

Authorship

Chris Turner, David Hay (LinkedIn), Reagan Simpson, and Collins Musyimi.

Developed at Kula, which builds infrastructure for regulated virtual-asset and titled-asset use cases. Reference implementations are open-source; we are proposing ecosystem interfaces, not a Kula-only stack. We are open to additional co-authorship and community contribution beyond Kula.

4 Likes

Quick update for reviewers: we have a non-normative UI suite and an ERC-specific architecture view.

These are intended to make the NAV snapshot model easier to inspect in context, including provider attribution, valuation and publication timestamps, staleness, correction chains, invalidation, and optional aggregation.

The UI is backed by the open-source reference implementation, but it is only an explanatory/demo layer; the ERC text remains normative.

Feedback on valuation-time semantics, provider attribution, staleness, correction and invalidation handling, and the optional aggregation extension would be very welcome.

Hello @redcoat,

Thanks a lot for this ERC, great job on that!

I would be interested to have some guideline on how this ERC could be used with an ERC-20 or an ERC-721, which are also sometimes used to represent financial assets (eventually).

Use case example:

If I have a money market fund represented by an ERC-20, how I can use this ERC (if it makes sense to use it) to represent the NAV in my ERC-20 ?

Also, maybe it could be worth to add the integration guideline for an ERC-4626 vault directly in the ERC ?

See titled-asset-standards/packages/erc-nav-oracle at main · KulaDao/titled-asset-standards · GitHub

Best!

2 Likes

@AccessDenied403 Thank you, happy to provide some high-level guidance. ERC-8330 is intentionally token-standard-neutral: it publishes and makes a NAV history queryable, but does not itself change an ERC-20 balance, an ERC-721 ownership record, or an ERC-4626 exchange rate.

For an ERC-20 money-market-fund token, a deployment would normally define the fund as the subjectId, select the currency and stream-level NAV basis (for example, NAV per share/token), and have its issuance, redemption, or settlement logic query a validated ERC-8330 result. The token’s ordinary transfer function does not need to depend on the NAV oracle unless the deployment deliberately makes it part of transfer or settlement policy.

For an ERC-721 representing a unique asset or position, the subjectId can identify that asset or position and the stream can report total-subject NAV. ERC-8330 does not imply that an NFT’s market price equals that reported NAV; it supplies a provider-attributed valuation record that an application may use.

ERC-4626 is a particularly useful integration case, but it needs care. ERC-8330 can be an input to a vault’s pricing or settlement process, while the vault remains responsible for its own asset-accounting, fees, liquidity, rounding, and conversion semantics. As the reference guidance notes, a vault should not directly make its conversion paths depend on an unconfigured or stale oracle call. An adapter or validated cached NAV is generally safer, with stale/unconfigured handling occurring in explicit subscription, redemption, or settlement flows.

1 Like