# Incorrect settleFee process for cross-margin account

Elfi Protocol's _settleCrossAccount applies settle fee twice for cross-margin positions, letting traders avoid paying fees and causing reverts on negative net PnL.

- Payout: Contest reward
- Severity: medium
- Program: Elfi Protocol
- Credited: jennifer37
- Disclosed: 2024-05-09
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-05-elfi-protocol-judging/issues/61
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-05-elfi-protocol%3AM-3
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:sherlock sev:medium technique:source-review vuln:business-logic vuln:fee-bypass vuln:precision-loss

**Target:** DecreasePositionProcess.sol _settleCrossAccount
**Root cause:** Settle fee is deducted/added once via subTokenWithLiability/addToken, then added again inside the recordPnlToken>=0 branch as (recordPnlToken + settledFee), double-counting the fee.
**Steps:**
1. Open a cross-margin position on Elfi Protocol.
2. Close or decrease the position so cache.settledFee > 0 (e.g. 10).
3. Observe _settleCrossAccount first calls subTokenWithLiability(marginToken, settledFee, SETTLE_FEE).
4. Since recordPnlToken >= 0, it then calls addToken(marginToken, recordPnlToken + settledFee, SETTLE_PNL), re-crediting the fee.
5. Net effect: trader does not pay the settle fee; if recordPnlToken + settledFee < 0, toUint256() reverts.
**How found:** Manual code review of _settleCrossAccount noticed the settle fee is applied in the initial if/else and then included again in the (recordPnlToken + settledFee) addToken call.
**Exploitation:** A trader repeatedly opens and closes cross-margin positions with positive PnL, avoiding all settle fees (borrow, funding, close) because the fee is refunded in the second addToken call.
**Insight:** In position-close accounting, check whether fee adjustments are applied once or folded into a later PnL settlement; double-counting can silently refund fees or cause signed-to-unsigned cast reverts.