feat(wallet)!: bind every approval to the gate's custody scope

R5: a PolicyAuthorizer now stamps a CustodyScope (profile index, plus the
configured wallet for a hot profile) onto every permission it mints, and
sign_approved refuses one minted by a different profile's gate. Without it a
host holding a hot gate for profile 0 and a signer for vault profile 1 could
route profile 1's spend through profile 0's gate: it auto-approves (the gate
judges outputs, never whose key owns the inputs) and profile 1's signer holds
the key, so the vault destination rule and clawback window never ran.

The two sides have genuinely different provenance -- the scope comes from the
host's persisted custody configuration at gate construction, the signer's from
the live master seed at sign time -- so this is a real comparison rather than
two derivations of one input.

Also: C4 routes the three gate-refusal tests through dig-account's own
derivation instead of the dependency's; C5 LF-normalizes the production/test
split so the structural invariants hold on a CRLF checkout; the summary
single-derivation invariant now tracks analyze(); and the confirm-twice
compile-fail fixture follows confirm_with.

Refs #1702

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

Author: MichaelTaylor3d

src/wallet/approval.rs

@@ -37,6 +37,7 @@ use dig_wallet_backend::types::TransactionSummary;
 use crate::auth::provider::{AuthProvider, SpendConfirmRequest, SpendDecision};
 use crate::error::{AccountError, Result};
 use crate::id::{AccountId, ProfileIx};
+use crate::wallet::policy::CustodyScope;
 use crate::wallet::summary::SpendSummary;
 
 /// The spends a ruling was made about, together with the single derivation made from them.
@@ -58,6 +59,9 @@ struct AuthorizedSpend {
     /// disagree shape this whole type exists to remove. What protects the caller is that `coin_spends`
     /// below is the same `Vec` the gate judged.
     verified: TransactionSummary,
+    /// WHOSE money the gate that minted this was configured to rule over, so the signer can refuse a
+    /// permission granted by some other profile's gate. See [`CustodyScope`].
+    scope: CustodyScope,
 }
 
 /// A spend the custody gate has PERMITTED, carrying the exact coin spends it permitted.
@@ -77,12 +81,14 @@ impl SpendApproval {
         coin_spends: Vec<CoinSpend>,
         summary: SpendSummary,
         verified: TransactionSummary,
+        scope: CustodyScope,
     ) -> Self {
         Self {
             inner: AuthorizedSpend {
                 coin_spends,
                 summary,
                 verified,
+                scope,
             },
         }
     }
@@ -102,6 +108,12 @@ impl SpendApproval {
     pub(crate) fn verified(&self) -> &TransactionSummary {
         &self.inner.verified
     }
+
+    /// The custody scope the minting gate was configured for. `pub(crate)`: the signer's admission
+    /// check, not a value a host reads.
+    pub(crate) fn scope(&self) -> &CustodyScope {
+        &self.inner.scope
+    }
 }
 
 /// A spend the custody gate would permit only with a human's agreement — the escalatable outcome.
@@ -119,12 +131,14 @@ impl PendingApproval {
         coin_spends: Vec<CoinSpend>,
         summary: SpendSummary,
         verified: TransactionSummary,
+        scope: CustodyScope,
     ) -> Self {
         Self {
             inner: AuthorizedSpend {
                 coin_spends,
                 summary,
                 verified,
+                scope,
             },
         }
     }
@@ -227,6 +241,16 @@ mod tests {
         }
     }
 
