Given any Head protocol state and the transaction corresponding a protocol transition we should be able to observe this transition correctly even in presence of other valid Hydra Head protocol states in the used lookup utxo.

Given a UTxO with more than one entry, we can split it into two non-empty UTxO.

checkIncrement requires the claimed deposit to be its transaction's first output, so increment resolves exactly that output rather than any output of the deposit transaction. Matching by transaction id alone would build a transaction that cannot validate.

recoverTx spends TxIn depositTxId (TxIx 0), so recover resolves exactly that output. Matching by transaction id alone would read one output's datum and then build a transaction spending a different one.

The commitment a partial fanout puts in the continuing head output must be one over everything the step leaves behind: what it did not distribute.

The on-chain check is A = P_K * A' against the A in the head datum, so the two ways of arriving at A' - removing the distributed outputs from the verified A, or building afresh over the rest - have to agree. This pins them at the call site; AccumulatorSpec only pins the underlying accumulator operations in isolation.

The accumulator commitment in the continuing head output of a partial fanout transaction. Output 0 is the head output; the chunk follows.

Run the action on a selection naming the first two outputs of the given set under each other's TxIn. The head still holds both outputs, so HeadLogic accepts this as a selection, but no TxIn in it resolves to the output it carries.

Deposits ranging from trivially fitting (a few ada-only outputs) to clearly oversized (>100 distinct-policy tokens whose merged value exceeds mainnet's 5000 byte maxValSize), so rejectOversizedDeposit exercises both verdicts.

Use spendableUTxO (not 'getKnownUTxO stClosed'): the generator adds the full UTxO value to the head output so partialFanoutTx can subtract distributed values without going negative. The evaluation UTxO must match.

The spendable UTxO for the final partial fanout is the FanoutProgress head output produced by the preceding partial fanout step, so we use the 3rd element from the generator rather than 'getKnownUTxO stClosed'.