ERC: uFund - Standardized Fund Metadata & Lifecycle Interface

ERCs
, ,
1

Summary

uFund is a proposed ERC interface for tokenized investment funds.

It defines a minimal, read-heavy, base-token-agnostic interface for querying fund-level information such as:

  • Net Asset Value (NAV) per share
  • NAV freshness/staleness
  • fund lifecycle state
  • declared and paid distributions
  • basic fee metadata
  • subscription and redemption windows
  • maturity date

It also defines optional extensions for:

  • AUM reporting
  • lockup reporting
  • accrued yield
  • multi-class share structures
  • proof-of-reserves attestations

The goal is to reduce custom integration work for DeFi protocols, wallets, indexers, custodians, and RWA platforms that need to interact with tokenized funds.

Motivation

Tokenized funds and RWA products are becoming a meaningful on-chain asset class, but integration remains fragmented.

Today, each issuer exposes fund data differently:

  • NAV may be derived from ERC-4626-style vault math
  • NAV may be pushed by an oracle
  • NAV may be pushed by an administrator
  • distributions may be represented through custom events or off-chain records
  • lifecycle state may not be standardized at all
  • proof-of-reserves data may be issuer-specific

For integrators such as wallets, indexers, lending protocols, custodians, dashboards, and RWA aggregators, this means custom adapters are often required for every fund.

uFund attempts to standardize the common fund metadata and lifecycle surface without forcing issuers to change their underlying token model, compliance system, custody system, or subscription/redemption architecture.

Design Goals

The proposal is intentionally:

  • read-heavy
  • base-token-agnostic
  • compatible with ERC-20, ERC-4626, ERC-7540, ERC-7575, ERC-3643, and ERC-7943-style systems
  • minimal in the mandatory core
  • extensible through optional interfaces
  • non-prescriptive on privileged/admin write functions

Core Interface

The mandatory core focuses on:

NAV

  • navPerShare()
  • navAsOf(uint256 timestamp)
  • navUpdatedAt()
  • navStale()
  • navStalenessThreshold()
  • valuationCurrency()

Lifecycle

  • lifecycleState()
  • lifecycleStateUpdatedAt()

Distributions

  • pendingDistributions()
  • lastDistribution()
  • nextDistributionDate()

Basic fund parameters

  • managementFeeBps()
  • performanceFeeBps()
  • subscriptionFeeBps()
  • redemptionFeeBps()
  • minInvestment()
  • subscriptionWindow()
  • redemptionWindow()
  • maturityDate()

Events-Only Write-Side Design

One of the main design choices is that uFund does not standardize admin write function signatures.

For example, the standard does not require every implementation to expose the same function names for:

  • setting NAV
  • changing lifecycle state
  • declaring distributions
  • updating AUM
  • publishing attestations

Instead, implementations are free to use their own admin model, oracle model, batch process, role system, multisig, DAO, or off-chain accounting flow.

What uFund standardizes is the event stream that must be emitted when corresponding state changes occur.

This is intended to give integrators and indexers a consistent way to observe fund state changes without forcing all issuers into the same write architecture.

This is similar in spirit to how ERC-20 standardizes Transfer and Approval events, while minting and burning mechanics remain implementation-specific.

Required Events

The core proposal defines required events such as:

  • NavUpdated
  • LifecycleStateChanged
  • DistributionDeclared
  • DistributionPaid
  • DistributionCancelled

Optional extensions define additional events such as:

  • AUMUpdated
  • ShareClassAdded
  • AttestationPublished

Optional Extensions

The current draft separates more debatable or fund-specific concepts into optional extensions:

IERC_UFUND_AUM

For funds that want to expose AUM and AUM update timestamps.

IERC_UFUND_Lockup

For funds that expose per-holder lockup expiry information.

IERC_UFUND_Yield

For funds that expose account-level accrued yield separately from NAV appreciation.

IERC_UFUND_MultiClass

For funds with multiple share classes.

IERC_UFUND_ProofOfReserves

For funds that publish proof-of-reserves or reserve attestation metadata.

Why Not Just ERC-4626 or ERC-7540?

ERC-4626 and ERC-7540 are vault/request-flow standards. They are useful and complementary, but not every tokenized fund is structured as an on-chain vault.

Some tokenized funds use:

  • permissioned ERC-20 share tokens
  • off-chain accounting
  • admin-pushed NAV
  • oracle-pushed NAV
  • daily dividend models
  • price-appreciating share models
  • asynchronous subscription/redemption workflows

uFund is intended to be additive and compatible with existing standards rather than a replacement.

A contract could implement:

  • ERC-20 + uFund
  • ERC-4626 + uFund
  • ERC-7540 + uFund
  • ERC-3643 + uFund
  • ERC-7943 + uFund

Reference Implementation

A draft reference implementation is available here:

The implementation is non-normative and mainly intended to demonstrate:

  • the core interface
  • optional extension interfaces
  • ERC-165 support
  • required event emission
  • a simple admin-driven reference implementation

Open Questions

I would appreciate feedback on the following:

  1. Is the mandatory core still too broad, or is NAV + lifecycle + distributions + basic fund parameters an acceptable minimum surface?

  2. Should AUM remain an optional extension, or should it be part of the core interface?

  3. Should lockup information be standardized at all, given that it can expose holder-specific information?

  4. Is the events-only write-side design acceptable, or should some write functions be standardized?

  5. Are the lifecycle states sufficient for most tokenized fund/RWA products?

  6. Are the indexed fields in the events suitable for indexers and analytics platforms?

  7. Should proof-of-reserves remain an optional extension, or should it be handled by a separate ERC entirely?

Next Steps

I am posting this here first to collect feedback before opening a PR to the ethereum/ERCs repository.

After discussion and iteration, I plan to submit the draft as:

ERCS/erc-draft_ufund.md

with ERC-165 interface IDs computed from the final Solidity interfaces.