# Users that have to claim collateral more than once for a time slot, may get the wrong total amount

GMX claimCollateral stored the factor-adjusted amount as claimed, so users claiming twice in one time slot after a factor change received less collateral than owed.

- 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/142
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-gmx%3AM-29
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:accounting-error

**Target:** GMX Synthetics MarketUtils.claimCollateral collateral claim accounting
**Root cause:** The claimedCollateralAmountKey is set to adjustedClaimableAmount (factor-applied total) instead of claimableAmount, so subsequent claims subtract the wrong baseline.
**Steps:**
1. User triggers claimable collateral of 1 ETH for a time slot; keeper sets claimableFactor=1.0
2. User claims: adjustedClaimableAmount=1, claimedAmount stored as 1, receives 1 ETH
3. Keeper sets claimableFactor=0.5 for that time slot
4. User triggers another 1 ETH claimable (claimableAmount=2) for same time slot
5. User claims: adjustedClaimableAmount=2*0.5=1, remainingClaimableAmount=1-1=0, receives nothing though 1.5 ETH total was owed
**How found:** Code reading of claimCollateral's accounting: noticed the stored value used adjustedClaimableAmount rather than the raw claimableAmount, then constructed a two-claim scenario with a factor change to show the shortfall.
**Exploitation:** No attacker action; a user legitimately claiming twice in a time slot after a claimableFactor change loses the difference because the stored claimed amount is inflated by the factor.
**Insight:** In claim-style accounting, verify the persisted 'claimed' baseline is the raw accumulated amount, not a factor-scaled value; factor changes between claims break subtraction logic.