fix(scripts): scale token amounts without a floating-point intermediary

[Nexory]

What

The Solana bridge and SPL mint CLI handlers scale the user-entered amount with a floating-point intermediary:

const scaledAmount = BigInt(Math.floor(args.amount * Math.pow(10, decimals)));

args.amount is a parseFloat-ed number (from the Zod .transform((val) => parseFloat(val))), and amount * 10 ** decimals is evaluated in IEEE-754 double precision. That loses accuracy for ordinary decimal inputs.

Why it is wrong

1.005   SOL  (9 decimals):  Math.floor(1.005 * 1e9)  = 1_004_999_999   (want 1_005_000_000, off by 1 lamport)
1.000001 USDC (6 decimals): Math.floor(1.000001 * 1e6) = 1_000_000      (want 1_000_001, trailing unit dropped)
1.005   ETH  (18 decimals): 1.005 * 1e18 exceeds Number.MAX_SAFE_INTEGER -> arbitrary trailing precision lost

1.005 * 1e9 evaluates to 1004999999.9999999, so Math.floor rounds it down. The on-chain amount ends up smaller than what the user typed. The magnitude is small for 9/6-decimal tokens (one smallest-unit), but for 18-decimal (wei) values any amount past ~15-16 significant digits loses precision because the product exceeds Number.MAX_SAFE_INTEGER.

Fix

Add a small parseTokenAmount(value, decimals) helper backed by viem's parseUnits (already a dependency), which parses the decimal string directly with no float intermediary, and use it at all six call sites:

• bridge-sol, bridge-sol-with-bc, bridge-spl, bridge-wrapped-token
• bridge-call (ETH -> wei)
• spl/mint

The amount / value Zod fields now keep the validated string instead of transforming to a float, so the raw decimal input reaches parseUnits intact. Logging is unchanged (the field is still a string). parseUnits truncates over-precision inputs the same way the previous Math.floor did, so no input that worked before changes behavior.

Verification (local)

$ bun test src/internal/amount.test.ts
 3 pass  0 fail  7 expect() calls

The test documents the legacy float loss (1.005 @ 9 -> 1_004_999_999) and pins the corrected output (-> 1_005_000_000).

$ tsc --noEmit        # whole scripts package
 0 errors

Notes

• This is a correctness fix; the per-transaction value difference is small for 9/6-decimal tokens, larger only for high-precision 18-decimal inputs.
• CI does not currently run the TypeScript scripts package (the workflows cover the Forge and Solana programs), so the verification above was run locally. Happy to wire a bun test / tsc step into CI for scripts in a follow-up if useful.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[cb-heimdall]

Review Error for mohamedelhalosy2023-stack @ 2026-06-22 00:23:27 UTC
User failed mfa authentication, see go/mfa-help

[cb-heimdall]

Review Error for mohamedelhalosy2023-stack @ 2026-06-22 10:04:01 UTC
User failed mfa authentication, see go/mfa-help

[cb-heimdall]

Review Error for mohamedelhalosy2023-stack @ 2026-06-22 19:10:37 UTC
User failed mfa authentication, see go/mfa-help

[FernLovesCrypto]

Good catch on the Math.floor(amount * 10**decimals) precision loss. One thing worth double-checking before this is called fixed: the Zod schema upstream still does .transform((val) => parseFloat(val)) on args.amount. If that transform runs before the value reaches parseTokenAmount, the amount has already been round-tripped through an IEEE-754 double before parseUnits ever sees it — so for high-precision 18-decimal inputs specified with many significant digits, precision could be lost at the parsing stage even after the scaling math itself is fixed.
Might be worth changing the schema to keep args.amount as a raw string (skip parseFloat entirely) and let parseTokenAmount/parseUnits do the only numeric parsing, so there's a single code path handling precision rather than two. Also flagging in case there isn't one already: a unit test with an amount that has more significant digits than a double can represent (e.g. 1.123456789012345678 for an 18-decimal token) would pin this down and prevent a future regression from reintroducing a float round-trip.

[cb-heimdall]

Review Error for mohamedelhalosy2023-stack @ 2026-07-04 11:02:43 UTC
User failed mfa authentication, see go/mfa-help

[Nexory]

Thanks for taking a look @FernLovesCrypto ! I think this is reading the pre-change schema. The PR actually removes the .transform((val) => parseFloat(val)), so amount (and value) stay as the original string. The .refine(...) only validates: its callback returns a boolean and never replaces the parsed value, so there is no float round-trip before parseTokenAmount. parseTokenAmount then passes the string straight to viem's parseUnits, which parses the decimal exactly.

The high-precision case is already covered in amount.test.ts: parseTokenAmount("1.005", 18) returns 1005000000000000000n (18-decimal wei, above Number.MAX_SAFE_INTEGER, still exact), next to a test documenting the old inline-float precision loss. So the single-string path is what this already does. Happy to add more cases if any input looks under-covered.