VAULT INFRASTRUCTURE

The Next Generation of Tokenized Vault Standards. Part 2

A Vault Is Not a Fund: New Standards for Asset Managers

ERC-4626 gave tokenized vaults a common language for issuing shares and converting them back to assets. Part 1 covered the ERCs that extend the vault mechanics — async requests, multi-asset entry points, native assets. But a standardized vault interface is not a standardized investment fund. This installment looks at a newer group of proposals that try to standardize the fund itself: fee allocation, investment mandates, portfolio composition, NAV and lifecycle reporting, reserves, and yield positions that don't fit the vault model.

A vault is not a fund

ERC-4626 answers a narrow but important question: how do you convert assets into fungible shares, and shares back into assets? That is enough for a simple yield vault. It is not enough to describe the economic and operational structure of a managed fund. Consider two products that both expose ERC-4626 shares — a passive USDC lending vault, and an actively managed private-credit fund with monthly subscriptions, quarterly redemptions, administrator-published NAV, performance fees, and a restricted mandate. At the interface level they look alike; as products they are nothing alike. A complete fund has several layers:

Fund product
│
├── Share and accounting model
├── Subscription and redemption process
├── Portfolio composition
├── Manager permissions
├── Fee allocation
├── NAV and reporting
├── Lifecycle and maturity
└── Distributions and investor information

ERC-4626 addresses the first layer; Part 1's ERC-7540 and ERC-7575 extend subscription, redemption, and multi-asset mechanics. The proposals below move further up the stack — they try to standardize parts of the fund itself. As of July 20, 2026, none is Final:

1. ERC-8113: fair performance fees

Performance fees typically charge the manager a cut of returns above a previous high-water mark, so the manager isn't paid merely for recovering an earlier loss. For a single vault that seems simple — charge only when price per share exceeds the mark. The problem is that investors enter at different prices:

Investor A deposits when the share price is 1.00.
The fund rises to 1.20.
Investor B then deposits at 1.20.
The fund falls to 1.10 and later recovers to 1.25.

Investor A has earned 25%.   Investor B has earned ~4.2%.

With one global high-water mark, newer investors may get a "free ride" or older ones may bear part of the fee created by later subscriptions. ERC-8113 proposes series accounting: instead of one global pool and one mark, the vault creates separate accounting series, each with its own totalAssets, totalShares, balances, and high-water mark. Investors settled together (entering at the same price) join the same series:

Series 1                         Series 2
├── Investors entering at 1.00   ├── Investors entering at 1.20
└── High-water mark: 1.00        └── High-water mark: 1.20

Each series is charged against its own starting point. It works for both periodically rebalanced ERC-4626 vaults and async ERC-7540 vaults (a batch of deposits claimed at the same price forms a new series). This imports a traditional fund-administration concept — series accounting, equalization credits — into on-chain infrastructure.

The accuracy has a cost: an indexer must track series creation, assets and shares per series, balances per series, high-water marks, per-series fee accrual, consolidation, and transfers between series. A wallet can no longer always show one balance and one price per share. The vault becomes less fungible internally.

Even if ERC-8113 isn't adopted, the problem remains: any fund that accepts investors at different times, recalculates NAV periodically, and charges performance fees has to decide how to allocate fees fairly. A global mark suffices for some products; sophisticated funds will find investor-cohort accounting hard to avoid.

2. ERC-8192: the investment mandate

ERC-4626 standardizes how capital enters and leaves a vault; it says almost nothing about what the manager may do with the assets. Platforms solve this with a grab-bag of proprietary systems — role-based access, allowlisted targets, approved adapters, function-selector restrictions, Merkle proofs, Safe modules. They all answer one question: how can a manager, agent, or solver execute transactions without getting unrestricted control of the fund? ERC-8192 proposes a standard interface for mandated execution (still an early forum draft).

It defines three roles — an authority that signs the mandate, an executor that submits actions, and the vault that holds assets and enforces the mandate. The authority signs an EIP-712 mandate specifying the permitted executor, a deadline, a nonce, an approved adapter set, a max loss per execution, a max cumulative drawdown, and optionally a committed batch of actions:

Authority signs bounded mandate
              ↓
Executor submits proposed actions
              ↓
Vault verifies signature and permissions
              ↓
Approved adapters execute
              ↓
Vault checks post-execution risk bounds

Adapters are constrained interfaces to external protocols — they limit which protocol, functions, calldata, and assets an executor can touch. Notably, ERC-8192's allowlist commits to the adapter's runtime code hash, not just its address, so an upgrade can't silently change approved behaviour. For risk, the vault reads totalAssets() before and after execution and enforces max per-execution and per-epoch loss — a circuit breaker.

That circuit breaker is only as reliable as totalAssets(). If an executor can manipulate the valuation oracle within the same transaction, the risk check gives false comfort — the proposal itself flags that vaults with manipulable or delayed valuations need extra oracle controls.

