Cross Vm Serialization Conformance

CROSS_VM_SERIALIZATION_CONFORMANCE

Trigger: NON_EVM_TARGET flag (recon detects a non-EVM destination — Solana/Bitcoin/Move/Cosmos — via 32-byte pubkey constants, base58/bech32 handling, custom account/byte encoders (account-meta packers, Borsh-style packing), or a foreign chain-id/program-id). Inject Into: breadth agent owning the cross-chain/encoding focus, and depth-external. Protocol Types: any contract that SERIALIZES data on the EVM side for consumption by a DIFFERENT VM (cross-chain bridges, general cross-chain messaging protocols, Solana/Bitcoin gateways). Added in: recall-recovery (post a ground-truth audit comparison — closes the outbound-encoding gap CROSS_CHAIN_MESSAGE_INTEGRITY does not cover; that skill covers INBOUND decode/auth only).

Why this exists

CROSS_CHAIN_MESSAGE_INTEGRITY audits messages the contract RECEIVES (decode, auth, replay). It does NOT audit whether the bytes the contract PRODUCES on the EVM side match the layout the destination VM expects. An EVM contract that packs a Solana account list, a Borsh struct, or a Bitcoin script with the wrong field width, wrong byte order, wrong flag encoding, or wrong cursor advance will ship structurally-valid-on-EVM but corrupt-on-arrival payloads — silently breaking cross-chain execution or corrupting permissions/amounts. This is a recurring, general bridge bug class and is INVISIBLE to pure EVM-side reasoning.

Methodology

Step 0 — Verify the serialization SCHEME matches the destination VM (GATES Steps 1-3)

Before ANY per-field check, confirm the encoder emits the destination VM's NATIVE wire format — not EVM ABI. Native formats: Solana/Anchor = Borsh; Cosmos = Protobuf/Amino; Move/Sui = BCS; Bitcoin = script + varint/ CompactSize; NEAR = Borsh. EVM abi.encode/abi.encodePacked emit EVM ABI (32-byte-word-aligned head/tail offsets, dynamic-length prefixes) — a layout that NONE of those VMs deserialize. So if the EVM side builds a payload with abi.encode/abi.encodePacked (or returns such a blob) that a non-EVM program will deserialize with its native decoder, the payload is structurally undecodable on arrival — a CONFIRMED scheme-mismatch finding regardless of field-level correctness. Field-level conformance (Steps 1-3) is meaningless if the whole envelope is the wrong format; only proceed once the scheme is correct.

FP guard (positive-evidence-to-demote — do NOT invert the burden of proof). Demote/skip ONLY on POSITIVE, in-scope evidence that the payload reaches an abi.decode consumer: an EVM-compatible reader, an EVM L2/sidechain target, or an on-chain re-encoding hop VISIBLE IN SCOPE that re-serializes before the foreign VM sees it. A round-trip to an EVM decoder is fine; a hand-off to a Borsh/BCS/Protobuf/script decoder is not.

When the actual consumer is EXTERNAL / out-of-scope / not inspectable, the Step-0 default STANDS — this is a CONFIRMED finding, NOT an Informational "pending external research" hedge. The destination VM's native format (Solana=Borsh, etc.) is the worst realistic condition (R10); assume it. Report at the Step-3 impact severity with an explicit [EXTERNAL-ASSUMPTION: destination deserializes with <format>; non-issue ONLY if it abi.decodes] note and route to the verifier. Inability to inspect the external consumer is NOT grounds to downgrade: the encode mismatch is proven on the EVM side, and only POSITIVE evidence of a safe decode path rebuts it — its mere possibility does not. "Requires external research → default Informational" is a prohibited burden inversion for this class.

Step 1 — Enumerate the serialization surfaces

List every site where the EVM contract builds bytes destined for a non-EVM VM: abi.encode/abi.encodePacked into a cross-chain message, custom assembly byte writers (mstore/mload cursors), account/instruction encoders (e.g. custom account-meta encoders, Borsh packers), address/pubkey conversions (20-byte EVM address ↔ 32-byte Solana pubkey; bytes20 truncation of a non-EVM address), and flag packing (writable/signer bits, option discriminants).

Step 2 — For each surface, verify field-by-field conformance to the destination layout

For EACH field written:

• Width: is the field written/read at the EXACT width the destination expects? (e.g. a 1-byte boolean flag read with a full 32-byte mload, or a 32-byte pubkey truncated to 20 bytes via bytes20.) A read/write wider or narrower than the field corrupts it and/or the following fields.
• Cursor advance: after writing/reading a field, does the pointer advance by the field's TRUE width? A 1-byte field whose cursor advances 1 byte but whose value is read from a 32-byte word overlaps the next field.
• Byte order / endianness: does the EVM side use the byte order the destination VM expects (Solana little-endian vs EVM big-endian for integers)?
• Field count / order: does the produced struct have the same number of fields, in the same order, as the destination's expected layout (and as the matching decoder, if round-tripped)?

Step 3 — Trace the consequence of any mismatch

If a field is mis-encoded, which destination-side value is corrupted — an account permission (writable/signer), a token/program address, an amount, or a recipient? A mismatch that reaches any of those is a confirmed finding (corrupted cross-chain execution / permission / value), severity per impact×likelihood. A mismatch in a purely cosmetic field is Low/Informational. Report the encoding-conformance root cause distinctly even if an adjacent bounds-check or value-binding finding already touches the same encoder.

Step Execution Checklist (MANDATORY)

Integration Point

Appended (via the driver's mechanical skill injection) to the cross-chain/encoding breadth agent and depth-external when NON_EVM_TARGET is set. Not always-on — only for protocols that serialize for a foreign VM.