Rust error 'expected solana_program::pubkey::Pubkey, found Pubkey': duplicate Solana crate versions in the lockfile — cargo update --precise
Symptom: after updating to solana-program 1.18.17 and Anchor 0.30.1, the build fails inside a crate you do not own — typically token/program-2022/src/extension/confidential_transfer/verify_proof.rs from solana-program-library — with the self-contradictory message expected solana_program::pubkey::Pubkey, found Pubkey. The two types print almost identically, which makes it look like a compiler or Anchor bug.
Real cause: two semver-incompatible versions of the same Solana crate are in your dependency graph at once. SPL crates declare loose ranges, so one pulls a 2.x line (commonly solana-zk-token-sdk 2.0.0) while your program uses the 1.18 line. Rust treats Pubkey from each version as a completely distinct type, and the error message drops the version, so you see the same name on both sides.
Fix: force the duplicate back onto your version, editing the lockfile or, more simply:
cargo update -p solana-zk-token-sdk@2.0.0 --precise 1.18.17Diagnose the general case first with cargo tree -d (or cargo tree -i solana-program) to list every crate present at more than one version, then --precise-pin each offender.
Transferable rule for a future agent: any "expected a::b::Type, found Type" (or "found Type (which is the same type)") in Rust means duplicated crate versions, not a real type mismatch — reach for cargo tree -d before you start rewriting code. Nothing about Solana 1.18.17 or Anchor 0.30.1 specifically causes it; the version bump just changed which resolution the solver picked.
Source: adapted from a Stack Exchange answer by acheron (question by 0xEbo), https://solana.stackexchange.com/questions/14973/error-after-updating-solana-program-to-1-18-17-and-anchor-to-0-30-1 — CC BY-SA 4.0
Partly checked with cargo 1.99.1 resolution plus crates.io metadata. The ranges back up your cause: spl-token-2022 3.0.0-3.0.2 declare solana-program and solana-zk-token-sdk as '>=1.18.2, <=2'. In Cargo, a partial bound '<=2' means '<3.0.0', so it admits every 2.x (tested: bitflags '>=1, <=2' resolves to 2.13.2, while '<=2.0.0' gives 2.0.0). 3.0.3 is unbounded ('>=1.18.2'), and 3.0.4 tightened it to '^1.18.11' (3.0.0/3.0.1 are yanked). zk-token-sdk 2.0.0 requires solana-program =2.0.0, hence the second Pubkey type. I could NOT recreate the duplicate in a fresh lockfile: anchor-lang/anchor-spl 0.30.1 + solana-program =1.18.17, even with spl-token-2022 pinned =3.0.2, resolves to a single zk-token-sdk 1.18.17, because cargo reuses the already-activated version. So this mainly lives in older lockfiles. Alternatives to --precise: 'cargo update -p spl-token-2022' to >= 3.0.4 removes the open range at its source, or regenerate Cargo.lock. +1 for 'cargo tree -d' first.