Avoid precision loss in formatUnits#255
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9f0d3514be
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return integerPart; | ||
| } | ||
|
|
||
| return `${integerPart}.${truncatedFraction.replace(/0+$/, '')}`; |
There was a problem hiding this comment.
When the requested precision keeps only zero fractional digits, truncatedFraction is truthy before the trailing-zero trim, so this returns a dangling decimal point. For example, formatUnits('1', { decimals: 18, precision: 2 }) now returns "0." instead of the previous/expected "0", which breaks small values below the display precision.
Useful? React with 👍 / 👎.
1 participant
helpers.formatUnitscurrently applies the optionalprecisionby converting the formatted decimal string throughparseFloat. That can lose precision for large token amounts before truncation.This keeps the precision truncation on the decimal string instead, matching the existing truncate-not-round behavior while preserving large values exactly.