Function propose_shielding_coinbase 

pub fn propose_shielding_coinbase<DbT, ParamsT, InputsT, FeeRuleT, CommitmentTreeErrT>(
    wallet_db: &mut DbT,
    params: &ParamsT,
    input_selector: &InputsT,
    fee_rule: &FeeRuleT,
    shielding_threshold: Zatoshis,
    from_addrs: &[TransparentAddress],
    to_address: ZcashAddress,
    memo: Option<MemoBytes>,
    limit: Option<usize>,
    lock_inputs: Option<LockRequest>,
) -> Result<Proposal<FeeRuleT, Infallible>, ProposeShieldingCoinbaseErrT<DbT, CommitmentTreeErrT, InputsT, FeeRuleT>>
where
    ParamsT: Parameters,
    DbT: WalletWrite + InputSource<Error = <DbT as WalletRead>::Error>,
    InputsT: ShieldingSelector<InputSource = DbT>,
    FeeRuleT: FeeRule + Clone,

Available on crate feature transparent-inputs only.

Constructs a proposal to shield one or more coinbase transparent outputs to an arbitrary shielded recipient.

Unlike propose_shielding, this method:

• Restricts input selection to coinbase outputs only. The restriction is enforced at the API boundary; it cannot be overridden by callers. Coinbase outputs have no prior transparent transaction graph, which is what makes it acceptable to send them to an arbitrary shielded recipient.
• Requires to_address to be a shielded address (Sapling, or a Unified Address with a shielded receiver). Transparent and TEX destinations are rejected with ProposalError::ShieldingRequiresShieldedRecipient. The address may belong to an account outside the caller’s wallet.
• Accepts an optional memo to be attached to the shielded payment.
• Accepts an optional limit capping the number of transparent inputs to at most n, keeping the highest-value UTXOs (with a stable tiebreaker by outpoint). Some(0) selects no inputs and therefore returns InputSelectorError::InsufficientFunds.

When lock_inputs is Some(request), the coinbase inputs selected by the proposal are locked on behalf of the request’s owner until target_height + request.for_blocks() to prevent concurrent proposals from selecting them; when None, no locking is performed. See propose_transfer for the full semantics and concurrency behavior.

The resulting proposal carries an explicit ZIP-321 payment to to_address for input_total - fee. No change is produced, in either the transparent or any shielded pool: a shielded change output would let the recipient (or any chain observer) learn the sender’s total selected-coinbase value by summing the public transparent input values and subtracting the visible payment amount.