KarpelesLab / libwallet / 27023772732

22%

push

github

fix SPL transfer "Program failed to complete" + simulate CU limit + bump 0.4.55

A user trying to send 1.315764 USDT on 0.4.53 got back:

  Transaction simulation failed: Error processing Instruction 1:
  Program failed to complete

The mainnet trace was reproducible: ATA derivation correct, sender
ATA holds 1.315764 USDT, recipient address valid, mint healthy.
Replayed the exact tx in standalone Go against mainnet and watched
the program log — the ATA CreateIdempotent (instruction 1 once a
ComputeBudget SetLimit is prepended) consumed 15,018 CUs.

Root cause: `solanaDefaultCULimit = 1_000`, set in 0.4.x for a
basic SOL transfer (~200 CUs). 0.4.53 added the SPL path that
ALWAYS prepends an idempotent ATA Create (~15k CUs end-to-end —
allocate, init mint state, init owner). Any caller who opted into
priority (PriorityLevel set or ComputeUnitPrice non-zero) ended
up with cuLimit=1000 from `resolveSolanaPriority`, the program
hit the 1k ceiling mid-flight, and the RPC reported "Program
failed to complete" with no further detail.

Fix in two layers:

- Conservative SPL default (safety net). 30,000 CUs covers
  TransferChecked + ATA CreateIdempotent + Token-2022 fee
  instruction overhead with ~2x margin. Picked when simulation
  isn't available.

- Simulation-driven sizing (primary path). Before signing, build
  a draft message with a 200k cap, call simulateTransaction with
  sigVerify=false, read unitsConsumed, set the on-wire CB limit
  to that plus a 10%-or-+1000 headroom (the larger). Caps at
  Solana's per-tx 1.4M CU max; never lowers a caller-pinned
  limit. On RPC failure falls back to the conservative default.
  Same pattern Phantom and Solflare use.

For the user's exact tx: simulation says 15,273 CUs; we set the
CB limit to 16,800 instead of the broken 1,000. Verified live
against mainnet from a standalone test that constructs the same
bytes.

Tests pin the headroom math across boundary cases (tiny tx where
additive +1000 dominates, the user's e... (continued)

24 of 107 new or added lines in 3 files covered. (22.43%)

4310 of 19156 relevant lines covered (22.5%)

98.68 hits per line