# Position net value is using outdated fees

Elfi perpetuals compute cross net value from stale funding/borrowing fees cached at last market interaction, delaying liquidations and risking insolvency.

- Payout: Contest reward
- Severity: high
- Program: Elfi Protocol
- Credited: mstpr-brainbot
- Disclosed: 2024-05-09
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-05-elfi-protocol-judging/issues/41
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-05-elfi-protocol%3AH-7
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:business-logic vuln:liquidation vuln:oracle-manipulation

**Target:** perpetual futures cross-margin net value / liquidation engine
**Root cause:** _getCrossNetValue subtracts cache.totalPosFee derived from fundingFeePerQty and cumulativeBorrowingFeePerToken, which only update on the last market interaction rather than accruing to current time.
**Steps:**
1. Deposit 1M USDC as user0 and open a 5x cross LONG BTC position via createOrderRequest/executeOrder
2. Read getCrossMMRTapir to record crossNetValue
3. mine(1000,{interval:150}) to accrue fees, re-read crossNetValue — unchanged
4. Have user1 open any small position to refresh per-token fee accumulators
5. Re-read user0 crossNetValue — drops significantly (957031...→948117...) despite no user0 action
**How found:** Reading _getCrossNetValue and tracing totalPosFee to getPositionFee, noticing funding/borrowing per-token values come from market-level accumulators only refreshed on interaction; confirmed with a coded PoC showing net value frozen over time then jumping when another user trades.
**Insight:** In perp/DEX accounting, check whether fee or interest accumulators are lazily refreshed per-market rather than time-accrued; a stale accumulator in a liquidation-relevant value lets positions appear healthier than reality until an unrelated trade triggers the update.