Show recipient address in send tx details

[BullishNode]

In the send transactions details screen, I can see the txid but not the recipient address. We should add that.

[BullishNode]

@claude discuss the implications and strategy to show the recipient address in the transaction details page when sending Bitcoin from either the Secure Bitcoin wallet or an imported external signer. Also discuss for the instant payments wallet, in this case showing the liquid address.

[claude]

Claude finished @BullishNode's task in 2m 54s —— View job

---

Analysis: Show Recipient Address in Transaction Details

I've completed a thorough analysis of the codebase to understand how recipient addresses can be displayed in transaction details across different wallet types.

---

Current State

Location: lib/features/transactions/ui/widgets/transaction_details_table.dart:125-135

The transaction details table already includes address display logic, but it's conditionally shown and has some gaps:

if (toAddress != null)
  DetailsTableItem(
    label:
        swap != null &&
                swap.receiveAddress != null &&
                swap.receiveAddress!.isNotEmpty
            ? context.loc.transactionDetailLabelRecipientAddress
            : context.loc.transactionDetailLabelAddress,
    displayValue: StringFormatting.truncateMiddle(toAddress),
    copyValue: toAddress,
  ),

The toAddress comes from:

final toAddress = swap?.receiveAddress ?? transaction?.toAddress;

And transaction?.toAddress is defined in transaction.dart:42 as:

String? get toAddress => walletTransaction?.toAddress ?? order?.toAddress;

---

Data Flow Analysis

1. Secure Bitcoin Wallet (On-chain)

Signer Types:

• Local signer (signer == SignerEntity.local): Seeds stored in app, signs locally
• Watch-signer (signer == SignerEntity.remote): External signers like hardware wallets (Coldcard, Jade, etc.)
• Watch-only (signer == SignerEntity.none): View-only wallets

Address Availability:

• ✅ Available: WalletTransaction.toAddress (line 70-74 in wallet_transaction.dart)
• Derived from destinationOutput?.address (line 57-68)
• For outgoing transactions: finds the first output where !output.isOwn
• For incoming transactions: finds the first output where output.isOwn
• For self-transfers: uses outputs.first

Current Display: ✅ Already shown when toAddress != null

Implications:

• Works identically for all signer types (local, remote, watch-only)
• The address is always available from transaction outputs
• No security or privacy concerns - addresses are public on the blockchain

---

2. Instant Payments Wallet (Liquid)

Network: Liquid (confidential transactions)

Address Availability:

• ✅ Available: Same as Bitcoin - WalletTransaction.toAddress
• Liquid uses confidential addresses (blinded)
• Address type: "Confidential Segwit" (line 124 in wallet.dart)

Current Display: ✅ Already shown when toAddress != null

Implications:

• Liquid addresses are longer than Bitcoin addresses
• Confidential transactions hide amounts/asset types on-chain, but addresses are still visible
• The StringFormatting.truncateMiddle() utility handles long addresses appropriately
• No special handling needed beyond what's already implemented

---

3. Swaps (Chain Swaps & Lightning)

Swap Types:

• Lightning to Bitcoin/Liquid (reverse swaps)
• Bitcoin/Liquid to Lightning (submarine swaps)
• Bitcoin ↔ Liquid (chain swaps)

Address Availability:

• ✅ Available: swap.receiveAddress (prioritized in line 75 of transaction_details_table.dart)
• For chain swaps: receives Bitcoin or Liquid address
• For submarine swaps to Lightning: receives Lightning invoice (not an address)

Current Display: ✅ Already shown with label "Recipient Address" for swaps

Implications:

• Lightning invoices vs addresses: The current code shows receiveAddress, which for Lightning swaps would be an invoice, not a traditional address
• Lightning invoices are much longer and contain the payment hash
• Label correctly distinguishes between "Recipient Address" (for swaps) and "Address" (for regular txs)

---

The Problem

Based on my analysis, recipient addresses ARE already being displayed in the transaction details table. However, there might be cases where toAddress is null:

Scenarios where address might not show:

1. Orders (Buy/Sell/Funding/Withdraw):

   • Currently shows order-specific information instead
   • order?.toAddress might not always be populated

2. Payjoin transactions:

   • No dedicated address field in the Payjoin entity
   • Falls back to walletTransaction?.toAddress

3. Pending/Unconfirmed transactions:

   • If transaction hasn't been broadcast yet, outputs might not be populated

4. Lightning swaps (submarine swaps):

   • receiveAddress contains a Lightning invoice, not a traditional address
   • Might be confusing to users if labeled as "address"

---

Recommendations & Strategy

Option 1: Ensure Address Always Shows (Recommended)

Goal: Make the address field always visible for wallet transactions

Changes needed:

1. Investigate why toAddress might be null for sent transactions
2. Add fallback logic to extract address from transaction outputs
3. Ensure proper labeling (especially for Lightning invoices vs addresses)

Files to modify:

• transaction_details_table.dart: Remove the if (toAddress != null) condition for outgoing transactions
• Add defensive checks and better error handling

Option 2: Improve Labeling & Context

Goal: Better communicate what's being shown

Changes needed:

1. Distinguish between:

   • "Recipient Address" - for sent Bitcoin/Liquid txs
   • "Receive Address" - for incoming txs
   • "Lightning Invoice" - for Lightning swaps
   • "Your Address" - for incoming txs

2. Add address type indicators:

   • Bitcoin (Native SegWit, Nested SegWit, Legacy)
   • Liquid (Confidential SegWit)
   • Lightning (Invoice/BOLT11)

Option 3: Enhanced Display for External Signers

Goal: Show signer information alongside address

Changes needed:

1. Display which signer/device was used
2. Show derivation path for the address
3. Helpful for users with multiple hardware wallets

Note: This is more complex and might be better suited for a separate feature

---

Questions for Clarification

1. Are addresses actually missing? Can you provide a screenshot or specific scenario where the recipient address doesn't show for a sent transaction?

2. Is this about improving the display (better labels, formatting) rather than missing data?

3. Should Lightning invoices be treated differently from regular addresses in the UI?

4. Do you want additional context like address type, derivation path, or signer information?

---

Implementation Complexity

• Low: If addresses are just not showing due to the if (toAddress != null) condition
• Medium: If we need to improve labeling and handle edge cases
• High: If we need to extract addresses from complex order/payjoin structures

Please provide more details about the specific scenario where addresses aren't showing, and I can implement the appropriate fix!

---