fix: convert a human amount to raw units without exponent notation

[ipezygj]

Before submitting this PR, please make sure:

• Your code builds clean without any errors or warnings
• You are using approved title ("feat/", "fix/", "docs/", "refactor/")

A description of the changes proposed in the pull request:

Fixes #622.

Math.floor(amount * Math.pow(10, decimals)).toString() prints "1e+21" once the raw amount reaches 1e21 — a thousand tokens with 18 decimals — and JSBI.BigInt and BigNumber.from both refuse that string, so a Uniswap CLMM open-position or add-liquidity of that size failed before it reached the chain, as the report describes. The float multiplication had also stopped being exact long before, from 2^53 raw units (about 9 tokens at 18 decimals).

The expression appeared 27 times across uniswap, pancakeswap, dflow, okx and titan, plus twice written with ** instead of Math.pow: in approximateBuyViaSellLeg, which every router BUY without ExactOut support goes through, and in Jupiter's quote. pancakeswap's CLMM add-liquidity had already moved to parseUnits, its siblings had not. All of them now go through one helper, toRawAmount(amount, decimals) in src/services/raw-amount.ts:

• the digits the caller typed are kept as text (String(n), the shortest round-trip form — toFixed was not used because it prints the binary expansion, (0.1).toFixed(18) ends in …006),
• expanded from exponent form on either side (1e-8, 1.5e21),
• cut to the token's decimals, which is the floor the old code applied, rather than the parseUnits(amount.toString()) throw on extra digits,
• and parseUnits does exact arithmetic on the string.

Behaviour for amounts the old code handled correctly is unchanged: the result is the same integer string.

Tests performed by the developer:

• New test/services/raw-amount.test.ts: 1000 at 18 decimals is 1000000000000000000000 and both big-int constructors accept it (the replaced expression yields 1e+21, asserted alongside); 0.1 and 1.1 at 18 decimals are exact; extra digits are cut, not refused; 1e-8 and 1.5e21 are expanded.
• New case in test/connectors/router-utils.test.ts: a BUY of 1000 of an 18-decimal token hands the sell leg 1000000000000000000000, not 1e+21.
• test/connectors/{uniswap,pancakeswap,dflow,okx,titan,jupiter} and router-utils: 165 passed. pnpm typecheck, eslint and prettier clean on the changed files.

Tips for QA testing:

Repeat the report: gateway lp uniswap/clmm add-liquidity (or POST /trading/clmm/open-position) with an amount whose raw value exceeds 1e21, e.g. 1000 of an 18-decimal token. Before: Cannot convert 1e+21 to a BigInt. After: the position opens with the intended amount. A small swap quote through any of the five connectors should return the same raw amount as before.

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; the prior BUY approximation defect is fixed and no new actionable failures remain.

Findings

1.  BUY conversion remains broken ▶

Summary

This PR centralizes conversion of human-readable token amounts into exact raw-unit integer strings and applies it across router, AMM, and CLMM connectors.

• Expands exponent-form numbers before converting them to raw units.
• Avoids floating-point multiplication and exponent notation that downstream big-integer parsers reject.
• Updates shared BUY approximation so DFlow, OKX, Titan, and Jupiter fallback routes use the corrected conversion.
• Adds focused tests for large, fractional, exponent-form, and excess-precision amounts.
• The previously reported BUY conversion gap is fully fixed by routing approximateBuyViaSellLeg through toRawAmount.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    A[Human token amount] --> B[toRawAmount]
    B --> C[Expand exponent notation]
    C --> D[Truncate to token decimals]
    D --> E[parseUnits exact conversion]
    E --> F[Raw integer string]
    F --> G[Router, AMM, or CLMM SDK]

Loading

_{Reviews (2) · Last reviewed commit: "fix: the BUY approximation and the Jupit..."}

[greptile-apps]

BUY conversion remains broken

This conversion only covers the SELL branch. DFlow BUY requests use approximateBuyViaSellLeg, which still converts the amount with Math.floor(baseAmount * 10 ** decimals).toString(). A BUY of 1000 units of an 18-decimal token therefore produces "1e+21" instead of a raw integer string and can fail before returning a route. Titan BUY requests have the same problem, as does OKX when ExactOut falls back to approximation.

Knowledge Base Used:

• Routing and aggregator connectors
• Swap quote and execution