fix(amount): round USDC to whole base units so the on-chain amount is an integer - #45
Open
Bornoz wants to merge 1 commit into
Open
fix(amount): round USDC to whole base units so the on-chain amount is an integer#45Bornoz wants to merge 1 commit into
Bornoz wants to merge 1 commit into
Conversation
… an integer convertUSDCToContractAmount scales a USDC amount to 6-decimal base units for the uint256 that pay(address,uint256,address) takes, but it does it in floating point: (amount * 1000000).toString(). Ordinary amounts land just under a whole unit — 2.01 becomes "2009999.9999999998", 1.005 becomes "1004999.9999999999" — and toString carries the fraction straight through. Both deposit routes pass the result as the uint256 amount, so a plain 2.01 deposit goes on-chain as a non-integer: rejected by the encoder, or truncated a base unit short. Round to the nearest base unit, which is the integer the function is meant to produce.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
convertUSDCToContractAmountturns a USDC amount into 6-decimal base units for theuint256thatpay(address,uint256,address)takes, but it scales in floating point:(amount * 1000000).toString(). Ordinary amounts land just under a whole unit —2.01becomes"2009999.9999999998",2.05"2049999.9999999998",1.005"1004999.9999999999"— and.toString()carries the fraction straight through. Around 3% of cent-precision amounts are affected.Both deposit routes then do
Number(convertUSDCToContractAmount(...))and pass the result as theuint256amount to the escrowpay()call (app/api/contracts/escrow/deposit/route.ts,.../deposit/approve/route.ts), so a plain $2.01 deposit goes on-chain as a non-integer amount — rejected by the encoder, or truncated a base unit short.Rounding to the nearest base unit is the correct fixed-point conversion and restores the integer the function is meant to produce. Verified against the current values:
2.01,2.05,4.02,1.005return fractional strings before the change and the exact base-unit integers after;tsc --noEmitandprettier --checkstay clean.Separate from #44, which fixes
parseAmount.