# Single-sided deposits that are auto-adjusted may have their collateral value cut in half

Typo in GMX deposit adjustment used subtraction instead of assignment, leaving adjusted long amount zero and halving single-sided depositor collateral value.

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

**Target:** GMX Synthetics ExecuteDepositUtils deposit adjustment logic
**Root cause:** Line 406 uses `adjustedLongTokenAmount - longTokenAmount - adjustedShortTokenAmount;` (subtraction, result discarded) instead of assignment, so adjustedLongTokenAmount stays at its zero-initialized value.
**Steps:**
1. Submit a single-sided deposit of only the long collateral token such that auto-adjustment triggers (diff < poolShortTokenAmount)
2. Observe getAdjustedLongAndShortTokenAmounts returns adjustedLongTokenAmount = 0 due to the discarded subtraction
3. Without a min-output slippage check, deposit executes with long portion zero, receiving ~half expected market tokens
4. With sane slippage, transaction reverts, breaking the feature
**How found:** Code review of getAdjustedLongAndShortTokenAmounts spotted the missing assignment operator on the adjusted long amount computation.
**Insight:** In adjustment/rebalancing math, verify every computed branch actually assigns its result to the returned variable; a bare expression statement silently discards the value and leaves defaults.