[HIGH] EXPECTED_SLAB_VERSION = 16 but the deployed wrapper writes 17 — any integrator gating on it rejects every live account

[0x-SquidSol]

Summary

EXPECTED_SLAB_VERSION is 16. The deployed wrapper writes and hard-checks 17, so anything gating on this constant rejects every live account.

src/abi/instructions.ts:504:

export const EXPECTED_SLAB_VERSION = 16;

Its own doc block describes it as "stored as u16 LE at byte offset 8 of every percolator-owned account" — right about where, wrong about what.

The program

percolator-prog/src/v16_program.rs:51:

pub const VERSION: u16 = 17;

written into data[8..10] by write_header (:1445), and check_header (:1461) rejects any mismatch with PercolatorError::InvalidVersion.

Verified against the live chain

getProgramAccounts on the deployed devnet wrapper DhSkE7uTb8HBUYYWF1xkxMYBGtLYJEoDq1tfBD7SnHcj, reading bytes 8..10 of each account:

live devnet wrapper-owned accounts: 206
version at bytes 8..10 -> {17: 204, 0: 2}

204 of 206 are version 17. The two zeros are uninitialised. None is 16.

Impact

Nothing inside this SDK consumes the constant, so no test fails and no in-repo behaviour changes. But it is a public export, and an integrator using it as a guard rejects every account the deployed wrapper has ever written.

percolator-nft hit this exact class already and had to be patched for it — commit 3e26fe7, "fix(nft): accept wrapper VERSION 17 (protocol-fee/taker-only layout)". This is the same drift, still present in the SDK.

The adjacent V17_SLAB_MAGIC (:510) is correct — I checked the magic bytes on-chain (00 36 31 56 43 52 45 50), so only the version is wrong.

Fix

One line: 16 → 17, plus a test pinning it against a real account layout so it cannot drift again silently.

[dcccrypto]

CONFIRMED, and this one is the highest-impact of the drift cluster. Fixed in #380.

EXPECTED_SLAB_VERSION = 16 while the deployed wrapper writes 17. Every SDK consumer that validates the version before decoding rejects every live slab — so the failure is total for integrators, not partial.

Bumped to 17, verified against the deployed wrapper (e8acd708, engine 9483ee90), not main.

Worth noting why this survived: the SDK's own tests were self-consistent — they constructed fixtures at version 16 and asserted they parsed. A test suite that builds its own inputs cannot detect a constant that disagrees with production. The check that catches this class is a parity gate against deployed bytes, which is exactly what #375 is about.