# execute_claim() possible loss of accuracy or even inability to retrieve funds

Vesting claim_batch divides then multiplies release_amount, truncating amount_per_claim to zero so long-duration percentage vesting claims yield nothing.

- Payout: Contest reward
- Severity: medium
- Program: Andromeda Ado
- Credited: bin2chen
- Disclosed: 2024-05-14
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-05-andromeda-ado-judging/issues/49
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-05-andromeda-ado%3AM-10
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:precision-loss

**Target:** CosmWasm vesting contract claim_batch
**Root cause:** amount_per_claim = batch.amount * release_amount / 1e18 is computed first and truncated to Uint128, then multiplied by number_of_claims; when per-claim value rounds to zero, total payout is zero.
**Steps:**
1. Set batch.amount=1e8, release_unit=1s, release_amount≈6341958396 (1 BTC over 5 years, 1e18 precision)
2. Call claim_batch after lockup_end with elapsed_time=157680000s
3. Observe amount_per_claim = 1e8*6341958396/1e18 = 0
4. amount_to_send = 0 * 157680000 = 0, funds unclaimable
5. Fix: multiply before divide: batch.amount * number_of_claims * release_amount / 1e18
**How found:** Code reading of claim_batch arithmetic order; noticed division before multiplication and constructed a long-duration percentage vesting scenario where per-claim truncates to zero.
**Insight:** In fixed-point vesting math, check the order of mul/div: any per-unit amount computed before multiplying by unit count can truncate to zero for small release rates over long durations.