Should CPI Guard block ConfidentialTransfer::Deposit?

[VictorLux]

@joncinque asked that this be discussed in public after a private report.

process_deposit never reads CpiGuard / in_cpi() after validate_owner. Sibling owner-signed value moves do:

• public Transfer / Burn
• confidential Transfer / TransferWithFee (confidential_transfer/processor.rs)
• confidential Burn (confidential_mint_burn/processor.rs)

Those confidential checks landed in #819 “for consistency”, with the note that another program cannot produce a valid ZKP for a confidential transfer. Deposit does not need a ZK proof, so that rationale does not cover it.

Observed locally on program@v11.0.0 under a real SBF CPI (sol_get_stack_height): with lock_cpi = true, Burn returns CpiGuardBurnBlocked; Deposit succeeds and moves public base.amount into pending confidential balance on the same account.

Docs (https://solana.com/docs/tokens/extensions/cpi-guard) also do not list Deposit.

Question: is the omit intentional (Deposit is an in-account conversion, not a transfer/burn), or should it match the #819 sibling check?

Not claiming theft — funds never leave the account.

[joncinque]

@2501babe / @samkim-crypto any thoughts about this?

I think it's fine to allow confidential deposits in CPI even with CPI guard enabled, since funds would be completely recoverable, but I'm curious to hear what you think

[plutohan]

One consideration for the allow side: recovery is owner-executable but not free. After a CPI deposit the funds sit in pending confidential balance, so the owner needs an ApplyPendingBalance plus a Withdraw with a fresh ZK proof to get back to public, and wallets without confidential support will show the public balance as reduced in the meantime. So the worst case is not loss but a display and UX grief the victim may not know how to undo, which is arguably within CPI Guard's consent model even though no value leaves the account.

That said, blocking Deposit adds a check to a path legitimate protocols may want for programmatic privacy flows, and the #819 rationale (another program cannot produce the ZKP) genuinely does not apply here, so the intentional-omit reading is defensible too.

If the decision is to keep allowing it, would you take a PR that makes the exemption explicit: a line in the CPI Guard docs listing Deposit as intentionally not blocked, plus a regression test locking in that a CPI Deposit with lock_cpi enabled succeeds? Happy to implement the sibling check instead if consensus goes the other way.