Fault P3 from the crash-refund review, reproduced by a5851fba3: a
standing grant's MintLedger could not be rebuilt from anything the
enforcement point kept. A firing sealed no receipt, a child never
exercised left no trace, and the type's doc named default() as the
genesis, so a ledger reading fewer fires than happened looked like one
that fired less. A restart from a ledger persisted after the first of
three firings fired two more past max_fires.
Each firing is now a decision sealed as a receipt. It is an allow on the
standing grant with action mint, cost 0, the mint policy's id as
resource and the trigger event's payload id as payload_hash, and it
states minted_uj, the budget the child carries: one new signed member of
the jcp/2 core. ReceiptLog::append_mint seals it, and the enforcement
point records it before the child leaves (SPEC §4.6, §4.11). A firing
debits nothing and accrues nothing, and group accounting does not count
it as an action; the child's own receipts debit what its work spends.
jcp_receipt::replay_mints lists a stream's firings, and
MintLedger::of_firings rebuilds the ledger from them: one fire each, and
their minted_uj summed. MintLedger::restore applies a stored copy beside
it, keeping the higher count and the higher spend, so neither a stale
copy nor a short stream hands a firing back. A refusal stating
minted_uj fires nothing (C3).
No receipt sealed before this changes its bytes or how it reads. SPEC
§8.1 states that streams sealed before minted_uj hold no record of
firings, so an enforcement point restoring one keeps the ledger it
stored beside the rebuilt one, or holds the standing grant as fired out.
§8.2 leaves firings out of group accounting, and §8 lists the member.
Conformance: replay.json gains three entries at its end, two firings of
one standing grant with a call by their child between them, per-entry
mints figures and a mints_after total, all taken from the MintLedger
the firings advanced, not from the receipts. The 23 existing entries and
the 5 legacy receipts keep their bytes. verify_replay.py reads firings,
checks mints_after, and refuses a changed minted_uj, changed totals and
four more planted reader faults. C20 now seals each firing and checks
that a restart from a stale ledger, restored beside the stream, stays
rate-limited. replay_pack reads the firings through the library.
The P3 test moves from jcp-grant, which cannot seal receipts, to
jcp-receipt's replay_debits.rs. It keeps its name and its fault
assertion, its restart now restores from the stream as well as the
persisted ledger, and it no longer carries should_panic. jcp-grant keeps
a unit test of the restore direction.
Changelog: none
Co-Authored-By: Claude Opus 5.5 <[email protected]>
fa478e003b