- 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.

pnpm audit --audit-level=high was failing on:

- nanoid <3.3.18 (GHSA-2v37-7h3g-55p8, "custom generators can loop
  indefinitely when size is zero") -> 3.3.17 bumped to 3.3.18

nanoid is only in the tree transitively via postcss (>vite>vitest etc.),
whose ^3.3.11 range already admits the fix, so this is a lockfile-only
bump with no override — same as the previous 3.3.16 -> 3.3.17 bump.
3.3.18 was published 2026-08-07 and is now past the workspace
minimumReleaseAge, so no exclude is needed either.

pnpm install --frozen-lockfile and pnpm audit --audit-level=high verified
locally (0 high; 4 low / 5 moderate remain, below the threshold).

- `/manage/period/$periodId` now has two faces. Edit is opt-in via `?mode=edit`; View is the absence of that param, and `validateSearch` normalizes any other value to View. A View/Edit toggle sits in the header, hidden when there is no wallet or the period is frozen.

- Every write affordance now gates on one flag: `showEditControls`, defined as connected SDK + `mode === 'edit'` + `editable`. `editable` now means the period is not frozen, based on readiness and votes. This replaces the previous status-based definition.

- Dropped the `status === 'upcoming'` condition. The contract's `editPeriod` only asserts operator, `!ready`, and `end > start`, so a draft whose voting window is active or has passed is still editable on chain.

- A ready period with no votes cast is still editable because it can be reverted to draft. It keeps edit controls live in Edit mode and shows a warning that changes will fail until it is reverted. The contract, not the UI, rejects those writes.

- Added `src/utils/periodEditing.ts` with shared `periodHasVotes` and `periodFrozen`, used by the list and detail page. A ready period with votes cast is frozen, so it gets no Edit affordance and no View/Edit toggle.

- Manage periods list: the title cell links to View, and the actions column holds a single button per row: Edit, or View for a frozen period.

- Misc: the Upcoming status chip no longer uses `bg-accent`; it now uses a custom soft pink so it is visually distinct from Ended. This intentionally uses a Tailwind color outside the design tokens because it only appears in the operator-only Manage UI.

feat: enforce Abstain as the last topic option

- Mirror the GT_OA rule from `ensureValidOptions` in the manage panel, so an operator cannot build an option list the contract will reject.

- There's a fixed row with "Abstain" option, locked and without move/remove controls. Both editors hold only the custom options and append Abstain at call time.

- Frontend is even stricter than the contract: enforces `MIN_CUSTOM_OPTIONS=2` (at least two non-abstain options) and rejects an operator-typed Abstain in any casing.

- Create a new utils file for topic options to centralize validation for add/edit topic options. Also adds the missing duplicate-option check to AddTopic.

chore: /docs wording

There are TWO arrows out of the committed artifact, not one, and neither was
checked:

    contracts/out/TrelyanInscription.*
        |  algod compile                |  algokit generate client
        v                               v
    bytecode ==? chain              contracts/trelyan_client.py

The client branch matters more than it looks. contracts/trelyan_client.py is an
89 KB generated file stamped "DO NOT MODIFY IT BY HAND", and the LocalNet suite
deploys the committed TEAL and drives it THROUGH that client. CI only ever
consumes it; nothing regenerated it and compared. A contract whose ABI moved
without the client being regenerated would be exercised by a suite talking to
the old interface -- and the suite would pass.

CHECKED WITHOUT RUNNING THE GENERATOR, DELIBERATELY

`algokit generate client` needs algokitgen-py, which would pin this check to a
generator version whose formatting churn is not a finding. It is also, on the
machine this was written on, blocked outright by a Windows Application Control
policy (os error 4551) -- the same policy that currently blocks cargo-deny.

No generator is needed: the client EMBEDS the full spec it was generated from,
in _APP_SPEC_JSON. Comparing that to the committed arc56.json needs nothing but
the two committed files, runs anywhere, and is stable across generator versions.

The comparison is on PARSED JSON rather than bytes, because the client embeds
the spec minified while arc56.json is pretty-printed -- a byte comparison would
fail always and therefore mean nothing.

Failure reporting distinguishes an ABI-method change (names differ; the suite is
testing a different interface) from a signature/struct/metadata change (names
agree), because those read very differently to a reviewer.

VERIFIED

  - clean tree: all five artifacts plus the client in step, exit 0
  - rename a method inside the client's embedded spec: CLIENT DRIFT, exit 1,
    naming both method lists
  - a missing _APP_SPEC_JSON block is reported as "repair the check", not
    silently passed -- if the generator's output shape changes, this check stops
    reading what it thinks it reads, and that is a finding about the check

HIGH. `falcon_det1024_verify_compressed` takes NO pubkey length parameter:
deterministic.c calls falcon_verify(..., pubkey, FALCON_DET1024_PUBKEY_SIZE,
...), so it reads exactly 1793 bytes from that pointer regardless of what the
caller allocated. `sig` and `message` are length-delimited and bounded; pubkey
alone was not.

FalconDet1024.verify() passed pubkey straight through as a bare c_char_p with
no check, so a shorter buffer read up to 1729 bytes past the end. Reachable
from the shipped public API -- trelyan_pq.verify is exported from __init__ --
so a verifier reading a pubkey from an arbitrary box or file could crash, or
compute a verdict partly from unrelated adjacent heap memory.

Proved with a guard page (two pages, only the first committed, payload flush
against the boundary):

  full 1793-byte pubkey -> returns cleanly, reads exactly 1793
  1792-byte pubkey      -> ACCESS VIOLATION at the first byte past the buffer
  64-byte pubkey        -> ACCESS VIOLATION

The one-byte-short case is the one that matters: it is the realistic
truncation. Reaching it needs no valid signature -- junk bytes with the right
two header values get there.

The asymmetry is what marks it an oversight rather than a decision: sign() has
always checked len(privkey) != PRIVKEY_SIZE. verify() checked nothing.

WHY NOTHING CAUGHT IT, which is the part worth keeping:

  * tests/fuzz/fuzz_falcon_verify.cc (C/ASan, 13.8M execs) DOCUMENTS this exact
    invariant and honours it -- it always hands the function a fixed 1793-byte
    buffer, and its comment calls a smaller one "a caller-side over-read -- a
    harness bug, not a finding". Correct, and it means that harness could never
    surface this by construction.
  * tests/fuzz/fuzz_encoding_atheris.py DID feed short pubkeys and asserted
    verify() "must return False, not raise" -- an assertion the code could not
    satisfy, because it crashed instead. That file is referenced by no
    workflow, so it has never run.
  * No test varied pubkey length; the KAT and fuzz suites vary the signature
    only, always with a full-size key.

The invariant was written down in one file, violated in another, and the
harness that would have caught it was never wired up.

Fixed in BOTH copies. contracts/falcon_det1024.py is the one deploy_testnet.py
signs real TestNet inscriptions with, and fixing only the SDK is exactly how
TCE-03's cwd hijack survived its first fix.

Raises rather than returning False, matching sign(): a mis-sized key is a
caller error, not a failed verification, and returning False would let a
truncated key read as "signature invalid". The Atheris harness's contract is
corrected to expect that, with the reason recorded inline.

9 regression tests, none needing the C library so they run everywhere.
Mutation-proved: removing either guard fails all 9. SDK suite 50 -> 59 passed,
19 skipped.

Security impact: closes a memory-safety defect reachable from the public API of
an audit-bound crypto SDK. No protocol, wire-format or on-chain change; the
contract's own ABI already pins committed_pubkey to 1793 bytes, so on-chain
state was never the exposure -- the off-chain verifier path was.