fix(solana): derive the omitted compute-unit limit instead of assuming the cap

When a transaction carries no SetComputeUnitLimit, the runtime requests
200,000 compute units per non-ComputeBudget instruction, capped at 1,400,000 --
it does not request the cap unconditionally. Assuming the cap could not
understate the fee, but it overstated it badly: a transfer alongside a
unit-price instruction is charged on 200,000 CUs and the device displayed
seven times that as the "Maximum priority fee".

Deriving the limit keeps the no-understatement property, because it is exactly
what the runtime will charge, and makes the screen describe the transaction
actually being signed.

The test that pinned the old rule is updated. It now covers the realistic
1-instruction case and the cap, which SOL_MAX_INSTRUCTIONS (8) lets a
transaction reach exactly with seven non-budget instructions -- so the clamp
stays as defence rather than as a reachable path.

Author: pastaghost

lib/firmware/solana.c

@@ -799,17 +799,34 @@ void solana_formatTokenAmount(char* buf, size_t len, uint64_t amount,
   snprintf(buf, len, "%llu.%s %s", (unsigned long long)whole, frac_str, symbol);
 }
 
+/* Solana's own default when a transaction carries no SetComputeUnitLimit:
+   200,000 compute units per non-ComputeBudget instruction, capped at
+   1,400,000. See the runtime's compute_budget_processor. */
+#define SOL_DEFAULT_CU_PER_INSTRUCTION 200000u
+#define SOL_MAX_CU_LIMIT 1400000u
+
+static bool solana_isComputeBudgetInstruction(uint8_t type) {
+  return type == SOL_INSTR_COMPUTE_BUDGET_HEAP_FRAME ||
+         type == SOL_INSTR_COMPUTE_BUDGET_UNIT_LIMIT ||
+         type == SOL_INSTR_COMPUTE_BUDGET_UNIT_PRICE ||
+         type == SOL_INSTR_COMPUTE_BUDGET_LOADED_ACCOUNTS_SIZE;
+}
+
 bool solana_calculatePriorityFee(const SolanaParsedTx* tx, uint64_t* fee_out,
                                  bool* has_fee) {
   const uint64_t divisor = 1000000u;
   uint64_t price = 0;
-  uint64_t limit = 1400000u;
+  uint64_t limit = 0;
   bool seen_price = false;
   bool seen_limit = false;
+  uint64_t non_budget_instructions = 0;
   *has_fee = false;
 
   for (uint8_t i = 0; i < tx->num_instructions; i++) {
     const SolanaParsedInstruction* pi = &tx->instructions[i];
+    if (!solana_isComputeBudgetInstruction((uint8_t)pi->type)) {
+      non_budget_instructions++;
+    }
     if (pi->type == SOL_INSTR_COMPUTE_BUDGET_UNIT_PRICE) {
       if (seen_price) return false;
       seen_price = true;
@@ -820,6 +837,21 @@ bool solana_calculatePriorityFee(const SolanaParsedTx* tx, uint64_t* fee_out,
       limit = pi->extra_value;
     }
   }
+
+  if (!seen_limit) {
+    /* Not the 1,400,000 cap.
+     *
+     * Assuming the cap whenever SetComputeUnitLimit was absent overstated the
+     * screen badly: a transfer plus a unit-price instruction is charged on
+     * 200,000 CUs, and the device showed seven times that as the "Maximum
+     * priority fee". It is an upper bound, so nothing was ever understated --
+     * but a maximum the runtime will never reach is not the transaction's
+     * maximum, and this release line is about screens that describe the thing
+     * being signed. num_instructions is a uint8_t, so this cannot overflow. */
+    limit = non_budget_instructions * SOL_DEFAULT_CU_PER_INSTRUCTION;
+    if (limit > SOL_MAX_CU_LIMIT) limit = SOL_MAX_CU_LIMIT;
+  }
+
   if (!seen_price || price == 0) return true;
 
   uint64_t whole = price / divisor;

unittests/firmware/solana.cpp

@@ -666,14 +666,38 @@ TEST(Solana, PriorityFeeCalculationIsRoundedAndOverflowSafe) {
   EXPECT_TRUE(has_fee);
   EXPECT_EQ(fee, 70000000ULL);
 
-  /* No explicit limit uses the protocol maximum so the displayed liability
-     cannot understate the fee. */
-  tx.num_instructions = 1;
-  tx.instructions[0].type = SOL_INSTR_COMPUTE_BUDGET_UNIT_PRICE;
-  tx.instructions[0].extra_value = 2000000;
+  /* With no explicit limit, use the limit the RUNTIME will request: 200,000
+     compute units per non-ComputeBudget instruction, capped at 1,400,000.
+
+     This replaces an earlier rule that assumed the 1,400,000 cap whenever
+     SetComputeUnitLimit was absent. That could not understate the fee, but it
+     overstated it badly -- a transfer alongside a unit-price instruction is
+     charged on 200,000 CUs and was shown as seven times that. Deriving the
+     limit still cannot understate what the runtime charges, because it is
+     exactly what the runtime charges. */
+  memset(&tx, 0, sizeof(tx));
+  tx.num_instructions = 2;
+  tx.instructions[0].type = SOL_INSTR_SYSTEM_TRANSFER;
+  tx.instructions[1].type = SOL_INSTR_COMPUTE_BUDGET_UNIT_PRICE;
+  tx.instructions[1].extra_value = 2000000;
+  ASSERT_TRUE(solana_calculatePriorityFee(&tx, &fee, &has_fee));
+  EXPECT_TRUE(has_fee);
+  EXPECT_EQ(fee, 400000ULL); /* 2 lamports/CU * 1 * 200,000 CUs */
+
+  /* Seven non-budget instructions reach the 1,400,000 cap exactly, which is
+     also the most SOL_MAX_INSTRUCTIONS (8) allows alongside a price
+     instruction. The clamp stays as defence rather than as a reachable path. */
+  memset(&tx, 0, sizeof(tx));
+  tx.num_instructions = 8;
+  for (int i = 0; i < 7; i++)
+    tx.instructions[i].type = SOL_INSTR_SYSTEM_TRANSFER;
+  tx.instructions[7].type = SOL_INSTR_COMPUTE_BUDGET_UNIT_PRICE;
+  tx.instructions[7].extra_value = 2000000;
   ASSERT_TRUE(solana_calculatePriorityFee(&tx, &fee, &has_fee));
   EXPECT_TRUE(has_fee);
-  EXPECT_EQ(fee, 2800000ULL);
+  EXPECT_EQ(fee, 2800000ULL); /* capped: 2 * 1,400,000 */
+
+  memset(&tx, 0, sizeof(tx));
 
   tx.num_instructions = 2;
   tx.instructions[0].type = SOL_INSTR_COMPUTE_BUDGET_UNIT_LIMIT;