registry/modify

The Modify decision: whether a fold of the registry’s state is valid, and if not, the one reason why (#157 leaf-codec-and-operations–request-covers-tip, #253).

Responsibility

validFold checks, in this order: the continuation output (continuation-address, state-token, state-drain) and the preserved pins (pins-altered); then runs the fold over the transaction’s inputs (registry/fold) and judges its result (empty-fold, surplus-actions, root, the mint delta); then discharges the collected duties (registry/discharge) and settles the lovelace they owe (registry/settlement). The first failing check is the answer.

Dependencies

Imports registry/fold, registry/discharge, registry/settlement, registry/refusal, lib (exact quantity, the mint refusal) and types. Imported by state, whose spend handler and modifyRefusal identify the state input and call it. Nothing below imports it.

Assumptions

• input is the state input being spent, carrying pins, and policyId and tokenId are its script and the one state token it holds, as state establishes before calling.
• The transaction’s first output is the continuation and carries an inline state datum; otherwise the decision crashes rather than refusing.

Invariants

• The answer is None or exactly one reason, so the spend handler traces exactly one user-defined trace for a refused fold.
• Continuation and pin checks precede everything the batch says; the fold’s own refusal precedes the batch-level checks; every duty is discharged before any lovelace is settled; positional rejected-request refunds precede the per-payee sums.
• The seven non-root state fields are equal before and after every fold, and the mint under the three pinned token policies equals the summed edge deltas exactly.