feat: Derive fiat order sourceAmount from on-chain tx data

[OGPoyraz]

Explanation

Currently, the fiat submit flow derives sourceAmountRaw from order.cryptoAmount - a human-readable value reported by the on-ramp provider. This value may not precisely reflect what was actually received on-chain.

This PR reads the actual transferred amount from the completed on-chain transaction (order.txHash) instead. For native tokens, the amount is taken from tx.value. For ERC-20 tokens, the amount is decoded from the transfer(address,uint256) call data. If the on-chain read fails or the transaction hash is missing, the existing order.cryptoAmount derivation is used as a fallback.

The implementation introduces:

• getTransferredAmountFromTxHash - a generic utility in utils/transaction-receipt.ts that reads transferred amounts from any on-chain transaction (native or ERC-20). Takes explicit chainId and tokenAddress params for reusability.
• resolveSourceAmountRaw - a fiat-strategy-specific function in strategy/fiat/utils.ts that orchestrates the on-chain read with order.cryptoAmount fallback.
• getRawSourceAmountFromOrderCryptoAmount - the existing decimal-shift conversion, moved from fiat-submit.ts to strategy/fiat/utils.ts and renamed for clarity.

References

• Related to the fiat strategy submit flow introduced in feat: Implement FiatStrategy submit flow with order polling and relay execution #8347

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Medium Risk
Changes how fiat submission computes sourceAmountRaw by reading on-chain transaction data via RPC, which can impact relay quoting/submission correctness and adds new failure modes around provider reads and ERC-20 calldata decoding.

Overview
Fiat submit now derives the relay sourceAmountRaw from the completed order’s on-chain transaction (order.txHash) when available, falling back to decimal-shifting order.cryptoAmount if the read fails or yields no amount.

This introduces a reusable getTransferredAmountFromTxHash utility to read native tx.value or decode ERC-20 transfer(address,uint256) calldata, refactors the prior cryptoAmount conversion into getRawSourceAmountFromOrderCryptoAmount, and updates/expands unit tests plus the package changelog accordingly.

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

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 0a7e13c. Configure here.}

[cursor]

ERC-20 path ignores tokenAddress, no tx.to verification

Medium Severity

getTransferredAmountFromTxHash accepts a tokenAddress parameter but, for ERC-20 tokens, never verifies that tx.to matches this address. It only uses tokenAddress to pick the native-vs-ERC-20 path. If the order.txHash points to a transfer call on a different ERC-20 contract, the function silently decodes and returns that unrelated amount. Because this is described as a generic reusable utility, callers may reasonably assume tokenAddress scopes the result to the intended token.

 

^{Reviewed by Cursor Bugbot for commit 0a7e13c. Configure here.}