[MEDIUM] BigInt-to-Number precision loss in display formatting across 5 files

[v1ktorrr0x]

Severity: Medium

Source

Multiple files:

• useLpPositions.ts:213: Number(lpBalanceRaw)
• DepositWithdrawPanel.tsx:253: Number(previewShares)
• LpPositionDashboard.tsx:48,53,144: Number(userRedeemableValue), Number(vaultBalance), Number(redemptionRateE6)
• PositionsDock.tsx:181: Number(pnlTokens)

Description

Number(bigint) silently loses precision for values exceeding Number.MAX_SAFE_INTEGER (~9e15). For USDC (6 decimals) this is safe up to ~9 billion USD. For tokens with 9+ decimals, the safe range shrinks to ~9 million. The conversions produce wrong display values with no indication of precision loss.

At current playground TVL levels this is cosmetic, but there is no precision awareness anywhere in the codebase.

Fix

For amounts that could theoretically exceed the safe range, compute with BigInt arithmetic and convert to Number only at the final display step with explicit documentation of the safe ceiling. At minimum, add a sentinel guard: if the value exceeds Number.MAX_SAFE_INTEGER, display a truncation indicator rather than a wrong number.

[dcccrypto]

Confirmed still live — keeping open. All three cited sites remain:

app/hooks/useLpPositions.ts:260  const lpBalance = Number(lpBalanceRaw) / Math.pow(10, lpMintDecimals);
app/hooks/useLpPositions.ts:271  (Number(lpBalanceRaw) / totalLpSupply) * 100
app/components/earn/DepositWithdrawPanel.tsx:367  ((Number(previewShares) / Number(lpSupply + previewShares)) * 100)

Not fixed here because the right remedy differs per site: a percentage display can tolerate the precision loss, whereas a balance shown to the user should stay in BigInt and format at the edge. Picking per site is a product call.

[dcccrypto]

FIXED and merged in PR #2535. Closing.

bigintToFloat and bigintRatio now guard the conversions, and the five named sites use them — PositionsDock PnL, LpPositionDashboard redeemable value, useLpPositions balance / redeemable / share.

Your framing of the risk is what set the shape of the fix:

The conversions produce wrong display values with no indication of precision loss.

So the helper returns null, not 0. Returning 0 would be worse than the bug: a wrong large number at least looks suspicious, whereas a confident 0 reads as a real balance. Callers render the placeholder they already render for missing data.

Three details a naive guard would have missed

• It checks the RAW base-unit magnitude, before the decimal divide. Dividing first hides the loss — (MAX+1)/1e6 is small and finite, but the precision is already gone. Your own note that the safe range shrinks with decimals is exactly why this ordering matters.
• It guards the negative side. A large loss is as easy to hit as a large gain, and raw > MAX alone lets it through.
• bigintRatio scales inside bigint arithmetic, so a huge numerator over a huge denominator still yields an exact small quotient. LpPositionDashboard's redeemable value is precisely that shape — converting each side to a float first would lose it before the division.

On your severity note

At current playground TVL levels this is cosmetic, but there is no precision awareness anywhere in the codebase.

The second half was the accurate part, and it turned out to be slightly overstated: usePortfolio and PositionsDock already carried MAX_SAFE_INTEGER comments in nearby code. The awareness existed in prose but not in a reusable helper — which is the same failure as #2246, where the conversion was inlined eight times so the one place that could grow a guard was eight places that could not. Both are closed by the same PR.

Negative control: removing the two checks fails 3 of the 11 new tests; the other 8 pin that ordinary values still convert, so it cannot be satisfied by returning null for everything.

Launch suite: 3149 passed / 16 skipped / 0 failed.