fix(sdk-coin-xtz): verify destination and amount in verifyTransaction

[bitgo-ai-agent-dev]

What

• Xtz.verifyTransaction now decodes txPrebuild.txHex and compares the encoded destination address and transfer amount against txParams.recipients[0]
• Added rejection when the transaction cannot be decoded (fail-closed behaviour)
• Added rejection when the prebuild output count is not exactly 1
• No behaviour change when no recipients or no txHex are present (wallet initialisation)

Why

• A compromised prebuild service could redirect an XTZ transfer to an attacker-controlled address while the local signer signed it silently, because verifyTransaction previously only checked that the recipient count was ≤ 1 and returned true unconditionally
• The multisig contract validates signatures over the payload, but if the payload already encodes an attacker-chosen destination, the on-chain check does not protect the user
• This fix ensures the locally-verified intent (destination + amount from txParams.recipients) matches the bytes that will actually be signed and broadcast

Test plan

• should verify a valid transaction where destination and amount match — passes for a matching prebuild
• should reject when prebuild destination does not match requested recipient — catches address redirection
• should reject when prebuild amount does not match requested recipient — catches amount manipulation
• should reject when the prebuild contains an unexpected number of outputs — catches unexpected multi-output builds
• should reject when the prebuild cannot be decoded — fail-closed on corrupt/invalid txHex
• should pass when no recipients are specified — backward-compatible for wallet-init flows
• should pass when no txHex is present in the prebuild — backward-compatible for wallet-init flows
• All 114 existing unit tests pass (yarn run unit-test --scope @bitgo/sdk-coin-xtz)

Ticket: CSHLD-838

[linear-code]

CSHLD-838

[prajwalu142]

@claude review this pr for potential regressions and provide verdict

[github-actions]

Claude finished @prajwalu142's task —— View job

---

Review of PR: fix(sdk-coin-xtz): verify destination and amount in verifyTransaction

Todo List:

• Read and analyze the main implementation changes in xtz.ts
• Review the test changes in xtz.ts test file
• Assess potential regressions and breaking changes
• Evaluate security improvements
• Provide final verdict

Analysis

The PR introduces security verification logic to the verifyTransaction method in the XTZ coin implementation. The changes decode transaction hex and validate that the encoded destination address and amount match the requested recipient parameters.

Key Changes in Implementation:

• Lines 132-164: New validation logic that decodes txPrebuild.txHex using TransactionBuilder
• Compares decoded destination address and amount against txParams.recipients[0]
• Fail-closed behavior: throws errors on decode failures or mismatches
• Only activates when both recipient and txHex are present

Test Coverage:

• 7 new comprehensive test cases covering all validation scenarios
• Tests both positive cases (matching destination/amount) and negative cases (mismatches, decode failures)
• Backward compatibility tests for empty recipients and missing txHex

Potential Regressions Assessment

✅ LOW RISK - The implementation follows a careful backward-compatibility approach:

1. Conditional Activation: The new validation only runs when recipient && txPrebuild?.txHex - preserving existing behavior for wallet initialization flows
2. Early Return Pattern: Maintains the original return true for cases without recipients or txHex
3. Error Boundaries: Uses try-catch for transaction decoding with descriptive error messages

No Breaking Changes Identified:

• Existing wallet initialization flows (no recipients/txHex) continue to work
• Single recipient transactions continue to work if destination/amount match
• Multi-recipient rejection logic remains unchanged

Security Improvements

✅ SIGNIFICANT SECURITY ENHANCEMENT:

1. Address Redirection Protection: Prevents attackers from redirecting funds by comparing decoded destination with requested recipient
2. Amount Manipulation Prevention: Validates that the actual transfer amount matches the requested amount
3. Fail-Closed Design: Invalid/corrupted txHex results in rejection rather than silent approval
4. Single Output Validation: Ensures prebuilds contain exactly one output as expected

The fix addresses a critical vulnerability where a compromised prebuild service could redirect transfers while signatures validate correctly.

Code Quality

✅ HIGH QUALITY IMPLEMENTATION:

• Proper error handling with descriptive messages
• Uses existing BigNumber utilities for amount comparison
• Consistent code style with existing patterns
• Comprehensive test coverage (86 new test lines)
• Clear comments explaining the security logic

Verdict

🟢 APPROVED - RECOMMEND MERGE

This is a well-implemented security fix that:

• ✅ Addresses a genuine security vulnerability
• ✅ Maintains backward compatibility
• ✅ Has comprehensive test coverage
• ✅ Uses fail-closed security principles
• ✅ No regression risk identified

The implementation is conservative, well-tested, and provides significant security value without breaking existing functionality.

[Ranjna-G]

not really sure if the last two cases are valid, please check and confirm