Fix XMTP transfer amount parsing#982
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: 03bce09611
ℹ️ 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".
| if not decimal_amount.is_finite() or decimal_amount <= 0: | ||
| raise ToolException("Amount must be a positive finite number") | ||
|
|
||
| base_units = decimal_amount * (Decimal(10) ** decimals) |
There was a problem hiding this comment.
For amounts with more than the default 28 significant digits, this multiplication is rounded by Python's active decimal context before the integer check runs; for example, _parse_token_amount("123456789123456789.123456789123456789", 18) produces 123456789123456789123456789100000000 instead of 123456789123456789123456789123456789. Because that rounded value is then embedded in the wallet_sendCalls payload, large or high-precision transfers can silently request the wrong base-unit amount while still passing validation.
Useful? React with 👍 / 👎.
1 participant
Fixes XMTP transfer amount conversion to avoid float precision loss for large or high-precision token amounts.
Also rejects non-finite, non-positive, or over-precision amounts before building wallet_sendCalls payloads.