fix(sdk-coin-flrp): update address index computation and signing logic in txn builders #7990
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary: FLRP Signature Index Bug Fix
The Bug
Problem: P-chain import/export transactions for FLRP were failing on-chain with "wrong signature" errors, while identical AVAXP transactions succeeded.
Root Cause: The FlareJS library's
pvm.e.newImportTx/pvm.e.newExportTxmethods usematchOwners()internally to determinesigIndices(signature positions). When all 3 wallet addresses were passed to FlareJS,matchOwners()would select different signature indices than intended, causing a mismatch between:Example of the mismatch:
The Fix
Solution: Pass only the 2 intended signing addresses to FlareJS builders, not all 3 wallet addresses.
Key Changes:
getSigningAddresses()method - Added toatomicTransactionBuilder.tsto determine the correct 2 signers:Updated transaction builders (
ImportInPTxBuilder.ts,ExportInPTxBuilder.ts,ImportInCTxBuilder.ts):newImportTx/newExportTxmatchOwners()now correctly selects the 2 signers from the UTXO's address listChange output fix (
ExportInPTxBuilder.ts):C-chain import fee (
ImportInCTxBuilder.ts):baseTxFeeis correctly applied for EVM gas costsHow It Works in Production
Signing Flow (User signs first, BitGo signs second):
On-Chain Verified Transactions
These transactions were built with the fix and accepted on Flare Coston2 testnet:
bgHnEJ64td8u31aZrGDaWcDqxZ8vDV5qGd7bmSifgvUnUW8v2nSBwNcgfLbk5S425b1qaYaqTTCiMCV75KU4Fbnq8SPUUqLq22t4gxEAdPLiiy9HsbjaQun1mVFewMoixNS64eZ56C38L4mpP1jsigIndices [0, 2] meaning:
3094db9d...sorts first)c20336a9...sorts third)This matches the expected signing pair (User + BitGo) for normal transactions.