fix(sdk-coin-polyx): forward decoded specVersion to v8 transfer builders in tryGetV8Builder - #9328
Merged
nvrakesh06 merged 1 commit intoJul 22, 2026
Conversation
Contributor
…ers in tryGetV8Builder tryGetV8Builder() now builds v8MaterialWithDecodedSpec from the decoded transaction bytes instead of using the static placeholder (specVersion 8000000). All four v8 transfer paths — V8TransferBuilder, V8HexTransferBuilder, V8TokenTransferBuilder, V8HexTokenTransferBuilder — receive .material(v8MaterialWithDecodedSpec) so createBaseTxInfo() encodes the live chain specVersion (e.g. 8000020) in the rebuilt signing payload. Without this fix verifySignature fails for any chain specVersion above 8000000 because the additional bytes in the rebuilt payload differ from the bytes the HSM signed. Adds a regression test that asserts signablePayload round-trips correctly when the factory is given a live material with specVersion 8000020. specVersion is present in signing payloads (unsigned) but not in signed extrinsics — falls back to v8Material.specVersion for signed txes so validateBaseFields does not throw. References: SI-1034 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
nvrakesh06
force-pushed
the
nvrakeshreddy/polyx-v8-token-withdrawal-routing
branch
from
July 22, 2026 15:45
c563e44 to
f2dc0ee
Compare
nvrakesh06
marked this pull request as ready for review
July 22, 2026 16:13
nayandas190
approved these changes
Jul 22, 2026
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
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.
Problem
tryGetV8Builder()inTransactionBuilderFactoryhardcodesutils.getV8Material()(staticspecVersion: 8000000) on all returned v8 builders. The live Polymesh chain is atspecVersion: 8000020.createBaseTxInfo()readsspecVersionfromthis._materialand encodes it in the signing payload's additional bytes — so any builder returned bytryGetV8Builderwithout a material override produces a rebuilt payload with wrong additional bytes, causingverifySignatureto fail even though the TSS signature is cryptographically valid.Root Cause
tryGetV8Builderdecoded the transaction against v8 metadata correctly, but then created builders without forwarding the decoded specVersion — always defaulting to the static placeholder. The analogous fix forgetV8BatchStakingBuilderwas done in SI-1034 on the decode-success path ingetBuilder(), but the four v8 transfer builders intryGetV8Builderwere missed.Fix
Build
v8MaterialWithDecodedSpecfrom the decoded transaction bytes:decodedTxn.specVersionis populated for signing payloads (unsigned txs) — the production path used bygetSignedTx/verifySignaturev8Material.specVersionfor signed extrinsics wheredecodeSignedTxdoesn't returnspecVersion, sovalidateBaseFieldsdoesn't throwAll four v8 transfer builders now receive
.material(v8MaterialWithDecodedSpec):V8TransferBuilderV8HexTransferBuilderV8TokenTransferBuilderV8HexTokenTransferBuilderRelationship to wallet-platform fix
A defensive wallet-platform fix (re-applying
.material(material)afterfactory.from()ingetSignedTx) is tracked in bitgo-microservices PR #61275. Both fixes arrive at the correct specVersion independently — having both is defense-in-depth with no conflict.Tests
Added regression test in
transactionBuilderFactory.tsthat:specVersion: 8000020TransactionBuilderFactory.from()with the same live materialsignablePayloadbyte-matches the originalAll 252 existing unit tests pass.
References: SI-1034