Function put_blocks_rows 

pub fn put_blocks_rows<DbT, SE, TE>(
    wallet_db: &mut DbT,
    gap_limits: GapLimits,
    from_state: &ChainState,
    blocks: Vec<ScannedBlock<<DbT as LowLevelWalletRead>::AccountId>>,
) -> Result<PutBlocksRows, PutBlocksError<SE, TE>>
where
    DbT: PutBlocksRowsDbT<SE, <DbT as LowLevelWalletRead>::AccountRef>,
    DbT::TxRef: Eq + Hash,

Persists the row-level (non-tree) data for a sequence of scanned blocks: block metadata, transaction and note rows, spent-note marking, nullifier tracking and pruning, and — when the transparent-inputs feature is enabled — transparent gap address maintenance for the involved accounts.

This is the first stage of put_blocks, which is equivalent to put_blocks_rows followed by the note commitment tree updates (see build_subtrees and update_tree) and LowLevelWalletWrite::notify_scan_complete. It is exposed so that wallet stores that maintain their note commitment trees by other means can reuse the row-writing logic through the LowLevelWalletWrite interface without also taking on the WalletCommitmentTrees requirement.

The TE type parameter is unconstrained here (the row stage cannot produce a tree error); it exists so that errors propagate directly as the PutBlocksError of the enclosing put_blocks call.

Parameters

• wallet_db: A handle to the underlying data store.
• from_state: The note commitment tree state as of the end of the last block prior to the first block in the provided block vector; PutBlocksError::NonSequentialBlocks will be returned if this invariant is violated.
• blocks: The scanned block data to be added to the data store. This vector must contain data for blocks in sequentially increasing height order; PutBlocksError::NonSequentialBlocks will be returned if this invariant is violated.

Spend tracking

When a batch extends the wallet’s contiguous fully-scanned frontier (i.e. LowLevelWalletRead::block_fully_scanned_height equals the from_state height, so every block from the wallet birthday through the previous block has been scanned), spend-map insertion is skipped for blocks more than SPEND_MAP_RETENTION_BLOCKS below the end of the batch. Under that precondition the skipped entries are provably unobservable: the spend maps exist to detect spends observed before the corresponding output’s block has been scanned, which cannot occur below a contiguous frontier — any wallet output spendable in a skipped block was either received in an already-scanned block (so its spend is detected directly against the wallet’s own nullifiers and outpoints rather than the map) or is received later in this same ascending batch (so the spend is linked when the receiving transaction is processed). For every out-of-order range — scanning after a gap, recent-first, or chain-tip pre-scans — every block’s spends are tracked.

This governs the shielded nullifier maps and the transparent spend map alike; the argument above is indifferent to which kind of output identifier is being tracked.