fix(sdk-coin-trx): fix BANDWIDTH transaction signature mismatch

[abhijit0943]

Fix protobuf3 serialization mismatch for TRON BANDWIDTH transactions.

Problem:

• BitGoJS explicitly encoded resource=BANDWIDTH (value 0) in protobuf
• TRON node re-serializes transactions and omits default values per protobuf3
• Different bytes → different txID → signature mismatch (SIGERROR)

Solution:

• Omit resource field when it's BANDWIDTH (the default value = 0)
• Update decode functions to treat missing resource as BANDWIDTH
• Add comprehensive round-trip tests for BANDWIDTH serialization

Files changed:

• freezeBalanceTxBuilder.ts: omit resource field for BANDWIDTH
• unfreezeBalanceTxBuilder.ts: omit resource field for BANDWIDTH
• delegateResourceTxBuilder.ts: omit resource field for BANDWIDTH
• undelegateResourceTxBuilder.ts: omit resource field for BANDWIDTH
• utils.ts: handle missing resource as BANDWIDTH in decode functions

Ticket: SC-5030

[Doddanna17]

Great fix for the BANDWIDTH transaction signature mismatch issue! I did a thorough review of the implementation and it looks solid.

Problem Understanding

The root cause was a protobuf3 serialization mismatch:

• BitGoJS explicitly encoded resource=BANDWIDTH (value 0)
• TRON nodes omit default values per protobuf3 spec when re-serializing
• Different bytes led to different transaction IDs, causing SIGERROR

Implementation Review

Encoding Changes (4 builders):
All transaction builders now conditionally omit the resource field:

if (this._resource !== 'BANDWIDTH') {
  rawContract.resource = this._resource;
}

This matches TRON node behavior and ensures consistent transaction hashes.

Decoding Changes (utils.ts):
Decode functions properly handle missing resource fields:

const resourceValue = !delegateResourceContract.resource ? TronResource.BANDWIDTH : TronResource.ENERGY;

Code Quality:

• Consistent pattern across all 4 transaction builders
• Clear comments explaining the protobuf3 rationale
• TypeScript types properly updated to optional fields
• Follows established protobuf3 patterns

Test Coverage

The new test suite is comprehensive with 16 tests total (4 per builder):

• Round-trip BANDWIDTH transactions (ensures resource is preserved)
• Round-trip ENERGY transactions (regression test)
• Transaction ID consistency (critical for signature verification)
• Signing after round-trip (validates full workflow)

Each test verifies that transactions can be serialized, deserialized, and re-serialized while maintaining consistent transaction IDs and resource values.

Safety Analysis

No Breaking Changes:

• Public API remains unchanged
• ENERGY transactions continue to work as before
• Existing code can use the fix transparently
• Backward compatible with all TRON node versions

Security:

• No new attack vectors introduced
• Aligns with official protobuf3 specification
• Matches TRON node behavior exactly

Performance:

• Negligible impact (slightly fewer bytes for BANDWIDTH)
• No measurable performance difference

Minor Suggestion (Optional)

Consider making the decode logic more explicit for future resource types:

// Current (works but assumes only 2 resource types)
const resourceValue = !contract.resource ? TronResource.BANDWIDTH : TronResource.ENERGY;

// Alternative (more explicit)
const resourceValue = contract.resource === 1 ? TronResource.ENERGY : TronResource.BANDWIDTH;

This would handle hypothetical future resource types more gracefully, though TRON has only had BANDWIDTH and ENERGY for years.

Priority: LOW - Not blocking, just a future-proofing consideration.

Recommendation

This fix is well-designed, thoroughly tested, and critical for TRON staking operations. Ready to merge.

Ticket: SC-5030

[lokesh-bitgo]

Approved based on codeowners