Borsh vs Zero-Copy

Solana account data comes in two fundamentally different models, and treating them the same is the biggest possible mistake. layoutd runs a different layout engine for each.

Borsh — the common case#

Standard #[account] types serialize their fields sequentially, length-prefixing variable types like Vec and String. There are no rigid byte offsets: a variable field in the middle moves everything after it, and migration is a deserialize-old then re-serialize-new matched by name.

• Field reorder is safe — matching is by name, not position.
• Appends are safe; mid-struct inserts shift following offsets.
• This is the simpler model and the focus of v0.1.

Zero-copy — the hard case#

#[account(zero_copy)] types use repr(C) with a fixed layout: real offsets, alignment requirements, and padding bytes. This is where offset math and alignment hazards live, and where audit findings concentrate. layoutd’s zero-copy engine replicates the compiler’s layout rules exactly to compute correct offsets.

• Order controls offsets, padding, and total size.
• A reorder can change size or break alignment — review or danger.
• The hardest, most defensible part of the tool.

For how each change case differs between the two models, see The Five Change Cases.