fix(sdk-core,sdk-coin-xlm): fix enabletoken approval failing with no operations

[akarath]

Summary

• Approving a dual-approval Stellar enable-token (trustline) pending approval failed with transaction prebuild does not have any operations.
• recreateAndSignTransaction() rebuilds the tx during approval but didn't preserve verification.verifyTokenEnablement, so Xlm.verifyTransaction() fell through to the generic createAccount/payment check instead of the trustline verification path, and never recognized the changeTrust operation.
• verifyTokenEnablement is a coin-agnostic verification flag also used by near, sol, algo, hbar, and xrp to gate their own enabletoken verification branches, so this same gap affects those coins too, not just XLM.
• Fix: recreateAndSignTransaction() now sets verifyTokenEnablement when rebuilding an enabletoken pending approval, so it takes the correct verification path regardless of coin.

Fixes CSHLD-1358.

Test plan

• yarn lint clean on all changed files
• yarn prettier --check clean on all changed files
• Full monorepo tsc build clean
• sdk-coin-xlm unit tests: 108 passing
• sdk-core unit tests: 534 passing
• bitgo pendingApproval.ts unit tests: 18 passing (incl. 2 new tests). 1 pre-existing failing test ([tbtc] should recreate the transaction...) confirmed unrelated — reproduces identically with this fix reverted.

🤖 Generated with Claude Code

[linear-code]

CSHLD-1358

[akarath]

@claude review

[github-actions]

Claude finished @akarath's task —— View job

---

Code Review Complete ✅

Reviewing PR #9399: fix enabletoken approval failing with no operations

Todo List:

• Read and analyze changed files
• Review the core fix logic
• Evaluate test coverage and quality
• Check for code quality and best practices
• Provide comprehensive review feedback

---

Review Summary

This is a well-implemented fix for a critical multi-coin issue. The solution is elegant, targeted, and properly tested.

✅ Strengths

1. Root Cause Correctly Identified: The issue stems from recreateAndSignTransaction() not preserving the verifyTokenEnablement flag, causing XLM's verifyTransaction() to take the wrong verification path and throw "transaction prebuild does not have any operations".

2. Multi-Coin Impact Properly Addressed: The fix correctly identifies that this affects all coins using verifyTokenEnablement (XLM, NEAR, SOL, ALGO, HBAR, XRP), and the solution works for all of them since it's implemented at the SDK core level.

3. Minimal, Targeted Fix: The 8-line addition in pendingApproval.ts:339-346 is precisely what's needed:

   if (this.type() === 'enabletoken') {
     params.verification = params.verification || {};
     params.verification.verifyTokenEnablement = true;
   }

4. Excellent Test Coverage: The new tests comprehensively cover:

   • ✅ Positive case: verifyTokenEnablement is preserved for enabletoken transactions
   • ✅ Negative case: Flag is not added for non-enabletoken transactions
   • ✅ Proper mocking and verification of the flag propagation

5. Code Quality: Clean implementation following existing patterns, proper null-safety with params.verification || {}.

🔍 Technical Analysis

The Fix Logic (pendingApproval.ts:339-346):

• Correctly checks this.type() === 'enabletoken'
• Safely initializes params.verification if undefined
• Sets verifyTokenEnablement: true to ensure proper verification path
• Integrates seamlessly with existing parameter passing

XLM Verification Flow (confirmed in xlm.ts:416-417):

if (txParams.verification && txParams.verification.verifyTokenEnablement) {
  return this.verifyTokenEnablementTransaction(txParams, transactionJson);
}

Without the flag, it falls through to generic checks that throw the error at line 421.

Interface Change (iPendingApproval.ts): The whitespace-only change to the enabletoken type is cosmetic and acceptable.

🎯 Verification

• ✅ Fix addresses the exact error message from the issue
• ✅ Logic correctly routes enabletoken transactions to proper verification
• ✅ Tests validate both positive and negative scenarios
• ✅ Multi-coin architecture properly handled at SDK core level
• ✅ No breaking changes or side effects

💡 Minor Suggestions

1. Consider adding a JSDoc comment to explain why the verifyTokenEnablement flag is needed:

   // For enabletoken transactions, we need to set verifyTokenEnablement to ensure
   // the transaction takes the correct verification path during approval

   (Already included - good!)

2. Test Enhancement: Consider adding an integration test that reproduces the original error scenario, though the current unit tests are sufficient.

🎉 Conclusion

LGTM - This PR effectively fixes a critical issue affecting multiple blockchain integrations. The implementation is clean, well-tested, and addresses the root cause without introducing complexity or side effects. The comprehensive test plan execution and multi-coin consideration demonstrate thorough engineering.

Recommendation: ✅ Approve and merge

---

Job Run | Branch: cshld-1358/fix-xlm-enabletoken-approval