feat(sdk-coin-iota): support MPCv2 consolidation recovery

[bitgo-ai-agent-dev]

What

• Detect MPCv2 signing material once before IOTA consolidation scans.
• Derive the base destination with MPCv2-compatible EdDSA derivation.
• Thread the resolved MPCv2 route into each recovery call.

Why

• MPCv2 signed consolidations must sweep to the correct base address without
  decrypting the keycard once per scanned receive index.

Test plan

• git diff --check
• Run the IOTA unit tests (Nix dev shell dependency bootstrap failed in this environment).

Ticket: WCI-1235

[linear-code]

WCI-1235

[Marzooqa]

@claude

[github-actions]

Claude finished @Marzooqa's task —— View job

---

PR Review: MPCv2 Consolidation Recovery for IOTA

Todo List

• Read and analyze the main implementation file (iota.ts)
• Review the test changes
• Check for potential security issues
• Verify code quality and best practices
• Provide comprehensive review feedback

---

Code Review Feedback

✅ Implementation Overview

This PR successfully adds MPCv2 consolidation recovery support for IOTA by:

• Detecting MPCv2 signing material once before scanning addresses (line 484-487 in recoverConsolidations)
• Deriving the base destination address using MPCv2-compatible EdDSA derivation (line 490-492)
• Threading the resolved MPCv2 signing material into each recovery call (line 512)

✅ Key Improvements

1. Performance Optimization (Critical)

• Before: The keycard was decrypted on every loop iteration during consolidation scans
• After: MPCv2 signing material is detected once and reused (precomputedMaterial parameter)
• Impact: Significant performance improvement for consolidation operations

2. MPCv2 Integration

• Proper integration with the existing MPCv2 infrastructure (signEddsaMpcV2RecoveryTx)
• Maintains backward compatibility with MPCv1 signing paths
• Clean abstraction through protected methods (getEddsaSigningMaterial, signIotaMpcV2Recovery)

✅ Code Quality Assessment

Well-structured changes:

• Clean separation of concerns with helper methods
• Consistent parameter passing pattern
• Good error handling preservation
• Minimal surface area changes

Good practices:

• Maintains existing function signatures and behavior
• Proper type safety with EddsaSigningMaterial interface
• Clear documentation in method signatures

✅ Security Considerations

Secure keycard handling:

• The precomputedMaterial parameter properly threads signing material without re-decryption
• Maintains the same security model as existing recovery flows
• No credential exposure or logging issues detected

Validation preserved:

• All existing validation logic remains intact
• Error paths properly maintained
• No bypassing of security checks

✅ Test Coverage Analysis

Comprehensive test additions (88 new lines):

• MPCv2 recovery path validation (lines 734-775, 844-907)
• MPCv1 regression testing (lines 909-933) - Excellent safety measure
• MPCv2 consolidation tests (lines 1112-1176)
• Error case coverage (missing keys, mismatched keys)
• Signature validation using nacl.sign.detached.verify - Great verification

⚠️ Minor Observations

1. Parameter Threading Pattern
The precomputedMaterial parameter is added to multiple methods, which increases complexity but is necessary for the optimization. This is well-handled.

2. Method Signatures
The recover method signature change (adding optional precomputedMaterial) maintains backward compatibility.

3. Code Consistency
The implementation follows the same patterns used in other coins (DOT, SUI) for MPCv2 support, which is good for consistency.

✅ Testing Strategy Validation

Excellent test coverage:

• Both MPCv1 and MPCv2 code paths tested
• Regression tests ensure MPCv1 still works
• Error scenarios properly covered
• Real signature verification in tests adds confidence

Test quality:

• Uses proper mocking with sinon
• Validates actual cryptographic signatures
• Covers both signed and unsigned transaction paths

🎯 Recommendation: APPROVE

This is a well-implemented feature that:

1. Solves the stated problem: Avoids re-decrypting keycards during consolidation scans
2. Maintains security: No security regressions or credential exposure
3. Preserves compatibility: MPCv1 flows remain unchanged
4. Has comprehensive tests: Both positive and negative test cases
5. Follows established patterns: Consistent with other coin implementations

The performance improvement for MPCv2 consolidation operations will be significant, and the implementation is clean and safe.

---

Job run: View workflow run
Branch: WCI-1235-iota-mpcv2-consolidations

[vibhavgo]

lgtm