# Pool value calculation uses wrong portion of the borrowing fees

GMX getPoolValue added the fee-receiver share of borrowing fees instead of the pool's share, mispricing LP shares on deposit and withdrawal.

- Payout: Contest reward
- Severity: high
- Program: Gmx
- Credited: 0xAmanda
- Disclosed: 2022-09-22
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-gmx-judging/issues/131
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-gmx%3AH-14
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** GMX Synthetics MarketUtils.getPoolValue() share pricing
**Root cause:** getPoolValue() applies BORROWING_FEE_RECEIVER_FACTOR to total borrowing fees and adds that receiver portion to pool value, instead of adding the pool's remaining portion (total minus receiver factor).
**Steps:**
1. Read MarketUtils.getPoolValue(): totalBorrowingFees summed for long/short tokens
2. Observe `cache.value += Precision.applyFactor(totalBorrowingFees, borrowingFeeReceiverFactor)` adds the receiver's cut
3. Note the pool's actual share is `totalBorrowingFees - applyFactor(total, receiverFactor)`
4. Since getPoolValue drives share minting in ExecuteDepositUtils and collateral return in WithdrawalUtils, LP share pricing is skewed
**How found:** Code review of the pool value accounting: noticed borrowing fees split between pool and fee receiver, and that the factor multiplication yields the receiver's portion rather than the pool's, which was then added to pool value.
**Exploitation:** No direct attack flow given; mispricing means depositors/withdrawers receive incorrect share or collateral amounts, causing principal losses to some LPs at others' gain.
**Insight:** When a fee is split between protocol and pool, check which side a factor multiplication actually yields; applyFactor(total, receiverFactor) gives the receiver's cut, so the pool's value must use the complement.