fix(runtime): read getBalance BigInt-safely — TronWeb's JSON.parse quantizes balances > 2ˆ53

[luiz-lvj]

Summary

stubProvider.getBalance returned balances via TronWeb's trx.getBalance, which parses the account JSON with a lossy JSON.parse. Any balance above 2^53 is quantized to the nearest IEEE-754 double — at a ~5e18 balance (a pre-funded signer) the ULP is 2^(62-52) = 1024 sun. So balance deltas smaller than ~1024 sun read as 0, even though the on-chain transfer happened.

This surfaced as OpenZeppelin's ERC2771Forwarder.executeBatch refunding a tiny value (10 sun) to a funded refundReceiver: the refund landed on-chain, but getBalance(refundReceiver) reported no change, so the test's balance == initial + refund assertion failed and the value looked "lost."

A value-magnitude sweep of the same refund confirms it's pure read-precision, not a transfer problem:

value	reported delta
10	0
1000	1024
1e6	1000448
1e9	999999488
1e12 / 1e15 / 1e18	exact

(1e12/1e15/1e18 are multiples of 1024, so they round-trip exactly; smaller, non-aligned values are rounded to the double ULP.)

Fix

Read balance out of the raw /wallet/getaccount response text (BigInt-exact) instead of going through TronWeb's lossy parser — the same >2^53 hazard wait.js's jsonParseBigSafe already avoids for transaction receipts.

Verification

Files

• src/runtime/ethers-bridge.js — getBalance reads /wallet/getaccount BigInt-safely.