Skip to content

Reject malformed token amounts before signing - #60

Open
SashaMIT wants to merge 1 commit into
WalletConnect:mainfrom
SashaMIT:fix/reject-malformed-token-amounts
Open

SashaMIT wants to merge 1 commit into
WalletConnect:mainfrom
SashaMIT:fix/reject-malformed-token-amounts

Conversation

@SashaMIT

@SashaMIT SashaMIT commented Oct 9, 2026

Copy link
Copy Markdown

Summary

parseTokenAmount is what ERC-20 fund and swap amounts go through before they are signed. A second decimal point ended the fraction, so 1.2.3 was signed as 1.2 USDC (1200000 base units at 6 decimals). An empty string was signed as zero. A negative string came back negative (-1.5 at 6 decimals is -500000).

Native transfers already reject those strings through parseEther. parseAmount in the CLI SDK already rejects them with the same decimal check. The token parser now uses that check.

Extra fractional digits are still truncated to the token's decimals, which is the behavior parseAmount tests already lock in.

The caller has not been given a checked integer yet. This parser is the check before the transfer is built.

Test plan

  • Companion wallet unit tests: 111 passed after npm run build
  • Removing the decimal check makes 1.2.3, -1.5, and "" return a bigint instead of throwing

parseTokenAmount treated a second decimal point as the end of the
fraction, so an ERC-20 fund or swap of 1.2.3 was signed as 1.2.
An empty amount was signed as zero, and a negative amount came back
negative. Native transfers already reject those strings. The token
parser now uses the same decimal check as parseAmount.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant