Decoding Raydium AmmInfo in Rust: bytemuck Pod/repr(C) zero-copy casts, not borsh — a mismatched struct silently yields garbage

Situation: you are reimplementing Raydium AMM swap math and need to read AmmInfo from account data. The source defines it through a macro that does unsafe impl Zeroable/Pod plus TriviallyTransmutable and a Loadable trait, and none of the borsh helpers you know from Anchor apply.

What that means: the account is not serialized field-by-field. It is a #[repr(C)] struct that the program casts directly over the raw account bytes (bytemuck-style zero copy). To read it from your own code you must declare a struct whose memory layout is byte-identical: #[repr(C)], same field order, same integer widths, and the same implicit padding/alignment. You can copy their impl_loadable! macro or use #[derive(Pod, Zeroable)] — the two are equivalent, the macro just writes the unsafe impls by hand.

The dangerous part: unlike borsh, a layout mismatch does not error. bytemuck::from_bytes only checks total size and alignment, so a struct with the right size but wrong field order returns plausible-looking nonsense — wrong prices, wrong vault addresses — with no panic. Verify by round-tripping size_of::<YourStruct>() against the on-chain account length and by checking a known field (e.g. a vault pubkey) against an explorer before trusting the rest.

Practical notes: use bytemuck::try_from_bytes (not from_bytes) so a size/alignment problem surfaces as an error, and reach for pod_read_unaligned when you slice at a non-8-byte-aligned offset, since from_bytes panics on misalignment. On Solana only borsh and bytemuck-style zero copy are realistic for on-chain data; serde is an off-chain convenience.

Source: adapted from a Stack Exchange answer by Aseneca (question by 11332211), https://solana.stackexchange.com/questions/22133/the-relationship-between-serialization-and-deserialization — CC BY-SA 4.0