Module pool 

Available on crate features test-dependencies only.

Re-exports

pub use locking::*;

Modules

dsl

A convenient DSL for writing wallet tests.

locking

The shared, backend-agnostic test suite for the note-locking feature.

Enums

InputTrust

An enumeration of mechanisms for generating transaction inputs for confirmations policy testing.

Traits

ShieldedPoolTester

Trait that exposes the pool-specific types and operations necessary to run the single-shielded-pool tests on a given pool.

Functions

account_deletion

account_deletion_with_internal_transfer

Regression test for a bug in which WalletWrite::delete_account failed with a rusqlite::Error::InvalidParameterName(":address") panic when the account being deleted was referenced by a sent_notes row via its to_account_id column.

account_rename

Verifies that WalletWrite::set_account_name replaces the name of the given account, leaves the names of other accounts unchanged, and permits two accounts to share a name.

anchor_checkpoints_retained_across_deep_scan

A wallet-level test for note-commitment-tree anchor retention: once NU6.3 (Ironwood) is active, checkpoints on the anchor-retention interval are retained as durable anchors, exempt from the ordinary PRUNING_DEPTH-checkpoint pruning budget, so that their roots and the witnesses anchored to them remain computable even after they age far behind the chain tip.

birthday_in_anchor_shard

canonical_crossing_abandoned_without_anchor_checkpointorchard

A canonical payment whose bucketed anchor checkpoint is MISSING from the wallet falls back to an ordinary crossing instead of failing at build time.

canonical_crossing_builds_at_empty_boundary_blockorchard

A canonical crossing whose bucketed anchor falls on a block with no shielded outputs must still build. Note eligibility at the bucketed anchor is a height comparison, so the proposal selects and anchors there regardless; unless the boundary checkpoint was ensured at scan time — the boundary block itself contributed no note commitment to create one — building would fail attempting to construct witnesses at a checkpoint that does not exist.

canonical_crossing_is_bucketed_and_unpaddedorchard

A payment whose value is a canonical ZIP 318 denomination, fundable from a single Orchard note, is proposed against a bucketed anchor and built with a single unpadded Ironwood action — the shape of a ZIP 318 migration transfer. Everything else keeps the ordinary anchor and the two-action floor.

canonical_crossing_prefers_single_noteorchard

A canonical payment is funded from the single oldest covering note even when accumulation would have reached the target through several smaller notes first.

change_note_spends_succeed

checkpoint_gaps

coinbase_only_filteringpczt and transparent-inputs

Tests that CoinbaseFilter::CoinbaseOnly excludes non-coinbase outputs and CoinbaseFilter::NonCoinbaseOnly excludes coinbase outputs from UTXO selection and shielding proposals, and that CoinbaseOnly still allows proposing shielding when only coinbase UTXOs are available.

create_pczt_supports_ironwood_outputorchard and pczt

PCZT construction supports the version 6 transaction format, including its Ironwood bundle. After NU6.3 a payment to an Orchard receiver is delivered through the Ironwood pool, so create_pczt_from_proposal realizes such a proposal as a version 6 PCZT that carries a populated Ironwood bundle.

create_pczt_uses_nu7_default_expirypczt

Tests that a PCZT that the wallet creates with no explicit expiry height expires after the default expiry delta for its target height: 40 blocks before NU7 activation, and 120 blocks from NU7 activation onward.

create_proposed_transactions_uses_nu7_default_expiry

Tests that a transaction that the wallet creates with no explicit expiry height expires after the default expiry delta for its target height: 40 blocks before NU7 activation, and 120 blocks from NU7 activation onward.

create_to_address_fails_on_incorrect_usk

create_to_address_respects_recipient_expiry

Tests that payment construction enforces the ZIP 316 Revision 2 address expiration rules: a payment to an address whose expiry height conflicts with the transaction’s expiry height is refused, a payment to an address whose expiry time has passed is refused (for any recipient of a multi-recipient transaction), and a payment to an address with unexpired metadata succeeds.

data_db_truncation

empty_boundary_blocks_are_checkpointed_and_retainedorchard

A grid boundary that lands on a block containing no note commitments in ANY pool must still be checkpointed and retained. Scanning checkpoints a block only at its last note commitment, so such a block produces no checkpoint of its own in any tree and the cross-pool ensure step has nothing to copy; unless the retained heights are ensured explicitly, the retained grid gains a permanent hole there — on mainnet a sizeable fraction of blocks carry no shielded outputs — and a ZIP 318 crossing anchored to the hole can never be proved.

external_address_change_spends_detected_in_restore_from_seed

fails_to_send_max_spendable_to_transparent_with_memotransparent-inputs

Tests that sending all the spendable funds within the given shielded pool in a single transaction to a transparent address with a memo fails.

