fix(transaction-pay-controller): convert exchange rate numbers to strings before passing to BigNumber

[OGPoyraz]

Explanation

Fixes a crash in transaction-pay-controller caused by BigNumber throwing when receiving a JavaScript number with more than 15 significant digits.

Root Cause

BigNumber enforces a strict 15 significant digit limit on number inputs — both in the constructor (new BigNumber(number)) and in math methods (.multipliedBy(number), .times(number), .plus(number), etc.) — because IEEE 754 floats lose precision beyond that.

In getTokenFiatRate (token.ts), three raw number values from external sources are passed directly to BigNumber:

// tokenToNativeRate: number — from marketData[chainId][address].price
// nativeToUsdRate: number — from CurrencyRateController state
// nativeToFiatRate: number — from CurrencyRateController state

const usdRate = new BigNumber(tokenToNativeRate ?? 1)   // ❌ constructor
    .multipliedBy(nativeToUsdRate)                       // ❌ method arg
    .toString(10);

const fiatRate = new BigNumber(tokenToNativeRate ?? 1)   // ❌ constructor
    .multipliedBy(nativeToFiatRate)                      // ❌ method arg
    .toString(10);

When does this crash?

Case 1: Large conversion rate (weak-currency locales like VND, IDR)

new BigNumber(40115252.21304121)     // ❌ 16 significant digits → THROWS
new BigNumber("40115252.21304121")   // ✅ string input → no limit

// .multipliedBy() also validates:
bn.multipliedBy(40115252.21304121)   // ❌ THROWS
bn.multipliedBy("40115252.21304121") // ✅ no limit

Case 2: Very precise small price (micro-cap tokens)

new BigNumber(0.00000123456789012345)  // ❌ 17 significant digits → THROWS
new BigNumber("0.00000123456789012345") // ✅ string input → no limit

Case 3: Near-peg stablecoin with API floating point noise

new BigNumber(1.0000000000000002)    // ❌ 17 significant digits → THROWS
new BigNumber("1.0000000000000002")  // ✅ string input → no limit

Real user state logs confirm CurrencyRateController stores values exceeding 15 significant digits for weak-currency locales:

"currencyRates": {
  "ETH": { "conversionRate": 40115252.21304121 },
  "BNB": { "conversionRate": 11259865.090939905 }
}

This happens because CurrencyRateController.boundedPrecisionNumber uses toFixed(9) which bounds decimal digits, not significant digits. For large numbers, 8+ integer digits + 9 decimal digits = 17+ significant digits.

The Fix

Wrap all three values in String() before passing to BigNumber. BigNumber's string constructor and string method arguments have no precision limit.

getTokenFiatRate is the single entry point where raw number values from CurrencyRateController and marketData enter the transaction-pay-controller. Everything downstream operates on FiatRates ({ fiatRate: string, usdRate: string }), so fixing this one function protects the entire controller.

Related

• Extension fix: fix: convert exchange rate numbers to strings before passing to BigNumber metamask-extension#42674
• Upstream root cause: CurrencyRateController.boundedPrecisionNumber should use toPrecision(15) instead of toFixed(9) (separate issue for @metamask/assets-controllers)

Changelog

@metamask/transaction-pay-controller

• Fixed: Crash when exchange rate numbers exceed 15 significant digits by converting to strings before passing to BigNumber

---

Note

Low Risk
Low risk, localized change to exchange-rate arithmetic that only alters input coercion to BigNumber to prevent runtime exceptions; outputs remain string rates.

Overview
Prevents transaction-pay-controller crashes when fiat/exchange rates exceed BigNumber’s 15-significant-digit limit by coercing tokenToNativeRate, nativeToUsdRate, and nativeToFiatRate to strings before BigNumber construction/multiplication in getTokenFiatRate.

Updates the package changelog to document the fix.

^{Reviewed by Cursor Bugbot for commit 1ec802c. Bugbot is set up for automated code reviews on this repo. Configure here.}