Alert Source Discuss
⚠️ Draft Standards Track: ERC

ERC-8113: Series Accounting for Incentivized Vaults

Series Accounting method for collecting performance fees in ERC-7540 type vaults.

Authors Yash Saraswat (@0xpanicError)
Created 2025-12-25
Discussion Link https://ethereum-magicians.org/t/erc-8113-series-accounting-for-incentivized-vaults/27306
Requires EIP-4626, EIP-7540

Table of Contents

Abstract

The following standard formalizes the Series Accounting Method for ERC-7540 and ERC-4626 type vaults, enabling them to collect performance fees on yields without introducing the free-rider problem.

It defines the necessary architectural specification for implementing Series Accounting by requiring an independent Series to track each batch of claimed deposit requests within the vault with its unique totalAssets, totalShares, sharesOf and highwaterMark values.

Motivation

Current vault implementations typically implement a Highwater Mark based on the highest recorded price-per-share (the ratio of total assets to total shares of the vault) to ensure performance fees are not collected for recovering losses. But relying on a single vault-wide highwater mark introduces the free-rider problem.

A free-rider occurs when a user’s deposit is claimed at a price-per-share below the vault’s current highwater mark. When the vault later reaches a new highwater mark, the user doesn’t pay a performance fee on all yield accrued between their initial entry price and the new highwater mark, effectively diminishing returns for existing users.

This standard implements the series accounting method where all batches of deposit requests are claimed in a series which maintains a unique highwater mark for those deposits. This allows for the protocol to accurately account for performance fees across all user deposits fairly. The “free-ride” problem is prevalent in vaults that derive their yields from RWAs. Reflecting performance from off-chain assets like hedge or liquid fund portfolios can vary drastically from each rebalancing/settlement cycle.

This can cause large fluctuations in exchange rates (price-per-share) of a vault resulting in inaccurate performance fee collection from users. Series Accounting is a very common and standard method of accounting portfolios in traditional funds but lacks any formal implementation in DeFi.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

The general architecture of a vault remains the same. This standard can be used with both rebalancing type and async type vaults. For ERC-4626 type vaults which rebalances price-per-share periodically, all deposits made within a rebalancing period can be considered as a batch (all “settled” with same price-per-share). For ERC-7540 async type vaults, the user flows remain the same:

  • users requiring to submit a request to enter or exit the vault
  • vault implementing a method to move request from “pending” to “claimable” state

However, the structure in which assets and shares are maintained in the vault is altered to accommodate for series accounting. Traditionally, the vault will store a global value for totalAssets and totalShares, but to follow this specification, the following state variables MUST be maintained individually for each series:

  • total assets
  • total shares
  • shares of users
  • list of users
  • highwater mark

Definitions

  • series: a series is like a sub-vault where a set of all deposit requests that are claimed together are accounted for.
  • price-per-share: ratio of total assets to total shares in a series.
  • highwater mark: the highest price-per-share (also referred as exchange price) of a given series.
  • oracle: the entity responsible for setting the price-per-share of the vault.
  • settle: the act of rebalancing the vault or claiming the deposit requests performed by the oracle in a series id, determined by the logic specified in this standard.
  • lead series: each vault has a default series called the lead series where the first set of deposit requests will be claimed.
  • outstanding series: a series apart from the lead series which contains user shares.
  • consolidation: the process where all user shares are transferred from outstanding series to the lead series.
  • consolidated series: an empty series from which user shares were transferred during consolidation.

Deposit Flow

For ERC-4626 type vaults, when the oracle provides the price-per-share for rebalancing, all deposits that will follow in that rebalancing period will be considered as a batch and MUST settle in the same series id. For ERC-7540 type vaults, when the oracle provides the price-per-share at which the deposits are to be claimed, all deposits MUST settle in the same series id. The standard defines in which series id the deposits SHOULD be settled as follows:

  • if the current highwater mark of the lead series is greater than the price-per-share of the lead series
    • MUST create a new series with a unique series ID.
    • MUST settle all pending deposit requests in this new series.
  • else (if the highwater mark is less than or equal to the price-per-share):
    • MUST settle all pending deposit requests in the lead series.
    • If the number of outstanding series is greater than zero:
      • MUST consolidate all outstanding series into the lead series.

Redeem Flow

ERC-8113 vaults MUST allow users to redeem (or request a redeem) by providing assets instead of shares as input.

The vault is RECOMMENDED to store the proportion of total assets for that user in the redeem request.

When the request is to be settled, the redemption MAY follow the FIFO method. At the time of settling a redeem request for a given price-per-share, the amount is to be redeemed from the lead series first. If the total user assets in lead series is not sufficient to fulfill the request, the remaining amount should be redeemed from the outstanding series with the lowest series Id. This process must be continued until the entire request is fulfilled. The portion of redemption that takes place in a given series is called a Redeem Slice.

Rationale

Using “assets” instead of “shares” for redemption

We cannot use shares to specify the amount a user wishes to redeem because shares are non-fungible across series. A user who can have assets across multiple series cannot specify a single share value in the request to represent all user assets.

If requests are made for a given series, shares can be used but then:

  • user must make multiple requests if they wish to redeem more than what they own in a given series
  • if the series gets consolidated (in case of async vaults), the redemption may take place from lead series but price-per-share information must be stored which makes implementation very complicated and can introduce security risks

The best solution presented to be users specifying assets instead of shares when making a redeem request. While processing the request, the implementation can store the proportion of total user assets across all series that they wish to redeem.

This solves the issues of non-fungible shares and accounting across multiple series.

Consolidating Series

Each new set of deposit requests may require its own series. This can cause the number of outstanding series to increase in number drastically if vault periodically has periods of poor performance.

This can cause following problems:

  • having many outstanding series may result in any implementation processing them to exceed the block gas limit eventually which can render the vault unusable.
  • traditional fund managers that expect to fetch vault data for their accounting reports are not pleased with having bloated Net Asset Vaule (NAV)/Assets Under Management (AUM) sheets with multiple series.

After the lead series reaches a new highwater mark, all subsequent outstanding series also reach new highwater marks. When this happens, each existing user has paid their fair share of performance and there no longer exists a need to maintain these deposits separately.

Hence, consolidating all outstanding series during this point can help a vault never exceed block gas limit and also keeps accounting reports for traditional managers clean and concise.

Backwards Compatibility

Note that ERC-8113 is not backwards compatible with ERC-7540 or ERC-4626.

The incompatibilties with ERC-4626 are as follows:

  • totalAssets would require additional input seriesId
  • convertToShares would require additional input seriesId
  • convertToAssets would require additional input seriesId
  • redeem would need to replace input shares with assets

The incompatibilities with ERC-7540 are as follows:

  • requestRedeem would need to replace input shares with assets

Security Considerations

The fee calculation for yield bearing vaults can be complex as there can be multiple fixed and variable charges applied before performance fee. This can cause mismatch from expected and realised fee collections.

Protocols must be careful and thoroughly analyze the accounting resulting from their implementations to ensure they match expectations, and should provide clear documentation of all fee calculations.

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Yash Saraswat (@0xpanicError), "ERC-8113: Series Accounting for Incentivized Vaults [DRAFT]," Ethereum Improvement Proposals, no. 8113, December 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-8113.