The direction is a shift from platform-specific roles to a signed, machine-readable mandate that vaults, smart accounts, agents, solvers, risk engines, and auditors could all interpret. As agent-based asset management grows, bounded authority — standardizing not just who can execute but what they may execute and which losses the vault will tolerate — becomes central.

3. ERC-7621: managed baskets

A tokenized index or managed basket needs to describe the portfolio, not just a list of accepted deposit assets. ERC-7621 proposes a common interface for a manager-rebalanced basket token (itself an ERC-20) whose holders have a proportional claim on the reserves. It makes the constituent set, each constituent's target weight, the recognized reserve per asset, the basket owner, and composition changes all queryable — plus multi-asset contribution and proportional withdrawal with built-in slippage protection.

The distinction from ERC-7575 (Part 1) matters:

ERC-7575:  Which assets can investors use to enter or exit?
ERC-7621:  Which assets should the portfolio contain, and at what weights?

A fund could accept only USDC from investors while holding a basket of ETH, WBTC, and tokenized Treasuries — subscription asset and portfolio constituents are separate concepts. ERC-7621 is also careful to separate target weights from actual reserves: markets and flows cause drift, so the targets describe intent, not current alignment. Likewise its rebalance() interface standardizes a change in weights without prescribing how swaps execute (AMMs, aggregators, auctions, intents) — sensible, since forcing one execution method into the interface would make it too restrictive.

ERC-7621 standardizes visibility into the basket; it does not make the product trustless. The owner (identified via ERC-173) can change composition, so investors still must assess whether ownership is an EOA, multisig, or DAO, whether rebalancing is delayed, and whether the manager can add illiquid assets or extract value during rebalancing.

4. ERC-8318: the fund as a product

A share token can tell a wallet the name, symbol, balance, and transfer history — but not whether the fund is active, closed, suspended, or matured; when NAV was last updated or whether it's stale; which fees apply; when subscriptions and redemptions open; or whether a distribution was declared. ERC-8318, proposed as uFund, standardizes this fund-level information. It is deliberately read-heavy and base-token-agnostic — a fund can combine it with ERC-20, ERC-4626, ERC-7540, ERC-7575, a security-token standard, or a proprietary subscription system.

The mandatory core covers NAV information (NAV per share, historical NAV, last-update time, staleness status and threshold, valuation currency), lifecycle state and its last change, distributions (pending, last, next expected), and basic parameters (management / performance / subscription / redemption fees, minimum investment, subscription and redemption windows, maturity). Optional extensions add AUM, lockups, accrued yield, multiple share classes, and proof-of-reserves.

A strong design choice: it standardizes reads and events, not the privileged write path. Issuers update NAV via an administrator, oracle, multisig, DAO vote, or off-chain process — forcing one setNAV() would standardize a sensitive write without fixing the trust model. Instead everyone exposes a consistent way to read NAV and observe a NavUpdated event, which is exactly what indexers need.

ERC-4626 answers:
  How many accounting assets correspond to these shares?

ERC-8318 attempts to answer:
  What does the fund report about its NAV, lifecycle, fees, and distributions?

The hard part is scope: funds vary enormously (accumulating vs distributing, fixed-maturity vs evergreen, one share class vs many), so drawing the line between core and optional data is genuinely difficult. But wallets, custodians, lending protocols, and fund marketplaces need some common way to understand a fund without a custom adapter per issuer.

5. ERC-8330: NAV is a history, not a number

ERC-8318 (above) exposes a fund's reported NAV as one metadata field. ERC-8330 takes NAV seriously as a subject of its own. For a fully on-chain ERC-4626 vault, totalAssets() / supply is a fine accounting value — but for private credit, real estate, and other administratively valued funds, NAV is calculated periodically, published after the valuation date, sometimes restated, and can go stale. ERC-8330 proposes a Subject-Linked NAV Snapshot Oracle: streams keyed by (subjectId, currency) with one basis each (PER_UNIT, PER_SHARE, or TOTAL), so a provider can't mix total and per-share NAV in one stream.

The standout idea is separating valuation time from publication time, with independent staleness checks for each:

Valuation timestamp:   June 30   →  "Is the underlying valuation itself too old?"
Publication timestamp: July 10   →  "Has the provider stopped publishing?"

