# Owner unable to collect fulfillment fee from certain users due to revert error

Rounding in claimOrder can compute zero owed tokens for small depositors, causing safeTransfer(0) to revert on zero-disallowing tokens and blocking fee collection.

- Payout: Contest reward
- Severity: medium
- Program: Gfx
- Credited: XDZIBEC
- Disclosed: 2023-06-23
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-06-gfx-judging/issues/55
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-gfx%3AM-2
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:dos vuln:precision-loss

**Target:** LimitOrderRegistry.claimOrder (Uniswap V3 limit orders)
**Root cause:** owed = (totalTokenOut * depositAmount) / totalTokenDeposited rounds down to 0 for small depositors when token decimals differ greatly; safeTransfer of 0 reverts on tokens that disallow zero-value transfers.
**Steps:**
1. Batch has Alice depositing 10 SHIB (18 dec) and Bob 100000000 SHIB; batch claims 9 USDC (6 dec).
2. Compute owed = (9e6 * 10e18) / (100000000e18) = 0.
3. claimOrder calls `tokenOut.safeTransfer(user, 0)` which reverts on zero-disallowing tokens.
4. Owner cannot collect fulfillment fee because claim reverts.
**How found:** Code review of the proportional payout formula in claimOrder, reasoning about decimal mismatch between pool tokens and integer rounding to zero.
**Insight:** When auditing proportional-share payout math, check whether integer division can yield zero for dust depositors and whether downstream transfer/state logic reverts on zero amounts, especially across tokens with very different decimals.