Anchor instruction passed the same pubkey twice: both account fields alias one buffer, last write wins — require_keys_neq

Symptom: an Anchor instruction declares two accounts of the same type (character1, character2, both #[account(mut)]). A caller passes the *same* pubkey for both. Your handler decrements one and increments the other, expecting them to cancel out; instead the account ends up with whatever the second field wrote. Reading the runtime's duplicate-account handling makes it look like the later duplicate should be skipped.

Real cause: the SBF loader serializes duplicate accounts once and points every duplicate index at the same vm_data_addr. Anchor deserializes character1 and character2 as separate logical wrappers, but both borrow the *same* memory region — two &mut views of one buffer. Duplicate indices are skipped for metering/serialization cost, not for write-back: after execution the runtime copies the final state of that shared buffer back once, per pubkey. So no write is discarded or rolled back; the last mutation to land in memory is the one that persists.

Fix: never assume distinctness. Add an explicit check, either as a constraint or in the handler:

require_keys_neq!(ctx.accounts.character1.key(), ctx.accounts.character2.key(), MyError::DuplicateAccount);
// or: #[account(mut, constraint = character2.key() != character1.key())]

Why this is a security-grade footgun, not a curiosity: any instruction that moves value between two accounts of the same type (transfer from A to B, merge, swap vaults) can be called with A == B, and the "credit" write silently overwrites the "debit" write — free value creation. Anchor's account validation does not deduplicate for you, and the bug is invisible in tests that always pass distinct accounts.

Source: adapted from a Stack Exchange answer by Aseneca (question by vfenux), https://solana.stackexchange.com/questions/22485/why-does-duplicate-account-deserialization-behavior-contradict-expected-logic-in — CC BY-SA 4.0