fix(wallet): refuse a spend whose input coin amounts do not sum in a u64

Found while delete-probing the guards: dig-wallet-backend 0.16 accumulates the spent
coins' amounts with an unchecked `+=` (client/verify.rs:153). Those amounts come from an
unsigned skeleton a dapp supplies, so they are attacker-chosen and need not name coins
that exist — an unsummable input total therefore PANICS in a debug build and WRAPS in a
release build, after which the wrapped figure is what value conservation is checked
against. Refusing it here as PolicyIndeterminate makes that unreachable.

Also merge the rolling-cap's two overflow checks into the one that is reachable: the
window's own total could only overflow if two recorded charges summed past u64::MAX,
which the projection check already prevents from ever being recorded, so that half could
never fire and no test could hold it.

Co-Authored-By: Claude <noreply@anthropic.com>

Author: MichaelTaylor3d

probe.sh

@@ -0,0 +1,50 @@
+#!/usr/bin/env bash
+# Delete-probe each guard: neutralize it, run the suite, restore. Red = the guard is load-bearing.
+set -u
+cd "$(dirname "$0")"
+
+probe() {
+  local name="$1" file="$2" from="$3" to="$4"
+  cp "$file" /tmp/probe.bak
+  python3 - "$file" "$from" "$to" <<'PY'
+import io,sys
+p,a,b=sys.argv[1],sys.argv[2],sys.argv[3]
+s=io.open(p,encoding='utf-8').read()
+if a not in s:
+    print("PATTERN-MISS"); sys.exit(3)
+io.open(p,'w',encoding='utf-8',newline='').write(s.replace(a,b,1))
+PY
+  if [ $? -ne 0 ]; then echo "$name :: PATTERN-MISS"; cp /tmp/probe.bak "$file"; return; fi
+  out=$(cargo test 2>&1)
+  failed=$(echo "$out" | sed -n '/^failures:$/,$p' | grep -oE "^    [a-z_][a-z_0-9:]*$" | tr -d ' ' | sort -u | tr '\n' ' ')
+  if echo "$out" | grep -q "test result: FAILED"; then
+    verdict="RED -> $failed"
+  elif ! echo "$out" | grep -q "test result:"; then
+    verdict="INCONCLUSIVE (the mutation itself did not compile)"
+  else
+    verdict="GREEN - VACUOUS"
+  fi
+  echo "$name :: $verdict"
+  cp /tmp/probe.bak "$file"
+}
+
+E=src/wallet/enforcer.rs
+S=src/wallet/summary.rs
+A=src/wallet/approval.rs
+
+probe "G7  an undeclared intent escalates" $E   'self.auto_send.configured_limits(op_class)'   'self.auto_send.configured_limits(match op_class {
+            SpendOpClass::Undeclared => SpendOpClass::Tip,
+            declared => declared,
+        })'
+
+probe "G2  custody total is CHECKED, not saturating" $S   'let native_total_mojos = summary.checked_native_total_mojos()?;'   'let native_total_mojos = summary.native_total_mojos();'
+
+probe "G19 input coin amounts must sum in a u64" $S   'coin_spends
+        .iter()
+        .try_fold(0u64, |sum, spend| sum.checked_add(spend.coin.amount))
+        .ok_or_else(|| {'   'coin_spends
+        .iter()
+        .try_fold(0u64, |sum, spend| Some(sum.wrapping_add(spend.coin.amount)))
+        .ok_or_else(|| {'
+
+probe "G13 the rolling projection is checked, not wrapped" $E   '.try_fold(total, |sum, record| sum.checked_add(record.mojos))'   '.try_fold(total, |sum, record| Some(sum.wrapping_add(record.mojos)))'

src/wallet/enforcer.rs

@@ -322,18 +322,22 @@ impl PolicyAuthorizer {
 
         recent.retain(|record| record.at_unix.saturating_add(self.auto_send.period_seconds) > now);
 
-        let already: u64 = recent.iter().try_fold(0u64, |sum, record| {
-            sum.checked_add(record.mojos).ok_or_else(|| {
+        // ONE checked accumulation, starting from this spend, rather than summing the window and then
+        // adding to it. The two-step form had an unreachable half: the window's own total can only
+        // overflow if two recorded charges sum past `u64::MAX`, which the projection check below
+        // already prevents from ever being recorded — so that guard could never fire, and a guard that
+        // cannot fire is a guard no test can hold. Folded together, the single remaining check IS
+        // reachable (a `u64::MAX` charge under a `u64::MAX` cap, then one mojo more).
+        let projected = recent
+            .iter()
+            .try_fold(total, |sum, record| sum.checked_add(record.mojos))
+            .ok_or_else(|| {
                 AccountError::PolicyIndeterminate(
-                    "the auto-send ledger total overflows u64".to_string(),
+                    "this spend plus the rolling period total overflows u64, so the cap cannot be \
+                     evaluated"
+                        .to_string(),
                 )
-            })
-        })?;
-        let projected = already.checked_add(total).ok_or_else(|| {
-            AccountError::PolicyIndeterminate(
-                "this spend plus the period total overflows u64".to_string(),
-            )
-        })?;
+            })?;
 
         if projected > self.auto_send.period_cap_mojos {
             return Ok(CapVerdict::OverCap);
@@ -455,6 +459,26 @@ mod tests {
         ctx.take()
     }
 
+    /// Two wallet-owned input coins, each paid straight out to a hinted third party.
+    ///
+    /// A multi-coin fixture is the only shape whose INPUT total can exceed a single coin's `u64`, so it
+    /// is the only one that can exercise the input-summability guard.
+    fn two_coin_spend(first: u64, second: u64) -> Vec<CoinSpend> {
+        let recipient = third_party().puzzle_hash();
+        let mut ctx = SpendContext::new();
+        for (parent, amount) in [([1u8; 32], first), ([2u8; 32], second)] {
+            let hint = ctx.hint(recipient).unwrap();
+            StandardLayer::new(spender().public_key())
+                .spend(
+                    &mut ctx,
+                    Coin::new(Bytes32::new(parent), spender().puzzle_hash(), amount),
+                    Conditions::new().create_coin(recipient, amount, hint),
+                )
+                .unwrap();
+        }
+        ctx.take()
+    }
+
     /// A spend paying `amount` to a third party with no fee — the workhorse fixture.
     fn pays_third_party(amount: u64) -> Vec<CoinSpend> {
         spend_paying(&[(third_party().puzzle_hash(), amount)], 0)
@@ -1411,4 +1435,58 @@ mod tests {
             "the signer must refuse un-hinted value leaving the wallet: {err}"
         );
     }
+
+    /// A coin-spend set whose INPUT amounts do not sum in a `u64` is refused rather than judged.
+    ///
+    /// This is the guard over `dig-wallet-backend` 0.16's unchecked input accumulation
+    /// (`client/verify.rs:153`): without it this very fixture panics in a debug build and, in a release
+    /// build, has its input total WRAP — after which the wrapped figure is what value conservation is
+    /// checked against. The amounts come from an unsigned skeleton a dapp supplies, so they are
+    /// attacker-chosen and need not name coins that exist.
+    ///
+    /// The truthful control matters here more than usual: the same two-coin shape at halved amounts
+    /// sums fine and is judged normally, so what follows is the SUM being unrepresentable and not the
+    /// gate refusing multi-coin spends.
+    #[test]
+    fn a_spend_whose_input_amounts_do_not_sum_in_a_u64_is_refused_rather_than_wrapped() {
+        let gate = gate_with(hot_custody(), permissive_auto_send());
+
+        let err =
+            refusal(gate.authorize_op(&two_coin_spend(u64::MAX, u64::MAX), SpendOpClass::Tip));
+        assert!(
+            matches!(&err, AccountError::PolicyIndeterminate(m) if m.contains("sum in a u64")),
+            "an unsummable input total must be indeterminate, and say so: {err}"
+        );
+
+        // Control: two coins whose amounts DO sum are judged on their merits.
+        let judged = gate.authorize_op(&two_coin_spend(1_000, 2_000), SpendOpClass::Tip);
+        assert!(
+            !matches!(&judged, Err(AccountError::PolicyIndeterminate(_))),
+            "the same two-coin shape must be judgeable when its total is representable"
+        );
+    }
+
+    /// The rolling ledger's projection is checked, so a charge that would push the window total past
+    /// `u64::MAX` is indeterminate rather than wrapped into a small, comfortably-under-cap number.
+    ///
+    /// Reachable only under a `u64::MAX` cap, which is why the fixture uses one: charge the whole
+    /// `u64::MAX` allowance, then ask for one mojo more.
+    #[test]
+    fn a_charge_that_would_overflow_the_rolling_total_is_indeterminate_not_wrapped() {
+        let gate = gate_with(
+            CustodyPolicy::Hot(HotWallet {
+                auto_send_limit: u64::MAX,
+            }),
+            permissive_auto_send(),
+        );
+
+        approval(gate.authorize_op(&pays_third_party(u64::MAX), SpendOpClass::Tip));
+        assert_eq!(ledger_total(&gate), u64::MAX);
+
+        let err = refusal(gate.authorize_op(&pays_third_party(1), SpendOpClass::Tip));
+        assert!(
+            matches!(&err, AccountError::PolicyIndeterminate(m) if m.contains("overflows u64")),
+            "the projection must refuse rather than wrap to 0: {err}"
+        );
+    }
 }

src/wallet/summary.rs

@@ -177,7 +177,29 @@ impl SpendSummary {
 /// This is the crate's ONE call into [`derive_summary`]: value conservation, quote-form delegated
 /// puzzles and the sole-`AGG_SIG_ME` rule are checked here, so a spend the driver cannot fully account
 /// for is refused before any custody decision — and before any signature — exists.
+///
+/// # Why the input amounts are summed first
+///
+/// `dig-wallet-backend` 0.16's `derive_summary` accumulates the spent coins' amounts with an unchecked
+/// `+=` (`client/verify.rs:153`), so a coin-spend set whose INPUT amounts do not sum in a `u64` panics
+/// in a debug build and WRAPS in a release build — and a wrapped input total is compared against the
+/// outputs to decide value conservation. The amounts come from an unsigned skeleton, which a dapp
+/// supplies, so they are attacker-chosen and need not correspond to coins that exist. Refusing an
+/// unsummable input total here keeps that reachable from nowhere: the answer is
+/// [`PolicyIndeterminate`](AccountError::PolicyIndeterminate), because a spend whose inputs cannot be
+/// totalled is not forbidden — it simply cannot be judged.
 fn derive_verified(coin_spends: &[CoinSpend]) -> Result<TransactionSummary> {
+    coin_spends
+        .iter()
+        .try_fold(0u64, |sum, spend| sum.checked_add(spend.coin.amount))
+        .ok_or_else(|| {
+            AccountError::PolicyIndeterminate(
+                "the spent coins' amounts do not sum in a u64, so this spend's value cannot be \
+                 accounted for"
+                    .to_string(),
+            )
+        })?;
+
     derive_summary(coin_spends)
         .map_err(|e| AccountError::Spend(format!("cannot derive spend summary: {e}")))
 }
@@ -204,6 +226,21 @@ impl DerivedSpend {
     /// Fail-closed at each step: an unaccountable spend is refused by the verify gate, and one whose
     /// native amounts cannot be summed in a `u64` is [`PolicyIndeterminate`](AccountError::PolicyIndeterminate)
     /// rather than clamped to `u64::MAX` and then tiered as though the clamp were its value.
+    ///
+    /// # The checked sum here cannot currently fail, and is kept anyway
+    ///
+    /// [`derive_verified`] refuses a spend whose INPUT amounts do not sum in a `u64`, and the verify
+    /// gate then requires value conservation, so the outputs plus the fee equal a figure that already
+    /// fits — the native total is bounded before this line runs. A delete-probe confirms it: swapping
+    /// [`checked_native_total_mojos`](SpendSummary::checked_native_total_mojos) for the saturating
+    /// accessor turns no test red.
+    ///
+    /// It stays because the bound rests on a DEPENDENCY's conservation check rather than on anything
+    /// this crate can see. If that check is ever relaxed, narrowed, or bypassed for a new spend shape,
+    /// the honest answer to "what is this spend worth" must become a refusal — never `u64::MAX` quietly
+    /// standing in for a number nobody computed. This is the one guard in the custody path that is
+    /// deliberately retained without a test able to hold it, and it is called out rather than left for
+    /// a reader to discover.
     pub(crate) fn derive(coin_spends: &[CoinSpend], policy: &CustodyPolicy) -> Result<Self> {
         let verified = derive_verified(coin_spends)?;
         // Tiered `Confirm` first — the stricter of the two hot tiers, so a bug that skipped the