Handle of a mutable local chain state that is kept in the direct chain layer.

Initialize a new local chain state from a given chain state history.

A callback used to actually submit a transaction to the chain.

A way to acquire a TimeHandle

Create a Chain component for posting "real" cardano transactions.

This component does not actually interact with a cardano-node, but creates cardano transactions from PostChainTx transactions emitted by a HydraNode, balancing and signing them using given TinyWallet, before handing it off to the given SubmitTx callback. There is also a draftTx option for drafting a commit tx on behalf of the user using their selected utxo.

NOTE: Given the constraints on m this function should work within IOSim and does not require any actual IO to happen which makes it highly suitable for simulations and testing.

Reject any UTxO containing a Byron address, which cannot be represented in the Hydra head protocol.

Reject deposits which could never be claimed: builds a dry-run increment transaction for the drafted deposit and rejects with DepositTooLarge when it would violate layer 1 ledger limits - the maximum transaction size, or the maximum serialized value size of the merged head output.

Serialized size of a value, computed exactly like the ledger's OutputTooBigUTxO check. NOTE: Keep in sync with validateOutputTooBigUTxO.

Byte headroom added to the unbalanced dry-run increment transaction when comparing against the maximum transaction size, covering what $sel:coverFee:TinyWallet and $sel:sign:TinyWallet add to the real increment: a fee input (~40 bytes), a collateral input (~40 bytes), an ada-only change output (~70 bytes), the script integrity hash (~37 bytes), the fee field (~5 bytes), one key witness (~102 bytes), and wider integer encodings for the estimated execution units, snapshot number and validity slot (~40 bytes) - around 334 bytes in total. We add some overhead and use 512 just to be more safe.

Balance and sign the given partial transaction.

A handler that takes care of following the chain.

Conversion of a slot number to a time failed. This can be usually be considered an internal error and may be happening because the used era history is too old.

Creates a ChainSyncHandler that can notify the given callback of events happening on-chain.

This forms the other half of a ChainComponent along with mkChain but is decoupled from actual interactions with the chain.

A TimeHandle is needed to do `SlotNo -> POSIXTime` conversions for Tick events.

Throws TimeConversionException when a received block's SlotNo cannot be converted to a UTCTime with the given TimeHandle.

Binary search for the largest chunk size in [1..maxChunk] for which tryTx returns Just. Assumes the predicate is monotone: if size n fits, all sizes < n also fit. Uses upper-mid so the search terminates correctly when hi = lo + 1. Returns 'Left ()' if no size fits. tryTx may throw to abort the search early.

Check whether a transaction fits within protocol size and script execution limits. Size check is cheap so it short-circuits before the expensive UPLC evaluation. Structural errors (script failures, protocol parameter conversion errors) are traced via the provided tracer; transient misses (size exceeded, budget overrun) are silent.

Try the preferred transaction first; if it doesn't fit within the script execution budget or exceeds the maximum transaction size, fall back to a binary search over partial fanout chunk sizes. Returns the largest chunk that fits, minimising the number of fanout steps.

Error mapping: * StaleChainState from partialFanout → StalePartialFanoutTx (race condition; HeadLogic silently ignores it and the chain observation loop triggers the correct next step). * Any other PartialFanoutError → FailedToConstructPartialFanoutTx (structural mismatch that will not resolve on retry). * No chunk fits within budget → FailedToConstructPartialFanoutTx (budget exhaustion; also not a race condition).

Maximum delay we put on the upper bound of transactions to fit into a block. NOTE: This is highly depending on the network. If the security parameter and epoch length result in a short horizon, this is problematic.