fully_funded_fully_privateorchard

fully_funded_send_to_torchard and transparent-inputs

immature_coinbase_outputs_are_excluded_from_note_selectionpczt and transparent-inputs

Tests that immature coinbase outputs are excluded from note selection.

insufficient_funds_counts_transparent_inputstransparent-inputs

Tests that the InsufficientFunds error of a transfer permitted to spend the account’s transparent outputs reports the value of those outputs as available, alongside the notes.

invalid_chain_cache_disconnected

metadata_queries_exclude_unwanted_notes

multi_note_crossing_is_not_bucketedorchard

A canonical amount that cannot be funded from a single Orchard note is NOT a canonical crossing, and must not pay for a bucketed anchor it gains nothing from.

multi_pool_checkpointorchard

multi_pool_checkpoints_with_pruningorchard

newly_discovered_notes_become_stabilized

Verifies that when a new account is imported into a fully-scanned wallet, the ensuing re-scan discovers the new account’s previously-unknown notes and scan_complete → mark_stabilized_notes flags them witness_stabilized on the fly, so they remain spendable across a subsequent deep rewind_to_chain_state.

oldest_note_is_selected_first

Note selection draws the OLDEST eligible notes first, where age is chain order — the note’s commitment tree position — not discovery order. Priority scanning discovers recent blocks before back-filling history, so a restored wallet’s newest notes carry its lowest row ids; ordering by id would spend fresh change while far older notes sat idle. The ordering must therefore survive scanning blocks out of order.

orchard_to_ironwood_payment_reports_net_value_deltaorchard

The transaction history entry for a payment funded from the Orchard pool and delivered through the Ironwood pool reports the amount that left the account (payment plus fee) as its balance delta, not the total value of the notes spent, which would ignore the change returned to the wallet.

orchard_to_ironwood_self_migration_reports_fee_only_deltaorchard

A migration of the wallet’s own funds from the Orchard pool to the Ironwood pool, namely a payment to the wallet’s own external Orchard receiver delivered through the Ironwood pool, leaves the account balance unchanged except for the fee. The payment output returned to the wallet is not recorded at transaction-creation time (it is an address payment, which the wallet expects to detect by scanning), so this exercises detection of the wallet’s own Ironwood outputs in the scanning path.

ovk_policy_prevents_recovery_from_chain

pczt_single_steppczt

pool_crossing_requiredorchard

proposal_fails_if_not_all_ephemeral_outputs_consumedtransparent-inputs

proposal_fails_with_no_blocks

proposal_records_and_serializes_proposed_versionorchard

The transaction version requested at proposal time is recorded on the proposal and preserved across serialization, so that transaction building honors it. A proposal serialized without a version request (as older serializers produced) decodes with no requested version and falls back to the target-height version at build time.

proposal_without_confirmations_policy_buildspczt and transparent-inputs

A newly constructed shielding proposal preserves the checkpoint selected by the wallet, even though it spends no shielded notes. A proposal serialized without the confirmations-policy field (as an older library version would have produced) decodes using the default policy and, because it still carries that real anchor, builds. Separately, a shielding step produces a shielded bundle, so a proposal that encodes such a step with the zero anchor sentinel is rejected at the parse boundary.

propose_and_build_shielding_coinbase_succeedspczt and transparent-inputs

Regression test for the propose-fee/build-fee mismatch fixed in #2376.

propose_shielding_coinbase_succeedspczt and transparent-inputs

Verifies that propose_shielding_coinbase with a shielded destination produces a proposal containing a single ZIP-321 payment to the supplied address for the full available value (input total minus fee), with no change.

propose_shielding_coinbase_transparent_recipient_rejectedpczt and transparent-inputs

Verifies that propose_shielding_coinbase rejects a transparent destination with ProposalError::ShieldingRequiresShieldedRecipient.

propose_shielding_coinbase_with_limit_truncates_inputspczt and transparent-inputs

Verifies that propose_shielding_coinbase with limit = Some(n) selects at most n UTXOs, preferring the highest-value coinbase outputs.

propose_shielding_coinbase_with_memo_succeedspczt and transparent-inputs

Verifies that propose_shielding_coinbase propagates the supplied memo into the resulting payment’s memo field.

propose_shielding_coinbase_with_zero_limit_insufficient_fundspczt and transparent-inputs

Verifies that propose_shielding_coinbase with limit = Some(0) selects no inputs, returning InputSelectorError::InsufficientFunds.

propose_v5_payment_to_orchard_receiver_is_rejectedorchard

After NU6.3 activation, a payment to an Orchard receiver must be delivered through the Ironwood pool, which requires a version 6 transaction. Explicitly requesting a version 5 transaction — which has no Ironwood bundle — for such a payment must be rejected at proposal time with ProposalError::OrchardReceiverRequiresIronwood, rather than producing a proposal that could only fail later at build time.