+    /// Any scope: these tests are about the ceremony's OUTCOME, not about admission, which is
+    /// enforced in the signer and tested in `policy.rs`/`authorizer.rs`.
+    fn scope() -> CustodyScope {
+        CustodyScope::new(
+            ProfileIx::ROOT,
+            &crate::wallet::policy::CustodyPolicy::Hot(Default::default()),
+            chia_protocol::Bytes32::new([0u8; 32]),
+        )
+    }
+
     fn summary() -> SpendSummary {
         SpendSummary::new(
             SpendTier::Confirm,
@@ -263,7 +287,7 @@ mod tests {
     /// from the same construction, so they cannot describe different spends.
     #[test]
     fn an_approval_exposes_the_spends_and_the_summary_it_was_built_from() {
-        let approval = SpendApproval::new(vec![coin_spend(99)], summary(), verified());
+        let approval = SpendApproval::new(vec![coin_spend(99)], summary(), verified(), scope());
         assert_eq!(approval.coin_spends(), &[coin_spend(99)]);
         assert_eq!(approval.summary().recipients[0].amount_mojos, 42);
         assert_eq!(approval.summary().fee, 7);
@@ -273,7 +297,7 @@ mod tests {
     /// spends, so these are the spends that become signable.
     #[test]
     fn confirming_a_pending_approval_yields_an_approval_over_the_very_same_spends() {
-        let pending = PendingApproval::new(vec![coin_spend(1234)], summary(), verified());
+        let pending = PendingApproval::new(vec![coin_spend(1234)], summary(), verified(), scope());
         assert_eq!(pending.summary().recipients[0].amount_mojos, 42);
 
         let approval = pending.decided(SpendDecision::Approve).unwrap();
@@ -284,7 +308,7 @@ mod tests {
     /// A decline is `UserDeclined` — terminal — not an escalatable refusal a caller could re-prompt.
     #[test]
     fn a_declined_ceremony_denies_outright_and_never_yields_an_approval() {
-        let pending = PendingApproval::new(vec![coin_spend(1)], summary(), verified());
+        let pending = PendingApproval::new(vec![coin_spend(1)], summary(), verified(), scope());
         let err = denial(pending.decided(SpendDecision::Decline(Some("not mine".into()))));
         assert!(
             matches!(&err, AccountError::UserDeclined(m) if m.contains("declined") && m.contains("not mine")),
@@ -295,7 +319,7 @@ mod tests {
     /// A decline with no stated reason is still a decline, and still denied.
     #[test]
     fn a_reasonless_decline_is_still_denied() {
-        let pending = PendingApproval::new(vec![coin_spend(1)], summary(), verified());
+        let pending = PendingApproval::new(vec![coin_spend(1)], summary(), verified(), scope());
         let err = denial(pending.decided(SpendDecision::Decline(None)));
         assert!(matches!(err, AccountError::UserDeclined(_)), "{err:?}");
     }

src/wallet/authorizer.rs

@@ -212,6 +212,7 @@ mod tests {
         let coin_spends = ctx.take();
 
         let gate = PolicyAuthorizer::new(
+            ProfileIx::ROOT,
             CustodyPolicy::Hot(HotWallet {
                 auto_send_limit: 10_000,
             }),
@@ -241,4 +242,150 @@ mod tests {
             "the signature is paired with the very spends the gate approved"
         );
     }
+
+    /// A spend of profile `ix`'s coins, paying `recipient`, ready for the gate.
+    ///
+    /// Built at the profile's OWN canonical puzzle hash, so the profile's signer genuinely controls
+    /// the coin — which is what makes the scope tests below able to fail for only one reason.
+    fn send_from_profile(ix: ProfileIx, recipient: chia_protocol::Bytes32) -> Vec<CoinSpend> {
+        use chia_puzzle_types::Memos;
+        use chia_wallet_sdk::driver::{SpendContext, StandardLayer};
+        use chia_wallet_sdk::types::Conditions;
+
+        let key = WalletKey::from_seed_at(&seed().master_seed()[..], ix);
+        let mut ctx = SpendContext::new();
+        let hint = ctx.hint(recipient).unwrap();
+        StandardLayer::new(key.public_key())
+            .spend(
+                &mut ctx,
+                chia_protocol::Coin::new(
+                    chia_protocol::Bytes32::new([1u8; 32]),
+                    key.puzzle_hash(),
+                    1_000,
+                ),
+                Conditions::new()
+                    .create_coin(recipient, 600, hint)
+                    .create_coin(key.puzzle_hash(), 390, Memos::None)
+                    .reserve_fee(10),
+            )
+            .unwrap();
+        ctx.take()
+    }
+
+    /// A gate ruling for `profile`, whose configured hot wallet is `profile`'s own wallet.
+    fn hot_gate_for(profile: ProfileIx) -> crate::wallet::enforcer::PolicyAuthorizer {
+        use crate::wallet::autosend::{AutoSendPolicy, OpClassLimits};
+        use crate::wallet::clock::FixedClock;
+        use crate::wallet::enforcer::PolicyAuthorizer;
+        use crate::wallet::policy::HotWallet;
+
+        let wallet = WalletKey::from_seed_at(&seed().master_seed()[..], profile);
+        PolicyAuthorizer::new(
+            profile,
+            CustodyPolicy::Hot(HotWallet {
+                auto_send_limit: 10_000,
+            }),
+            AutoSendPolicy {
+                enabled: true,
+                small_send: OpClassLimits::enabled_up_to(1_000),
+                period_cap_mojos: 1_000,
+                ..AutoSendPolicy::default()
+            },
+            &wallet.address().unwrap(),
+            Arc::new(FixedClock::new(1_800_000_000)),
+        )
+        .unwrap()
+    }
+
+    /// Approve `coin_spends` through `gate`, insisting on the auto-approved outcome.
+    fn auto_approved(
+        gate: &crate::wallet::enforcer::PolicyAuthorizer,
+        coin_spends: &[CoinSpend],
+    ) -> crate::wallet::approval::SpendApproval {
+        use crate::wallet::approval::SpendRuling;
+        use crate::wallet::autosend::SpendOpClass;
+        match gate.authorize_op(coin_spends, SpendOpClass::SmallSend) {
+            Ok(SpendRuling::Approved(approval)) => approval,
+            Ok(SpendRuling::RequiresConfirmation(_)) => panic!("a 610 mojo send is within bounds"),
+            Err(e) => panic!("the gate refused a legitimate send: {e}"),
+        }
+    }
+
+    /// **An approval minted by one profile's gate cannot be signed by another profile's signer.**
+    ///
+    /// The exploit this closes: profile 1 holds VAULT coins, so its spends are meant to face the vault
+    /// destination rule and the clawback window. A host that also holds an ordinary `Hot` gate for
+    /// profile 0 can route profile 1's spend through THAT gate instead — it auto-approves, because the
+    /// gate inspects only the spend's outputs and its own configuration, never the profile the input
+    /// coins belong to — and then sign with profile 1's signer, which does control those coins.
+    /// Hot-wallet treatment for vault money, with every advertised bound satisfied.
+    ///
+    /// The fixture is built so the scope check is the ONLY thing that can refuse: the coins are
+    /// profile 1's own, so profile 1's signer genuinely holds the key and the signature would
+    /// otherwise succeed. `a_gate_and_signer_for_the_same_profile_still_sign` is the control that
+    /// proves it.
+    #[test]
+    fn an_approval_minted_for_one_profile_is_refused_by_another_profiles_signer() {
+        use crate::wallet::money_signer::MoneySigner;
+
+        let coin_spends = send_from_profile(ProfileIx(1), chia_protocol::Bytes32::new([7u8; 32]));
+        let approval = auto_approved(&hot_gate_for(ProfileIx::ROOT), &coin_spends);
+
+        let vault_profile_signer =
+            WalletOps::new(seed(), ProfileIx(1), live()).money_signer(Network::Mainnet);
+        let err = vault_profile_signer
+            .sign_approved(approval)
+            .expect_err("a signer must refuse an approval another profile's gate minted");
+        assert!(
+            matches!(&err, crate::error::AccountError::PolicyDenied(m)
+                if m.contains("profile")),
+            "the refusal must name the mismatch, not a key failure: {err:?}"
+        );
+    }
+
+    /// The truthful control: same coins, same signer, gate scoped to the RIGHT profile — and it signs.
+    ///
+    /// Without this the test above proves nothing, because a signer for the wrong profile would also
+    /// fail simply by not holding the key. Here the key, the coins and the gate all agree, so the only
+    /// difference between the two tests is which profile the gate was built for.
+    #[test]
+    fn a_gate_and_signer_for_the_same_profile_still_sign() {
+        use crate::wallet::money_signer::MoneySigner;
+
+        let coin_spends = send_from_profile(ProfileIx(1), chia_protocol::Bytes32::new([7u8; 32]));
+        let approval = auto_approved(&hot_gate_for(ProfileIx(1)), &coin_spends);
+
+        let bundle = WalletOps::new(seed(), ProfileIx(1), live())
+            .money_signer(Network::Mainnet)
+            .sign_approved(approval)
+            .expect("a correctly-scoped approval must still sign");
+        assert_eq!(bundle.coin_spends, coin_spends);
+    }
+
+    /// **A relocked session stops signing, even through a signer built while it was live.**
+    ///
+    /// The approval is minted and the signer built BEFORE the lock, which is the whole hazard: the old
+    /// signer copied the seed at construction, so it kept signing forever and `lock()` was a hint. The
+    /// signer now observes the session, so revocation reaches it.
+    #[test]
+    fn a_signer_built_before_the_lock_refuses_after_it() {
+        use crate::wallet::money_signer::MoneySigner;
+
+        let coin_spends = send_from_profile(ProfileIx(1), chia_protocol::Bytes32::new([7u8; 32]));
+        let approval = auto_approved(&hot_gate_for(ProfileIx(1)), &coin_spends);
+
+        let residency = live();
+        let signer =
+            WalletOps::new(seed(), ProfileIx(1), residency.clone()).money_signer(Network::Mainnet);
+
+        residency.revoke();
+
+        let err = signer
+            .sign_approved(approval)
+            .expect_err("a signer must not outlive the unlock that produced it");
+        assert!(
+            matches!(err, crate::error::AccountError::Locked),
+            "a locked session is a named outcome, not a generic spend failure: {err:?}"
+        );
+    }
 }

src/wallet/enforcer.rs

@@ -66,10 +66,11 @@ use chia_protocol::{Bytes32, CoinSpend};
 use chia_wallet_sdk::utils::Address;
 
 use crate::error::{AccountError, Result};
+use crate::id::ProfileIx;
 use crate::wallet::approval::{PendingApproval, SpendApproval, SpendRuling};
 use crate::wallet::autosend::{AutoSendPolicy, SpendOpClass, MAX_LEDGER_ENTRIES};
 use crate::wallet::clock::Clock;
-use crate::wallet::policy::CustodyPolicy;
+use crate::wallet::policy::{CustodyPolicy, CustodyScope};
 use crate::wallet::summary::{DerivedSpend, SpendSummary, SpendTier};
 
 /// One auto-approved spend, recorded so the rolling period cap can be measured.
@@ -120,6 +121,9 @@ pub struct PolicyAuthorizer {
     /// the coin, whereas two address strings can differ (network prefix, casing) while naming the
     /// same key, and two identical strings cannot be compared at all if either fails to decode.
     hot_wallet_puzzle_hash: Bytes32,
+    /// WHOSE money this gate rules over, stamped onto every permission it mints so a signer for a
+    /// different profile refuses it. See [`CustodyScope`].
+    scope: CustodyScope,
     clock: Arc<dyn Clock>,
     /// Auto-approvals inside the current rolling window, oldest first.
     recent: Mutex<VecDeque<AutoSendRecord>>,
@@ -139,6 +143,7 @@ impl PolicyAuthorizer {
     /// here so an unusable value is a construction error rather than a comparison that silently never
     /// matches at authorization time.
     pub fn new(
+        profile: ProfileIx,
         custody: CustodyPolicy,
         auto_send: AutoSendPolicy,
         hot_wallet_address: &str,
@@ -150,6 +155,7 @@ impl PolicyAuthorizer {
             ))
         })?;
         Ok(Self {
+            scope: CustodyScope::new(profile, &custody, hot_wallet.puzzle_hash),
             custody,
             auto_send,
             hot_wallet_puzzle_hash: hot_wallet.puzzle_hash,
@@ -273,6 +279,7 @@ impl PolicyAuthorizer {
                 coin_spends.to_vec(),
                 derived.summary,
                 derived.verified,
+                self.scope,
             ))),
             CapVerdict::OverCap => self.escalate(coin_spends, derived),
         }
@@ -394,6 +401,7 @@ impl PolicyAuthorizer {
             coin_spends.to_vec(),
             derived.summary,
             derived.verified,
+            self.scope,
         )))
     }
 
@@ -445,7 +453,6 @@ enum CapVerdict {
 #[cfg(test)]
 mod tests {
     use super::*;
-    use crate::id::ProfileIx;
     use crate::keys::wallet_key::WalletKey;
     use crate::wallet::autosend::{OpClassLimits, DEFAULT_PERIOD_SECONDS};
     use crate::wallet::clock::{FixedClock, UnreadableClock};
@@ -460,6 +467,11 @@ mod tests {
     /// than whatever the wall clock happens to read.
     const NOW: u64 = 1_800_000_000;
 
+    /// The profile every gate in this module rules for. These tests exercise the gate's DECISIONS,
+    /// which do not depend on the index; the scope it stamps is exercised where it is enforced, in
+    /// `authorizer.rs` and `policy.rs`.
+    const GATE_PROFILE: ProfileIx = ProfileIx::ROOT;
+
     /// Comfortably above every per-transaction limit these tests configure, so a spend's TIER is
     /// decided by the custody policy while its APPROVAL is decided by the auto-send limits. If this
     /// were set at the auto-send limit instead, an over-limit spend would be refused by
@@ -627,6 +639,7 @@ mod tests {
     ) -> (PolicyAuthorizer, Arc<FixedClock>) {
         let clock = Arc::new(FixedClock::new(NOW));
         let gate = PolicyAuthorizer::new(
+            GATE_PROFILE,
             custody,
             auto_send,
             &hot_wallet().address().unwrap(),
@@ -1276,6 +1289,7 @@ mod tests {
     #[test]
     fn an_unreadable_clock_refuses_rather_than_assuming_an_empty_window() {
         let gate = PolicyAuthorizer::new(
+            GATE_PROFILE,
             hot_custody(),
             permissive_auto_send(),
             &hot_wallet().address().unwrap(),
@@ -1365,6 +1379,7 @@ mod tests {
     fn a_gate_cannot_be_built_on_an_undecodable_hot_wallet_address() {
         for address in ["", "nonsense", "xch1zzzz"] {
             let err = PolicyAuthorizer::new(
+                GATE_PROFILE,
                 hot_custody(),
                 permissive_auto_send(),
                 address,