PriceUpdateV2 LEN

[adrena-orex]

Issue

Deserializing an PriceUpdateV2 account info using AnchorDeserialize::try_from_slice(data) fails.

Note: Using PriceUpdateV2::try_deserialize(&mut data) works.

Cause

The PriceUpdateV2 structure have a size of 136 bytes, while LEN is 134 and onchain accounts are 134 bytes.

Onchain Account Example

https://explorer.solana.com/address/7UVimffxr9ow1uXYxsr4LHAcV58mLzhmwaeKvJ1pjLiE?cluster=devnet

PriceUpdateV2 struct in the code

#[account]
#[derive(BorshSchema)]
pub struct PriceUpdateV2 {
    pub write_authority:    Pubkey,
    pub verification_level: VerificationLevel,
    pub price_message:      PriceFeedMessage,
    pub posted_slot:        u64,
}

impl PriceUpdateV2 {
    pub const LEN: usize = 8 + 32 + 2 + 32 + 8 + 8 + 4 + 8 + 8 + 8 + 8 + 8;
}

[JohnnnyWang]

Yes, same question, is it correct to launch on mainnet (or TestNet)?
In my local solana-test-validator, the size is also 136

[mariobern]

hey guys, thank you for the question

@aditya520 @guibescos could you take a look please?

[guibescos]

I'm pretty confused about this. The size of the struct is 134, we even have a test to check this https://github.com/pyth-network/pyth-crosschain/blob/main/target_chains/solana/pyth_solana_receiver_sdk/src/price_update.rs#L238.

The reason why AnchorDeserialize::try_from_slice(data) fails is because it expects the PriceUpdateV2 to start at the beginning of the bytes but instead there's the Anchor 8 bytes discriminator.
PriceUpdateV2::try_deserialize handles the discriminator properly.

[J0HnNy-W]

Yes, this is really strange.

I checked the class in vscode and found that the size is 136.

At the same time, I wrote a mock pyth program and found that the solana log output of executing this method is also 136

size of price_update_v2: 136

Version:

pyth-solana-receiver-sdk ="0.3"

My Device:
I use a macbook pro M2 max, and develop with anchor 0.30.1, solana-cli 1.18.17 (src:b685182a; feat:4215500110, client:SolanaLabs)

[0xtinkle]

There seems to be an inconsistency in how the struct size is calculated across different environments.

A few thoughts and debugging steps:

1. Anchor's 8-Byte Discriminator
   Since AnchorDeserialize::try_from_slice(data) fails but PriceUpdateV2::try_deserialize(&mut data) works, it seems like try_from_slice is expecting data without the 8-byte Anchor discriminator at the start.
   Confirming: Is the data being deserialized directly from an on-chain account, or is it being extracted from within another struct?

2. Struct Alignment & Padding (M1/M2 Architectures?)
   Some systems (especially Apple Silicon) automatically pad structs to align memory. This might be why some local environments return 136 while on-chain storage has 134.
   Could be worth explicitly packing the struct (#[repr(C, packed)]) to avoid implicit padding.

3. Testing on Different Systems
   Given reports that different machines return different sizes, maybe test with:
   std::mem::size_of::<PriceUpdateV2>()
borsh::to_vec(&price_update_v2).unwrap().len()
   If results differ, a #[repr(C, packed)] annotation might help ensure consistency.
   Would love to hear thoughts from others—does forcing packed or adjusting the LEN resolve the issue?