receive_two_notes_with_same_value

Tests that the wallet correctly reports balance with two notes that are identical other than their note randomness.

reorg_to_checkpoint

rewind_after_non_contiguous_scan

rewind_to_chain_state_deep

rewind_to_chain_state_shallow

scan_cached_blocks_allows_blocks_out_of_order

scan_cached_blocks_detects_spends_out_of_order

scan_cached_blocks_finds_change_notes

scan_cached_blocks_finds_received_notes

scan_full_block_detects_outputs

Builds a real transaction via the proposal/creation path, assembles it into a full block, and verifies that decrypt_block followed by scan_block detects the wallet output (the change note) that it contains.

self_migration_keeps_spending_orchardorchard

Self-migration does not stall once the wallet holds Ironwood notes.

send_max_fails_when_balance_is_consumed_by_fees

Tests that a send-max proposal fails with InsufficientFunds when the entire wallet balance would be consumed by fees, rather than proposing a transaction that delivers nothing to the recipient.

send_max_fee_overflow_is_an_errortransparent-inputs

Tests that a send-max proposal whose total required fee overflows the maximum monetary amount fails with a balance error rather than panicking.

send_max_spendable_proposal_succeeds_when_unconfirmed_funds_present

Tests that attempting to send MaxSpendable funds within the given shielded pool in a single transaction succeeds if there are funds that are not yet confirmed.

send_max_spendable_to_transparenttransparent-inputs

Tests that sending all the spendable funds within the given shielded pool to a transparent (non-TEX) recipient succeeds.

send_max_spends_inputs_across_poolsorchard

Tests that a send-max proposal spends notes from multiple shielded pools in a single transaction when the wallet’s funds are split across pools.

send_multi_step_proposed_transfertransparent-inputs

send_single_step_proposed_transfer

Tests sending funds within the given shielded pool in a single transaction.

send_with_multiple_change_outputs

shield_transparenttransparent-inputs

shielding_coinbase_to_orchard_receiver_delivers_via_ironwoodorchard and pczt and transparent-inputs

Verifies that once Ironwood is active, propose_shielding_coinbase resolves a destination with an Orchard receiver to the Ironwood pool — the payment is delivered to the Orchard receiver via the Ironwood bundle — and that the proposed transaction builds.

spend_all_funds_multi_step_proposed_transfertransparent-inputs

Test attempts to sweep a wallet into a TEX address

spend_all_funds_single_step_proposed_transfer

Tests spending all funds within the given shielded pool in a single transaction.

spend_everything_multi_step_many_notes_proposed_transfertransparent-inputs

This test attempts to send the max spendable funds to a TEX address recipient checks that the transactions were stored and that the amounts involved are correct

spend_everything_multi_step_single_note_proposed_transfertransparent-inputs

This test attempts to send the max spendable funds to a TEX address recipient checks that the transactions were stored and that the amounts involved are correct

spend_everything_multi_step_with_marginal_notes_proposed_transfertransparent-inputs

This test attempts to send the max spendable funds to a TEX address recipient. The wallet contains many notes denominated with the marginal fee value. Checks that the transactions were stored and that the amounts involved are correct

spend_everything_proposal_fails_when_unconfirmed_funds_present

Tests that attempting to send all the spendable funds within the given shielded pool in a single transaction fail if there are funds that are not yet confirmed.

spend_everything_single_step_proposed_transfer

Tests sending every piece of spendable funds within the given shielded pool in a single transaction.

spend_fails_on_unverified_notes

spend_max_spendable_single_step_proposed_transfer

Tests max spendable funds within the given shielded pool in a single transaction.

spend_succeeds_to_t_addr_zero_change

stabilized_note_spendable_after_deep_rewind

Multiple wallet notes in a stabilized shard remain spendable after a deep rewind_to_chain_state moves the scan queue below them.

transfer_fails_across_pools_at_a_dust_shortfallorchard

Tests that a transfer which draws on a second pool at a dust shortfall reports InsufficientFunds over both pools when the second note cannot cover the two-bundle fee.

transfer_grows_across_pools_at_a_dust_shortfallorchard

Tests that a transfer whose change from the preferred pool’s note would be dust draws on a note in another pool instead of failing.

truncate_to_chain_state

truncate_to_chain_state_above_scanned

truncate_to_chain_state_below_birthday

valid_chain_states

wallet_recovery_computes_feestransparent-inputs

Ensure that wallet recovery recomputes fees.

zip317_spend

zip_315_confirmations_test_steps

Tests that inputs from a source can be spent according to the default ConfirmationsPolicy.