Reproduced Exploit
FeeManager miscalculates performance fees — AuditVault synthetic reduction
This bug report discusses an issue found in the performance fee calculation of the Mellow Flexible Vaults protocol. The current formula used in the FeeManager.calculateFee function is incorrect and leads to incorrect fee calculations. The root cause of the issue is that the formula assumes that the…
Chain
Other
Category
logic
Date
Jul 2025
Source
AuditVault
EVM Playground
Source-level debugger — step opcodes and Solidity in sync
The attack is replayed in an in-browser EVM preloaded with the exact dumped fork state. The execution tree shows every call; step by Solidity line or by opcode across all depths — source, Stack, Memory, Storage, Balances (native / ERC-20 / NFT), Transient storage and Return value stay in sync. Click a tree node, opcode, or source line to jump. No backend, no live RPC.
Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 62110-h-5-incorrect-performance-fee-calculation-in-feemanager-sher. Standalone Foundry PoC and full write-up: 62110-h-5-incorrect-performance-fee-calculation-in-feemanager-sher_exp in the
evm-hack-registrymirror.
Vulnerability classes: vuln/logic/fee-calculation · vuln/arithmetic/precision-loss
Reproduction: self-contained Foundry PoC with an offline synthetic contract. Full trace: output.txt.
AuditVault finding: 62110 · H-5: Incorrect performance fee calculation in FeeManager``
Key info#
| Impact | HIGH — FeeManager miscalculates performance fees |
| Protocol | [[Mellow]] Flexible Vaults |
| Finding | AuditVault #62110 |
| Report | https://github.com/sherlock-audit/2025-07-mellow-flexible-vaults-judging |
| Source | AuditVault finding |
| Compiler | ^0.8.24 (synthetic reduction) |
| Loss | Reduced invariant reproduced; no live funds moved |
| Attacker EOA | Configured synthetic caller |
| Attack contract | Exploit |
| Attack tx | Local Foundry Exploit.attack() call |
| Chain · block · date | Ethereum model · block 1 · synthetic |
| Vulnerable contract | Local synthetic vulnerable contract in test/ |
| Bug class | See vulnerability-class tags above |
TL;DR#
This bug report discusses an issue found in the performance fee calculation of the Mellow Flexible Vaults protocol. The current formula used in the FeeManager.calculateFee function is incorrect and leads to incorrect fee calculations. The root cause of the issue is that the formula assumes that the price difference can be directly multiplied by the total shares, which is not the case. This can result in incorrect performance fee calculations. The report also includes a suggested correction to the formula to properly convert the price difference to share amounts. The protocol team has fixed this issue in their code.
Background#
The upstream report is a Solidity finding. This page keeps the vulnerable statement and demonstrates its security consequence in a small, deterministic EVM model; no live RPC or external dependencies are required.
The vulnerable code#
// The exact vulnerable pattern is retained in test/62110-h-5-incorrect-performance-fee-calculation-in-feemanager-sher.sol.
// @> see the marked statement in the synthetic reduction
Root cause#
The caller-controlled input or stale state is trusted before the required uniqueness, bounds, authorization, accounting, or reentrancy invariant is enforced. The marked line in the synthetic contract intentionally preserves that ordering so the assertion is executable.
Preconditions#
- The vulnerable contract is deployed with the state described by the report.
- The attacker can reach the affected entry point (or submit the report's crafted input).
Attack walkthrough#
Exploit.run()initializes the minimal state from the report.- The marked vulnerable operation executes without its required check.
- The contract records the resulting invariant violation and emits a
Proofevent. - The test asserts the harm; the passing trace is recorded at output.txt:4.
Diagrams#
Remediation#
Apply the invariant before mutating state: accrue interest before adding principal; reject duplicate signers; use checked casts and bounded lengths; validate token/target/DAO identities; use nonReentrant; enforce slippage and fee equality; and validate the canonical authority or ownership relationship described by the report.
How to reproduce#
cd evm-hack-registry/62110-h-5-incorrect-performance-fee-calculation-in-feemanager-sher_exp
forge test -vvvvv
The test is offline and uses only the shared forge-std library. The corresponding Playground bundle is generated from scripts/poc-configs/62110-h-5-incorrect-performance-fee-calculation-in-feemanager-sher.mjs.
Sources#
- AuditVault finding
- https://github.com/sherlock-audit/2025-07-mellow-flexible-vaults-judging
- Synthetic test
Reference: https://github.com/sherlock-audit/2025-07-mellow-flexible-vaults-judging
Sources & further analysis#
Reproductions & code
- Standalone PoC + full trace: 62110-h-5-incorrect-performance-fee-calculation-in-feemanager-sher_exp (evm-hack-registry mirror).
- AuditVault finding: 62110-h-5-incorrect-performance-fee-calculation-in-feemanager-sher.
Alerts & third-party analyses
These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.