fix(sdk-coin-flr): add getSignablePayload and addSignatureToTransaction for atomic txs#9358
Draft
bitgo-ai-agent-dev[bot] wants to merge 1 commit into
Draft
fix(sdk-coin-flr): add getSignablePayload and addSignatureToTransaction for atomic txs#9358bitgo-ai-agent-dev[bot] wants to merge 1 commit into
bitgo-ai-agent-dev[bot] wants to merge 1 commit into
Conversation
…ddSignatureToTransaction The FLR coin was missing getSignablePayload and addSignatureToTransaction overrides for atomic cross-chain transactions (C-chain to P-chain export, codec prefix 0x0000). The inherited EVM implementation from AbstractEthLikeCoin uses the EVM transaction builder which cannot parse Avalanche/Flare PVM/EVM atomic format, causing the TSS server-side signature injection step to fail for FLR→FLRP withdrawals. When signature injection fails, the server may retry building a new ExportInC with the same nonce as the already-pending transaction, resulting in "transaction attempted to double spend" from the blockchain. Fix: override getSignablePayload to route atomic txs (codec prefix 0000) to the FLRP atomic builder (getAtomicBuilder), which correctly parses the transaction and computes SHA-256(txBody) as the signable payload. Add addSignatureToTransaction to inject the TSS-produced signature into the unsigned atomic transaction to produce the final broadcastable hex. Both methods mirror the existing FLRP coin implementations but use getAtomicBuilder() (which wraps the FLRP builder) instead of the FLRP- internal getBuilder(). Ticket: CECHO-1784 Session-Id: e17e771f-ba61-468a-a77e-c2c97ade3e23 Task-Id: 81aaba89-3f88-4d30-a6f6-81d77b7908d9
Contributor
ralph-bitgo
Bot
force-pushed
the
fix/CECHO-1784-flr-atomic-tss-signing
branch
from
July 27, 2026 09:30
2e4fca5 to
fc4045f
Compare
bitgo-ai-agent-dev
Bot
force-pushed
the
fix/CECHO-1784-flr-atomic-tss-signing
branch
from
July 27, 2026 09:30
fc4045f to
bf8c700
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
What
getSignablePayloadoverride toFlrthat routes atomic cross-chain transactions (codec prefix0x0000) to the FLRP atomic builder, which correctly computes SHA-256(txBody) as the signing payloadaddSignatureToTransactionmethod toFlrthat injects a TSS-produced signature into an unsigned atomic ExportInC transaction to produce the final broadcastable hexWhy
When a FLR TSS wallet performs a C→P cross-chain withdrawal (FLR to FLRP), the ExportInC atomic transaction has codec prefix
0x0000. The FLR coin inheritedgetSignablePayloadfromAbstractEthLikeCoin, which uses the EVM transaction builder — but the EVM builder cannot parse Avalanche/Flare atomic transaction format.Without a proper
getSignablePayloadoverride, the server-side TSS signature injection step fails for FLR→FLRP withdrawals. When signature injection fails, the server may retry the withdrawal by building a new ExportInC transaction using the same C-chain address nonce as the already-pending transaction. The Flare node then rejects the duplicate as "transaction attempted to double spend."Adding
getSignablePayloadandaddSignatureToTransaction(mirroring the existing FLRP coin implementations, but usinggetAtomicBuilder()) gives the server the correct codec path for assembling signed atomic transactions, preventing the retry loop that causes the double spend.Test plan
getSignablePayloadreturns a 32-byte SHA-256 hash for atomic tx hexgetSignablePayloadreturns the same bytes as the FLRP builder'ssignablePayloadaddSignatureToTransactionproduces identical signed hex to the FLRP builder'ssign()methodTicket: CECHO-1784