a. why a binary tree instead of a flat published list

A flat list of every wallet and amount owed would be provable, but it would not scale. Publishing thousands of entries on chain, or requiring a claimant to submit the entire list for verification, grows in cost linearly with the number of wallets ever entitled to anything. A binary tree reduces what a claimant must submit to roughly the base two logarithm of the number of entries. A million entries requires about twenty supporting hashes. The root itself stays a fixed 32 bytes regardless of the epoch's size.

b. what a verified proof actually establishes

A verified proof establishes one specific fact. That a given wallet and amount pair was one of the leaves that produced the published root. It does not establish that the entitlement data used to build the tree was calculated fairly or derived the way it claims to have been derived. That guarantee depends entirely on whether the entitlement rule is something any third party can independently recompute from public on chain history. This is the actual limit of what a merkle proof can promise on its own, and it is stated here directly.

c. why rollover subtracts two stored totals instead of scanning individual claims

Computing the unclaimed remainder as total pool minus claimed total, both already tracked on the epoch account, keeps rollover constant in cost regardless of how many or how few claims were made during that epoch. This requires claimed total to be incremented correctly and only through the claim instruction, which is why a separate claim record exists for every wallet within every epoch. It makes double claiming structurally impossible rather than something enforced through bookkeeping discipline.

d. the minimum epoch length

The constant governing minimum epoch length exists so an epoch cannot be closed moments after opening, leaving no realistic window for anyone to claim before the following epoch's rollover absorbed whatever remained unclaimed. This value is fixed at genesis. No instruction can shorten or lengthen it after deployment.

e. what publish root and rollover cannot do

Neither instruction lets the caller choose the contents of the root, the size of the unclaimed remainder, or which wallets were entitled within an epoch. Both are fully determined by data computed before the call. The only thing a caller contributes is timing, submitting the transaction once the required condition has been met, in exchange for a fixed reward.

f. known limits

A published root represents only the entitlement data that existed at the moment it was computed. There is no instruction that revises a published root, even to correct an error made while building the tree off chain. This is treated as intentional. A root that could be revised after publication would not function as a root. It would function as a claim awaiting confirmation. Anyone constructing entitlement data for root has to get it right before publishing, because after that point it is permanent.