Repay transactions fail when the USDG repay amount contains decimal values other than .00. This happens consistently when using the HALF or MAX buttons, which auto-fill a decimal amount. The transaction simulation fails and the transaction cannot be executed.
Observed behavior:
When HALF or MAX is selected, the interface auto-fills a repay amount with multiple decimals.
Example: 2.115207 USDG.
Submitting Repay with this value results in a failed simulation and failed transaction.
Example failed TX:
4jbBsWHK7KpEDFYuPAnuxdD5eLFPhTj1oiPLJHUEPTUkvhhA16PWCb4oeiZePyecCqNfqCSArTwVfJsG2W2HSS6T
Successful behavior (workaround):
Repay succeeds only when the effective repay amount equals an exact .00 USDG value.
Workaround: manually adjust the input to a slightly different decimal so the effective repay value resolves to exactly X.00 USDG.
Example: entering 2.0000601 results in an actual repay of exactly 2.00 USDG and the transaction succeeds.
Example successful TX:
63SPUJwNqL3YoW4M4WsdP6iQpjxBZQb8648tuJ99oBfAZ73cCPnT21tEVxAYcBkaEQLgvu4xf3fiupFMGTJNtBWY
Impact:
- Repay is blocked for normal users
- HALF and MAX buttons produce unusable values
- Root cause is not visible to users
- Multiple retries caused extra fees and liquidation risk in my case
Notes:
Support previously indicated the team was aware, but the issue was still reproducible. I was only able to proceed after isolating the decimal precision constraint manually.