- Neither reader had a single test. Both scan box names by prefix, so a contract-side prefix change made them return [] with nothing going red — and `getVoters` feeds the frontend's voter list, so that silence reached the UI.

- `getVoters` asserts empty before any vote, then exactly the govs who voted. The period's 'o'/'t' boxes already exist at that point, so it also pins that the 'v' filter excludes them.

- Verified by sabotage: flipping 'v' to 0x77 and 'a' to 'b' fails both.

- Converges frac-delegation-sdk on ggov-sdk's style. `instanceBoxName` was deriving prefix + key encoding from the ARC-56 spec at call time; it now hardcodes 'i' + big-endian uint16, matching gGov's `periodBoxName`/`topicBodyBoxName`. Drops the ABIType, APP_SPEC and Buffer dependencies from the util.

- New `smart_contracts/boxNames.spec.ts` derives the expected bytes from the compiled specs and compares them against every helper, at 0 / 1 / key-type max. Deriving there and nowhere in the SDKs is what makes drift visible. Plain `.spec.ts`, no contract code and no chain.

- Also guards the cross-app near-collision: the period app's `periodBody` key is 'P', the registry's `periodApprovalBox` key is 'Pap'. Same leading byte, different apps, and `asciiBoxName` is single-byte by construction.

- Stops four places re-implementing the helpers by hand — `getPeriodBody` and `getTopicBody` in ggov-sdk's period reader were building 'P' and 'T' + uint32 inline, and both vote e2e tests were assembling the expected box name byte by byte. The e2e tests keep their own job: proving the ref is emitted on both the top-up and no-top-up branches.

Analogous to fractional delegation. Same registry as a vault + MBR post-condition pattern.

- `makeVoteTxns` now names the frac registry app and its `instances` box on every vote, top-up or not, given the state-conditional inner call on `checkNeedMBR`.

- Ref-slot padding goes `numEscrows * 5 + 20` -> `+ 21` for the extra box.

- `extraFee` is deliberately unchanged. Both MBR hops pay their own fee, so the voter's group fee is invariant to whether the top-up fires.

- New `instanceBoxName` in util/boxes.ts, deriving prefix and key encoding from the ARC-56 spec rather than hardcoding 'i' + uint16.

- Test coverage includes regression-like cases for the whole MBR top-up flow.

- The registry becomes an MBR vault. `vote()` ends with `checkNeedMBR()` subroutine: if the instance app account is at or below its minimum balance, it inner-calls the registry's new `requestMBR`, which pays it `mbrTopUp` (new global, 5 A, settable via `setMBRTopUp`). Users never pay vote-record MBR, and instances no longer need hand-funding.

- Post-condition, not a threshold. The AVM updates `min_balance` the instant a box is allocated but enforces the requirement only after each (outer) transaction, so the account may sit underwater mid-execution as long as the top-up lands first. However, MBR do is enforced between intermediate states of a group transaction, so a sibling payment later in the same group would be too late.

Nits: `checkNeedMBR()` could sit in more than one place:
- periodVoteCache is always an overwrite, so the call could go before it
- on a re-vote the record write is an overwrite too, so the call could be skipped

Left plain at the end for clarity; the saving would be a handful of opcodes. What is not flexible is that it must stay after the vote record write - that write is the allocation it repairs.

Corrects the note added earlier on this branch, which was misleading in three
ways. All three were found by follow-up verification and adversarial review
after that note was written.

1. It said the pin is "several commits behind main" without the decisive fact:
   go-algorand's go.mod requires github.com/algorand/falcon v0.1.0, and that
   tag dereferences to exactly ce15e75b. It is the repo's ONLY tag. The pin is
   alignment with the code defining on-chain falcon_verify behaviour - which is
   the point for a signer whose output must be accepted by that verifier.
   main (956d9bc0) is 7 ahead / 0 behind, and UNRELEASED.

2. It called the PR #16 change "a malleability gap". Wrong term. Signature
   malleability means distinct valid signatures for one (key, message) pair;
   that does not occur on either build. It is non-canonical input acceptance in
   a parser. The original wording would have pointed an auditor at the wrong
   invariant.

3. It warned that TRELYAN's off-chain accept/reject "can diverge from what the
   chain accepts". Misleading: falcon_det1024_convert_compressed_to_ct is not
   bound by this SDK at all - trelyan_pq.falcon binds only
   shake256_init_prng_from_system, keygen, sign_compressed and
   verify_compressed. The affected function is unreachable from TRELYAN. It IS
   reachable in go-algorand via GetFixedLengthHashableRepresentation ->
   ConvertToCT, making it an upstream report rather than a local divergence.

Also records that bumping was tested, not assumed: both trees built with
FALCON_FPEMU=1 and compared over 120 signatures (12 keypairs x 10 message
shapes) plus the committed KAT - byte-identical throughout, each build
accepting the other's output. A bump would be safe but would make this repo
stricter than the deployed verifier for no reachable benefit.

Adds the more precise description of the underflow: sig_compressed_len - 2
wraps to SIZE_MAX on a 1-byte input, so the decoder receives a pointer past the
buffer with a claimed length of 2^64-1.

Docs only. Pinned commit and both digests unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>