Skip to content

Commit 428b60d

Browse files
refactor(key-wallet): wire ManagedCoreKeysAccount into the collection (#742)
* refactor(key-wallet): wire ManagedCoreKeysAccount into the collection Promotes the dead-code `ManagedCoreKeysAccount` introduced in #711 into the active type for accounts that derive special-purpose keys but don't track funds. Cuts ~10 keys-only accounts per wallet from carrying always-empty `balance` / `utxos` / `spent_outpoints` state. Storage split on `ManagedAccountCollection`: - Identity, asset-lock, and provider fields move from `ManagedCoreFundsAccount` → `ManagedCoreKeysAccount`. - Standard, CoinJoin, and DashPay fields stay on `ManagedCoreFundsAccount`. New borrowed enum `ManagedAccountRef<'a> { Funds, Keys }` (and mutable counterpart `ManagedAccountRefMut<'a>`) plus owned `OwnedManagedCoreAccount`. Spanning collection accessors (`get_by_account_type_match`, `all_accounts`, …) return the borrowed enum. The enum delegates the funds-agnostic surface (transactions, monitor revision, address-pool helpers, record/confirm transaction) so most callers don't need to dispatch on the variant; funds- only operations (`as_funds()`, `as_funds_mut()`) require an explicit unwrap. `ManagedCoreKeysAccount` gains the methods needed to be a first-class participant in transaction matching: - `record_transaction` / `confirm_transaction` (no UTXO/balance work) - `check_transaction_for_match`, `check_asset_lock_transaction_for_match`, and the four `check_provider_*_key_in_transaction_for_match` variants - `classify_address` / `check_provider_payout` helpers `wallet/managed_wallet_info` accessors that returned `&mut ManagedCoreFundsAccount` for identity / asset-lock / provider accounts now return `&mut ManagedCoreKeysAccount`. Funds-only surfaces (`account_balances`, `update_balance`, `mark_instant_send_utxos`, matured-coinbase / immature) filter to the funds variant. `ManagedAccountCollection::insert` accepts either variant via `OwnedManagedCoreAccount`; explicit `insert_funds` / `insert_keys` helpers are exposed for callers that statically know the variant. `get`, `get_mut`, `remove`, `contains_key` now scope to the funds-bearing index lookup (Standard BIP44/32 + CoinJoin) — keys accounts use type-keyed accessors. C ABI preserved on the FFI side. `FFIManagedCoreAccount` now wraps an internal `Funds | Keys` enum carrying an `Arc<…>`, with new `as_funds` / `as_keys` / `keys_account` accessors and a `new_keys` constructor. Funds- only entry points (`get_balance`, `get_utxo_count`) gracefully return defaults on the keys variant; trait-shared entry points (`get_network`, `get_account_type`, address-pool getters, transactions) work on both. Variant-aware constructors are wired through `managed_wallet_get_account`, `managed_wallet_get_top_up_account_with_registration_index`, and the per-type collection getters. This is a clean replay of the work from PR #716 on the current architecture (the original branch carried merge noise from unrelated discarded branches and depended on pre-#711 / pre-#733 struct layouts that no longer exist). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(key-wallet-ffi): rustdoc + regenerate FFI_API.md - Drop intra-doc links to private `FFIManagedCoreAccountInner` variants on `keys_account()` so `cargo doc -D warnings` (and the Documentation CI job) passes; the enum is internal and doesn't need to appear in public rustdoc. - Regenerate `key-wallet-ffi/FFI_API.md` to pick up the updated descriptions on `managed_core_account_get_balance` / `_get_utxo_count` (the verify-ffi pre-commit hook). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(key-wallet-ffi): include all account variants in managed_wallet_get_account_count The count was only summing standard / coinjoin / identity_registration / identity_topup buckets — every other variant `managed_wallet_get_account` can return (identity_topup_not_bound, identity_invitation, asset-lock, provider, dashpay, platform-payment) was excluded. Pre-existing miscount, made more visible by the keys-account split now exposing those getters through the variant-aware FFI surface. `provider_operator_keys` (BLS) and `provider_platform_keys` (EdDSA) are feature-gated on the immutable `AccountCollection` and counted only when the corresponding feature is enabled. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(key-wallet): add `all_funding_accounts(_mut)` and drop in-loop `as_funds()` filters Five funds-only callsites in `wallet_info_interface.rs` were iterating `all_accounts()` and filtering each ref via `as_funds()` / `as_funds_mut()` inside the loop body — pure noise, since balance / UTXO state only ever lives on Standard / CoinJoin / DashPay accounts. Add focused accessors on `ManagedAccountCollection`: - `all_funding_accounts(&self) -> Vec<&ManagedCoreFundsAccount>` - `all_funding_accounts_mut(&mut self) -> Vec<&mut ManagedCoreFundsAccount>` Migrate `account_balances`, `utxos`, `update_balance`, `immature_transactions`, and `matured_coinbase_records` to use them. `monitored_addresses`, `transaction_history`, `monitor_revision`, and `mark_instant_send_utxos` keep using `all_accounts(_mut)` — they legitimately span both variants. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(key-wallet): rename insert_{funds,keys} -> insert_{funds,keys}_bearing_account `insert_funds` / `insert_keys` were ambiguous about *what* "funds" or "keys" referred to. The longer names make the variant intent explicit and match the surrounding "funds-bearing" / "keys-only" terminology already used in the doc comments and field comments. The generic `insert(impl Into<OwnedManagedCoreAccount>)` keeps its name — that's the variant-agnostic entry point. No public callers existed outside this file (verified via grep across key-wallet, key-wallet-ffi, key-wallet-manager, dash-spv) so this is a local rename with no downstream impact. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(key-wallet): simplify keys-account `record_transaction` to its real semantics The keys-account `record_transaction` was carrying three branches that are statically unreachable on the keys-account data model: - `change_addrs` — for non-Standard `CoreAccountTypeMatch` variants, `involved_change_addresses()` is always `&[]`. Identity / asset-lock / provider accounts own a single address pool with no external/internal split, so the `OutputRole::Change` arm can never match. - `OutputRole::Sent` — gated on `has_inputs = account_match.sent > 0`, but the keys-account `check_transaction_for_match` sets `sent = 0` unconditionally (keys accounts don't track per-account UTXOs, so there's no signal that they contributed inputs). - `direction = Internal | Outgoing` — both gated on `has_inputs`, same dead-branch reason. A keys account always sees direction `Incoming` (or `CoinJoin` for the unlikely-but-possible case where the upstream classifier flagged a CoinJoin tx that touched a keys-account address). Drop the dead branches, rename `receive_addrs` → `owned_addrs` (no receive/change distinction exists for these account types), and document the actual semantics on the method's doc comment. Behavior is preserved — the previous code happened to compute the right answer through dead arms; the new code expresses it directly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(key-wallet): make keys-account `record_transaction` a thin marker Keys-account flows (identity registration, asset lock, provider-key registration / update) are typically funded from a Standard or CoinJoin account in the same wallet. The funding account's `record_transaction` already populates `input_details` (from its UTXO set) and `output_details` (classified receive / change / sent), so the keys-account record reproducing them would double-count and risk drifting out of sync if the classification logic changes. Treat the keys-account record as the thin marker it really is: "this tx involved this keys account" plus `net_amount`, and nothing more. - `direction = TransactionDirection::Internal` — from the wallet's perspective, the tx moves funds from one of its accounts to another. - `input_details = Vec::new()` — already correct (keys accounts don't track per-account UTXOs). - `output_details = Vec::new()` — the funding account's record carries the per-output classification. Drop the now-unused `OutputDetail` / `OutputRole` / `Address` imports and gate the `HashSet` import behind the same feature flag as `finalized_txids`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(key-wallet): cover special-tx → keys-account matching paths end-to-end For each special-transaction type that drives one of the new keys-account `check_*_for_match` methods on `ManagedCoreKeysAccount`, construct a transaction and assert `ManagedWalletInfo::check_core_transaction` flags the right `AccountTypeToCheck`. 13 tests in `tests/special_transaction_matching_tests.rs`: - AssetLockPayloadType → 6 tests covering each of the keys-account variants (Identity{Registration, TopUp, TopUpNotBound, Invitation}, AssetLock{Address, Shielded}TopUp). - ProviderRegistrationPayloadType → 4 tests, one per provider-key match field (owner_key_hash, voting_key_hash, operator_public_key (BLS), platform_node_id (EdDSA)). The BLS / EdDSA tests are feature-gated the same way the matching impls are. - ProviderUpdateRegistrarPayloadType → 2 tests (voting + operator key changes). - 1 test pinning the keys-account `TransactionRecord` shape: direction Internal, empty input/output details (the post-PR thin-marker contract). Skipped on purpose: - AssetUnlock / Coinbase — match Standard, not the keys-only variants. - QuorumCommitment — no key/address fields the wallet matches against. - ProviderUpdateRevocation — payload has no key-hash / pubkey field for matching. Also fixes a real PR-introduced bug surfaced by writing the IdentityTopUp test: `add_managed_account` / `add_managed_account_from_xpub` always constructed `ManagedCoreFundsAccount` regardless of the account type, then relied on `insert()` accepting it — which now correctly errors for keys-only types after the variant split. The fix dispatches via a small `owned_from_account` helper that picks the right variant, and the BLS / EdDSA paths (always ProviderOperatorKeys / ProviderPlatformKeys, both keys-only) drop their `ManagedCoreFundsAccount::from_*_account` calls in favor of `ManagedCoreKeysAccount::from_*_account`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(key-wallet): keep `from_account_collection` field-direct insertions The earlier refactor in this PR routed every `from_account_collection` case through `managed_collection.insert(managed_account)` where `managed_account` was an `OwnedManagedCoreAccount`. That swapped 14 trivial field-typed inserts (e.g. `standard_bip44_accounts.insert(*index, managed)`) for 14 generic-insert calls — each having to carry a `.expect()` for an invariant the old code never had to articulate. Restore the field-direct shape: - `create_managed_account_from_account_type` (returned the owned enum) is renamed to `build_managed_account_type` and returns the inner [`ManagedAccountType`]. That's the actual shared work — building the address pools. - Per-variant thin wrappers wrap it as the right concrete type: - `create_managed_funds_account_from_account` → `ManagedCoreFundsAccount` - `create_managed_keys_account_from_account` → `ManagedCoreKeysAccount` - `create_managed_keys_account_from_bls_account` (ProviderOperatorKeys, always keys) - `create_managed_keys_account_from_eddsa_account` (ProviderPlatformKeys, always keys) - `from_account_collection` does the field-direct insert each variant expects — same shape as the original code. - `is_funds_bearing_account_type` was only used by the old funnel and is now removed. The variant-aware `insert(impl Into<OwnedManagedCoreAccount>)` and the explicit `insert_funds_bearing_account` / `insert_keys_bearing_account` remain as the public entry points for callers that genuinely need the runtime-dispatched insert (e.g. `add_managed_account`). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 parent 478af3b commit 428b60d

17 files changed

Lines changed: 2275 additions & 465 deletions

dash-spv/tests/dashd_sync/helpers.rs

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,6 @@ use dash_spv::network::NetworkEvent;
22
use dash_spv::sync::{ProgressPercentage, SyncEvent, SyncProgress, SyncState};
33
use dash_spv::test_utils::DashCoreNode;
44
use dashcore::Txid;
5-
use key_wallet::managed_account::managed_account_trait::ManagedAccountTrait;
65
use key_wallet::transaction_checking::TransactionContext;
76
use key_wallet::wallet::managed_wallet_info::wallet_info_interface::WalletInfoInterface;
87
use key_wallet::wallet::managed_wallet_info::ManagedWalletInfo;

key-wallet-ffi/FFI_API.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -233,14 +233,14 @@ Functions: 108
233233
| `managed_core_account_free_transactions` | Free transactions array returned by managed_core_account_get_transactions ... | managed_account |
234234
| `managed_core_account_get_account_type` | Get the account type of a managed account # Safety - `account` must be a... | managed_account |
235235
| `managed_core_account_get_address_pool` | Get an address pool from a managed account by type This function returns... | managed_account |
236-
| `managed_core_account_get_balance` | Get the balance of a managed account # Safety - `account` must be a valid... | managed_account |
236+
| `managed_core_account_get_balance` | Get the balance of a managed account | managed_account |
237237
| `managed_core_account_get_external_address_pool` | Get the external address pool from a managed account This function returns... | managed_account |
238238
| `managed_core_account_get_index` | Get the account index from a managed account Returns the primary account... | managed_account |
239239
| `managed_core_account_get_internal_address_pool` | Get the internal address pool from a managed account This function returns... | managed_account |
240240
| `managed_core_account_get_network` | Get the network of a managed account # Safety - `account` must be a valid... | managed_account |
241241
| `managed_core_account_get_transaction_count` | Get the number of transactions in a managed account Only available with the... | managed_account |
242242
| `managed_core_account_get_transactions` | Get all transactions from a managed account Returns an array of... | managed_account |
243-
| `managed_core_account_get_utxo_count` | Get the number of UTXOs in a managed account # Safety - `account` must be... | managed_account |
243+
| `managed_core_account_get_utxo_count` | Get the number of UTXOs in a managed account | managed_account |
244244
| `managed_platform_account_free` | Free a managed platform account handle # Safety - `account` must be a... | managed_account |
245245
| `managed_platform_account_get_account_index` | Get the account index of a managed platform account # Safety - `account`... | managed_account |
246246
| `managed_platform_account_get_address_pool` | Get the address pool from a managed platform account Platform accounts only... | managed_account |
@@ -3095,7 +3095,7 @@ managed_core_account_get_balance(account: *const FFIManagedCoreAccount, balance_
30953095
```
30963096

30973097
**Description:**
3098-
Get the balance of a managed account # Safety - `account` must be a valid pointer to an FFIManagedCoreAccount instance - `balance_out` must be a valid pointer to an FFIBalance structure
3098+
Get the balance of a managed account. Returns `false` (and leaves `balance_out` untouched) when the handle wraps a keys-only account (identity / asset-lock / provider) — those don't track per-account balances. Use [`managed_core_account_get_account_type`] to disambiguate, or only call this for funds-bearing accounts. # Safety - `account` must be a valid pointer to an FFIManagedCoreAccount instance - `balance_out` must be a valid pointer to an FFIBalance structure
30993099

31003100
**Safety:**
31013101
- `account` must be a valid pointer to an FFIManagedCoreAccount instance - `balance_out` must be a valid pointer to an FFIBalance structure
@@ -3207,7 +3207,7 @@ managed_core_account_get_utxo_count(account: *const FFIManagedCoreAccount,) -> c
32073207
```
32083208

32093209
**Description:**
3210-
Get the number of UTXOs in a managed account # Safety - `account` must be a valid pointer to an FFIManagedCoreAccount instance
3210+
Get the number of UTXOs in a managed account. Always returns 0 for keys-only accounts (identity / asset-lock / provider), which do not track per-account UTXOs. # Safety - `account` must be a valid pointer to an FFIManagedCoreAccount instance
32113211

32123212
**Safety:**
32133213
- `account` must be a valid pointer to an FFIManagedCoreAccount instance

key-wallet-ffi/src/address_pool.rs

Lines changed: 67 additions & 37 deletions
Original file line numberDiff line numberDiff line change
@@ -16,58 +16,74 @@ use key_wallet::managed_account::address_pool::{
1616
AddressInfo, AddressPool, KeySource, PublicKeyType,
1717
};
1818
use key_wallet::managed_account::managed_account_trait::ManagedAccountTrait;
19-
use key_wallet::managed_account::ManagedCoreFundsAccount;
19+
use key_wallet::managed_account::{ManagedAccountRef, ManagedAccountRefMut};
2020
use key_wallet::AccountType;
2121

22-
// Helper functions to get managed accounts by type
22+
// Helper functions to get managed accounts by type. Identity / asset-lock /
23+
// provider variants are stored as keys-only accounts; Standard / CoinJoin
24+
// stay funds-bearing. The returned [`ManagedAccountRef`] enum exposes the
25+
// shared trait surface (address pools, managed type, network) used here
26+
// without forcing callers to dispatch on the variant.
2327
fn get_managed_account_by_type<'a>(
2428
collection: &'a ManagedAccountCollection,
2529
account_type: &AccountType,
26-
) -> Option<&'a ManagedCoreFundsAccount> {
30+
) -> Option<ManagedAccountRef<'a>> {
2731
match account_type {
2832
AccountType::Standard {
2933
index,
3034
standard_account_type,
3135
} => match standard_account_type {
3236
key_wallet::account::StandardAccountType::BIP44Account => {
33-
collection.standard_bip44_accounts.get(index)
37+
collection.standard_bip44_accounts.get(index).map(ManagedAccountRef::Funds)
3438
}
3539
key_wallet::account::StandardAccountType::BIP32Account => {
36-
collection.standard_bip32_accounts.get(index)
40+
collection.standard_bip32_accounts.get(index).map(ManagedAccountRef::Funds)
3741
}
3842
},
3943
AccountType::CoinJoin {
4044
index,
41-
} => collection.coinjoin_accounts.get(index),
42-
AccountType::IdentityRegistration => collection.identity_registration.as_ref(),
45+
} => collection.coinjoin_accounts.get(index).map(ManagedAccountRef::Funds),
46+
AccountType::IdentityRegistration => {
47+
collection.identity_registration.as_ref().map(ManagedAccountRef::Keys)
48+
}
4349
AccountType::IdentityTopUp {
4450
registration_index,
45-
} => collection.identity_topup.get(registration_index),
51+
} => collection.identity_topup.get(registration_index).map(ManagedAccountRef::Keys),
4652
AccountType::IdentityTopUpNotBoundToIdentity => {
47-
collection.identity_topup_not_bound.as_ref()
53+
collection.identity_topup_not_bound.as_ref().map(ManagedAccountRef::Keys)
54+
}
55+
AccountType::IdentityInvitation => {
56+
collection.identity_invitation.as_ref().map(ManagedAccountRef::Keys)
57+
}
58+
AccountType::AssetLockAddressTopUp => {
59+
collection.asset_lock_address_topup.as_ref().map(ManagedAccountRef::Keys)
4860
}
49-
AccountType::IdentityInvitation => collection.identity_invitation.as_ref(),
50-
AccountType::AssetLockAddressTopUp => collection.asset_lock_address_topup.as_ref(),
5161
AccountType::AssetLockShieldedAddressTopUp => {
52-
collection.asset_lock_shielded_address_topup.as_ref()
62+
collection.asset_lock_shielded_address_topup.as_ref().map(ManagedAccountRef::Keys)
63+
}
64+
AccountType::ProviderVotingKeys => {
65+
collection.provider_voting_keys.as_ref().map(ManagedAccountRef::Keys)
66+
}
67+
AccountType::ProviderOwnerKeys => {
68+
collection.provider_owner_keys.as_ref().map(ManagedAccountRef::Keys)
69+
}
70+
AccountType::ProviderOperatorKeys => {
71+
collection.provider_operator_keys.as_ref().map(ManagedAccountRef::Keys)
72+
}
73+
AccountType::ProviderPlatformKeys => {
74+
collection.provider_platform_keys.as_ref().map(ManagedAccountRef::Keys)
5375
}
54-
AccountType::ProviderVotingKeys => collection.provider_voting_keys.as_ref(),
55-
AccountType::ProviderOwnerKeys => collection.provider_owner_keys.as_ref(),
56-
AccountType::ProviderOperatorKeys => collection.provider_operator_keys.as_ref(),
57-
AccountType::ProviderPlatformKeys => collection.provider_platform_keys.as_ref(),
5876
AccountType::DashpayReceivingFunds {
5977
..
6078
}
6179
| AccountType::DashpayExternalAccount {
6280
..
63-
} => {
64-
// DashPay managed accounts are not currently persisted in ManagedAccountCollection
65-
None
6681
}
67-
AccountType::PlatformPayment {
82+
| AccountType::PlatformPayment {
6883
..
6984
} => {
70-
// Platform Payment accounts are not currently persisted in ManagedAccountCollection
85+
// DashPay and Platform Payment accounts are not reachable through
86+
// this address-pool helper.
7187
None
7288
}
7389
}
@@ -76,38 +92,52 @@ fn get_managed_account_by_type<'a>(
7692
fn get_managed_account_by_type_mut<'a>(
7793
collection: &'a mut ManagedAccountCollection,
7894
account_type: &AccountType,
79-
) -> Option<&'a mut ManagedCoreFundsAccount> {
95+
) -> Option<ManagedAccountRefMut<'a>> {
8096
match account_type {
8197
AccountType::Standard {
8298
index,
8399
standard_account_type,
84100
} => match standard_account_type {
85101
key_wallet::account::StandardAccountType::BIP44Account => {
86-
collection.standard_bip44_accounts.get_mut(index)
102+
collection.standard_bip44_accounts.get_mut(index).map(ManagedAccountRefMut::Funds)
87103
}
88104
key_wallet::account::StandardAccountType::BIP32Account => {
89-
collection.standard_bip32_accounts.get_mut(index)
105+
collection.standard_bip32_accounts.get_mut(index).map(ManagedAccountRefMut::Funds)
90106
}
91107
},
92108
AccountType::CoinJoin {
93109
index,
94-
} => collection.coinjoin_accounts.get_mut(index),
95-
AccountType::IdentityRegistration => collection.identity_registration.as_mut(),
110+
} => collection.coinjoin_accounts.get_mut(index).map(ManagedAccountRefMut::Funds),
111+
AccountType::IdentityRegistration => {
112+
collection.identity_registration.as_mut().map(ManagedAccountRefMut::Keys)
113+
}
96114
AccountType::IdentityTopUp {
97115
registration_index,
98-
} => collection.identity_topup.get_mut(registration_index),
116+
} => collection.identity_topup.get_mut(registration_index).map(ManagedAccountRefMut::Keys),
99117
AccountType::IdentityTopUpNotBoundToIdentity => {
100-
collection.identity_topup_not_bound.as_mut()
118+
collection.identity_topup_not_bound.as_mut().map(ManagedAccountRefMut::Keys)
119+
}
120+
AccountType::IdentityInvitation => {
121+
collection.identity_invitation.as_mut().map(ManagedAccountRefMut::Keys)
122+
}
123+
AccountType::AssetLockAddressTopUp => {
124+
collection.asset_lock_address_topup.as_mut().map(ManagedAccountRefMut::Keys)
101125
}
102-
AccountType::IdentityInvitation => collection.identity_invitation.as_mut(),
103-
AccountType::AssetLockAddressTopUp => collection.asset_lock_address_topup.as_mut(),
104126
AccountType::AssetLockShieldedAddressTopUp => {
105-
collection.asset_lock_shielded_address_topup.as_mut()
127+
collection.asset_lock_shielded_address_topup.as_mut().map(ManagedAccountRefMut::Keys)
128+
}
129+
AccountType::ProviderVotingKeys => {
130+
collection.provider_voting_keys.as_mut().map(ManagedAccountRefMut::Keys)
131+
}
132+
AccountType::ProviderOwnerKeys => {
133+
collection.provider_owner_keys.as_mut().map(ManagedAccountRefMut::Keys)
134+
}
135+
AccountType::ProviderOperatorKeys => {
136+
collection.provider_operator_keys.as_mut().map(ManagedAccountRefMut::Keys)
137+
}
138+
AccountType::ProviderPlatformKeys => {
139+
collection.provider_platform_keys.as_mut().map(ManagedAccountRefMut::Keys)
106140
}
107-
AccountType::ProviderVotingKeys => collection.provider_voting_keys.as_mut(),
108-
AccountType::ProviderOwnerKeys => collection.provider_owner_keys.as_mut(),
109-
AccountType::ProviderOperatorKeys => collection.provider_operator_keys.as_mut(),
110-
AccountType::ProviderPlatformKeys => collection.provider_platform_keys.as_mut(),
111141
AccountType::DashpayReceivingFunds {
112142
..
113143
}
@@ -384,7 +414,7 @@ pub unsafe extern "C" fn managed_wallet_set_gap_limit(
384414
let account_type_rust = account_type.to_account_type(account_index);
385415

386416
// Get the specific managed account
387-
let managed_account = unwrap_or_return!(
417+
let mut managed_account = unwrap_or_return!(
388418
get_managed_account_by_type_mut(&mut managed_wallet.accounts, &account_type_rust),
389419
error
390420
);
@@ -471,7 +501,7 @@ pub unsafe extern "C" fn managed_wallet_generate_addresses_to_index(
471501
let key_source = KeySource::Public(xpub);
472502

473503
// Get the specific managed account
474-
let managed_account = unwrap_or_return!(
504+
let mut managed_account = unwrap_or_return!(
475505
get_managed_account_by_type_mut(&mut managed_wallet.accounts, &account_type_rust),
476506
error
477507
);

0 commit comments

Comments
 (0)