A class for accessing the known UTxO set in a type. This is useful to get all the relevant UTxO for resolving transaction inputs.

The chain state used by the Hydra.Chain.Direct implementation. It records the actual ChainState paired with a ChainSlot (used to know up to which point to rewind on rollbacks). XXX: could move this into IsChainState and use UTxOType tx instead of ChainStateType tx

Get a generic ChainSlot from a Cardano ChainPoint. Slot 0 is used for the genesis point.

An enumeration of all possible on-chain states of a Hydra Head, where each case stores the relevant information to construct & observe transactions to other states.

Defines the starting state of the direct chain layer.

Read-only chain-specific data. This is different to HydraContext as it only contains data known to single peer.

Construct an init transaction given some general ChainContext, the HeadParameters and a seed TxIn which will be spent.

Construct a increment transaction spending the head and deposit outputs in given UTxO, and producing single head output for pending $sel:utxoToCommit:Snapshot of given Snapshot.

Build an increment transaction claiming a drafted (not yet submitted) deposit transaction against the current head output. The incrementing snapshot is based on the given current confirmed snapshot, as the next snapshot which would commit the drafted deposit. The result can never validate on chain (for an InitialSnapshot base the multi-signature is fabricated, otherwise the current snapshot's signatures do not cover the fabricated snapshot), but is byte-accurate in every component that matters for size estimation: script witnesses, datum layout, one 64-byte signature per party in the redeemer, and the merged head output value. The head seed, parties and periods are decoded from the current head output's inline datum.

Decode head seed and parameters from the inline datum of a head output.

Possible errors when trying to construct decrement tx

Construct a decrement transaction spending the head output in given UTxO, and producing outputs for all pending $sel:utxoToDecommit:Snapshot of given Snapshot.

Construct a recover transaction spending the deposit output and producing outputs the user initially deposited.

Construct a close transaction spending the head output in given UTxO, head parameters, and a confirmed snapshot. NOTE: Lower and upper bound slot difference should not exceed contestation period.

Construct a contest transaction based on the ClosedState and a confirmed snapshot. The given PointInTime will be used as an upper validity bound and needs to be before the deadline.

Construct a fanout transaction based on the ClosedState and off-chain agreed UTxO set to fan out.

Errors that can occur when constructing partial or final-partial fanout transactions.

Construct a partial fanout transaction that distributes a subset of UTxOs. Handles both first step (Closed → FanoutProgress) and intermediate steps (FanoutProgress → FanoutProgress) by detecting the current on-chain datum type. The first chunkSize UTxOs from remainingUTxO are distributed; the rest become the new remaining set.

Construct the final partial fanout transaction that distributes all remaining UTxOs and burns all head tokens. Reads FanoutProgressDatum from the head output.

Read and decode the head state from a head script output.

Build an accumulator from the given UTxO and verify its commitment matches the one in the on-chain datum. Returns the accumulator for reuse by the caller. Fails with StaleChainState if the commitments differ.

Define some global context from which generators can pick values for generation. This allows to write fairly independent generators which however still make sense with one another within the context of a head.

For example, one can generate a head's _party_ from that global list, whereas other functions may rely on all parties and thus, we need both generation to be coherent.

Do not use this in production code, but only for generating test data.