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).

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

A definition of all transitions between ChainStates. Enumerable and bounded to be used as labels for checking coverage.

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.

Representation of the Head output after an Init transaction.

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

Construct a commit transaction based on known, spendable UTxO and some arbitrary UTxOs to commit. This does look for "our initial output" to spend and check the given UTxO' to be compatible. Hence, this function does fail if already committed or if the head is not initializing.

NOTE: This version of commit does only commit outputs which are held by payment keys. For a variant which supports committing scripts, see commit'.

Construct a commit transaction based on known, spendable UTxO and some user UTxO inputs to commit. This does look for "our initial output" to spend and check the given UTxO' to be compatible. Hence, this function does fail if already committed or if the head is not initializing.

NOTE: A simpler variant only supporting pubkey outputs is commit.

Construct a abort transaction based on known, spendable UTxO. This function looks for head, initial and commit outputs to spend and it will fail if we can't find the head output.

Construct a collect transaction based on known, spendable UTxO. This function looks for head output and commit outputs to spend and it will fail if we can't find the head output.

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.

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.

Observe an init transition using a InitialState and observeInitTx.

Observe an commit transition using a InitialState and observeCommitTx.

Observe an collect transition using a InitialState and observeCollectComTx. This function checks the head id and ignores if not relevant.

Observe a close transition using a OpenState and observeCloseTx. This function checks the head id and ignores if not relevant.

Maximum number of parties used in the generators.

Generate a ChainContext and ChainState within the known limits above, along with a transaction that results in a transition away from it.

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.

Generate a HydraContext for a arbitrary number of parties, bounded by given maximum.

Generate a HydraContext for a given number of parties.

Get all peer-specific ChainContexts from a HydraContext. NOTE: This assumes that HydraContext has same length $sel:ctxVerificationKeys:HydraContext and $sel:ctxHydraSigningKeys:HydraContext. XXX: This is actually a non-monadic function.

Pick one of the participants and derive the peer-specific ChainContext from a HydraContext. NOTE: This assumes that HydraContext has same length $sel:ctxVerificationKeys:HydraContext and $sel:ctxHydraSigningKeys:HydraContext.

Unsafe version of close that throws an error if the transaction fails to build.

Unsafe version of contest that throws an error if the transaction fails to build.