The approval the application minted for exactly this request.

Registry-mode shape for this module’s shared fold fixture (#157): the request books "42" at edge 1 — so the fixture describes a real edge of seven-admitted-edges instead of the pre-#157 “any bytes” registry. Every Modify row below therefore refuses for ITS OWN reason rather than at the leaf codec.

The +1 active the booking entails, and the output it must land in.

The root after the booking folds.

An enterprise payment-key address, as destination carries it.

The destination of a request that names none (#157 request-destination-binding): the requests in this module exercise the cage’s non-registry paths — minting, contribute, retract, sweep, rejection — none of which moves a token to a destination. The registry-mode rows build their own.

Unit tests and validator-level property tests for the MPF Cage validator.

This is a test module (no pub exports), which allows it to import the cage validator directly via qualified syntax: cage.mpfCage.spend(...).

Test Fixture Layout

All tests share a common set of constants that simulate a minimal cage scenario:

• Time phases: process_time = 10s, retract_time = 10s, submitted_at = 0

  • Phase 1 (oracle processing): [0, 10_000) — validity range [0, 5_000]
  • Phase 2 (requester retract): [10_000, 20_000) — validity range [10_000, 15_000]
  • After the windows: [20_000, …) — validity range [20_000, 25_000]

• State UTxO (update): holds testToken at testScriptAddress with an empty MPF root (no owner field exists).

• Request UTxO (request): an edge-1 (insertActive) request targeting testToken, submitted at time 0.

• Expected output (output): the State UTxO after processing the Insert, with the computed MPF root.

The four policies the eight-field State pins (#157 state-datum-fields). The active policy keeps the 0xaa bytes the representative policy had, so the preservation rows that used 0xbb for the altered case still read the same way; the application, absent and terminal policies are the three the ticket adds.

The delivery output for the fee fixture: its request carries 2 ADA against a 500_000 tip, so the deposit the fold returns is the difference — 2_000_000 less the 500_000 testFee (#157 request-deposit-returned). The zero-tip variant: the whole 2 ADA rides back to the destination.