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.
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.
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:
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:
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:
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.
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:
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.
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:
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.
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 seriesIdconvertToShares would require additional input seriesIdconvertToAssets would require additional input seriesIdredeem would need to replace input shares with assetsThe incompatibilities with ERC-7540 are as follows:
requestRedeem would need to replace input shares with assetsThe 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.