The following standard formalizes the Series Accounting Method for ERC-7540 type vaults, enabling them to collect performance fees on yields without introducing a free-ride problem.
Current ERC-7540 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 a free-ride problem.
A free-ride 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.
Check out the full proposal here: Add ERC: Series Accounting for Incentivized Vaults by 0xpanicError · Pull Request #1429 · ethereum/ERCs · GitHub
This proposal addresses a real accounting issue that shows up in ERC-7540 style vaults once deposits are settled asynchronously and performance fees are involved.
What this standard gets right
- Fixes the free-ride problem
A single vault-wide high-water mark assumes all users entered at similar prices, which breaks down when deposits are claimed at different exchange rates. Series-level accounting avoids newer deposits benefiting from recoveries they didn’t participate in.
- Series as deposit cohorts makes sense
Treating each claimed batch as its own accounting unit closely mirrors traditional fund accounting and maps well to how ERC-7540 request settlement already works.
- Reverting ERC-4626 conversion helpers is the honest choice
When shares are non-fungible across series, exposing a single totalAssets or conversion rate would be misleading. Forcing integrators to handle this explicitly is better than leaking incorrect abstractions.
- Asset-based redemption is the right abstraction
Once users can hold positions across multiple series, shares stop being a meaningful request unit. Redeeming by assets avoids pushing internal accounting complexity onto users.
Points implementations should be careful about
- Consolidation timing and fee finalisation
Merging series once a new high-water mark is reached is necessary for gas and reporting, but the exact trigger conditions matter. Edge cases around partial recoveries or fee timing need to be handled very carefully.
Overall, the added complexity feels justified for incentivised ERC-7540 vaults, especially those tracking RWAs or discretely priced strategies. This is not free complexity — it’s complexity that already exists, now made explicit and fair.
1 Like
Thanks for the reply!
Yes you’re right about the consolidation logic. In the proposal and reference implementation, I suggest consolidation logic can be to merge all outstanding series when the lead series reaches a new highwater mark. This was a design decision to try to keep complexities at a minimum.
But individual implementation can also for partial consolidations as well where outstanding series consolidate into each other instead of the lead if they are in sync with each other but not the lead yet. Although this must be done more carefully as it leads to more edge cases and has a greater surface for attack vectors.
For context, the reference implementation is also audited by Sherlock and thouroughly tested with integration and fuzz tests. You can find the report here.
Thanks for the clarification — that makes sense.
Consolidating outstanding series only when the lead series reaches a new high-water mark feels like a reasonable default to keep both state complexity and attack surface under control. I agree that partial or peer-to-peer consolidation between non-lead series can quickly introduce edge cases, especially around fee realisation and ordering.
It’s also good to know the reference implementation has gone through a Sherlock audit and extensive fuzzing — that adds confidence around the baseline design.
One follow-up from an implementer’s perspective:>
- Do you see value in standardising consolidation policies (not just mechanics) in a future extension?
For example, explicitly defining when partial consolidation is safe vs discouraged could help teams avoid diverging designs that reintroduce risk while still allowing flexibility.
Overall, the choice to keep the default consolidation path simple feels pragmatic, especially for early adopters of ERC-7540-style vaults.
I think consolidation policies can be left an open design space for individual protocols. I was given an advice from other ERC authors to not over specify a standard as it makes it too opinionated and can make the standard restrictive for applications.