Snapshots preserve provider attribution (administrator vs independent valuer vs auditor NAV), use append-only correction chains, and support administrative invalidation that drops a snapshot from current queries while keeping it in history. An optional extension defines deterministic lower-median aggregation across providers (which still can't remove correlated error). Its most important warning:

Reported NAV  ≠  market price  ≠  guaranteed redemption price  ≠  liquidation value

A private-credit fund may report 1.00 per share while redemptions are suspended, and a token can trade at a discount or premium to NAV. Infrastructure should store accounting value, reported NAV, market price, redemption price, and liquidation value separately — treating them as interchangeable produces misleading analytics. Of these fund-level standards, ERC-8330 may be the most immediately relevant to fund platforms and indexers; these fields belong in any serious tokenized-fund data model whether or not the ERC is adopted.

6. ERC-7425: tokenized reserves

Not every pool of managed assets exists to maximize returns. A reserve provides contingency capital — DAO treasuries, protocol insurance funds, emergency backstops, collateral-support facilities. ERC-7425 proposes a tokenized reserve built on ERC-4626: stakeholders deposit an asset and receive shares, and the proposal adds mechanisms to create and record proposals about reserve outflows so participants can signal support for spending funds. The emphasis is on stakeholder participation, auditable inflows and outflows, and authorization around withdrawals.

The key insight: reserve shares are not investment shares. They may represent governance participation, a claim on remaining assets, or membership in a contingency pool — and the reserve may be expected to spend capital in an emergency. Classifying every ERC-4626-like share as a yield product produces misleading analytics; a reserve is better judged by capital adequacy, coverage ratios, authorized uses, and withdrawal governance than by APY.

ERC-7425 is an early Draft with a narrow spec — it doesn't resolve who declares an emergency, what threshold is required, whether shares are transferable, or how losses are allocated after a payout (likely too product-specific for one ERC). Its main value may be conceptual: tokenized reserves deserve a distinct model rather than being treated as generic vaults.

7. ERC-5115: yield beyond the vault

ERC-4626 works when there is one accounting asset that users deposit, the vault issues fungible shares, and shares convert back to that same asset. Not every yield-bearing position fits: an AMM liquidity position may need several input tokens and express value through an invariant rather than one depositable token; a position may emit separate reward tokens. ERC-5115, the SY Token standard, proposes a more flexible wrapper — exposing multiple accepted input tokens, multiple output tokens, an underlying yield-bearing token, and preview / conversion functions.

ERC-4626:  A standard vault with one accounting asset.
ERC-5115:  A generalized wrapper around a yield-generating mechanism.

It is not a claim that ERC-4626 is insufficient for ordinary vaults — its own motivation expects ERC-4626 to remain preferred for products that fit the vault model. The goal is to reduce custom adapters for positions outside it: LP tokens, staked LP, reward-bearing receipts, liquid staking assets, and protocol-specific yield tokens. For an asset manager, a generalized wrapper makes such positions easier to value, compose, and use as portfolio constituents — though wrapping them behind one interface does not remove impermanent loss, reward-token quirks, withdrawal constraints, or oracle assumptions. The likely answer is that both standards are needed: ERC-4626 for simplicity, a broader wrapper for assets without one depositable accounting token.

How the proposals fit together

These are not competing alternatives — they address different layers of the fund stack:

Investor-facing fund information
├── ERC-8318: lifecycle, fees, distributions
└── ERC-8330: provider-attributed NAV history

Portfolio design
└── ERC-7621: constituents and target weights

Manager authority
└── ERC-8192: bounded delegated execution

Investor accounting
└── ERC-8113: series and performance-fee allocation

Product category
└── ERC-7425: stakeholder-governed reserve

Underlying yield positions
└── ERC-5115: generalized yield-bearing wrappers

A sophisticated product could combine several: ERC-7540 for async subscriptions, ERC-8113 for series-level fees, ERC-8192 to constrain strategy agents, ERC-8318 and ERC-8330 to expose lifecycle and NAV, ERC-5115-style yield positions, and an ERC-7621-like portfolio interface. No single implementation will do all of that soon — the point is how far the tokenized-fund model is expanding beyond basic vault shares.

Crucially, these needs aren't theoretical — platforms already ship proprietary high-water-mark fees, subscription queues, NAV calculation, manager roles, approved adapters, and rebalancing. So:

The market may agree a capability is necessary without agreeing on the ERC that should standardize it. A new standard gains adoption only if it defines a narrow, recurring problem, avoids over-prescribing implementation, stays compatible with existing contracts, and ships with reliable interface detection, events, and reference code. Broad proposals face a harder path, because funds differ in governance, valuation, compliance, custody, and fees.

Ranked by the importance of the problem each addresses (not a prediction of adoption): ERC-8113 (fair fees) and ERC-8192 (bounded mandates) top the list for asset managers and infrastructure, followed by ERC-8330 (NAV history), ERC-8318 (fund metadata), and ERC-7621 (basket composition) for wallets and indexers, with ERC-5115 (yield wrappers) and ERC-7425 (reserves) rounding it out.

ERC-4626 standardized the vault. The next challenge is standardizing the fund built around it — moving from "how shares are issued" toward "how funds are accounted for, managed, described, and understood." Most of these remain early-stage, and even a finalized standard needs real implementations before it matters. But the direction is clear.