Fields

• txSkelOptAutoSlotIncrease :: Bool

  Whether to increase the slot counter automatically on transaction submission. This is useful for modelling transactions that could be submitted in parallel in reality, so there should be no explicit ordering of what comes first.

  Default is True.

• txSkelOptModTx :: Tx ConwayEra -> Tx ConwayEra

  Applies an arbitrary modification to a transaction after it has been potentially adjusted and balanced. The name of this option contains unsafe to draw attention to the fact that modifying a transaction at that stage might make it invalid. Still, this offers a hook for being able to alter a transaction in unforeseen ways. It is mostly used to test contracts that have been written for custom PABs.

  One interesting use of this function is to observe a transaction just before it is being sent for validation, with

  txSkelOptModTx = [RawModTx Debug.Trace.traceShowId]

  The leftmost function in the list is applied first.

  Default is [].

• txSkelOptBalancingPolicy :: BalancingPolicy

  Whether to balance the transaction or not, and which user should provide/reclaim the missing and surplus value.

  If you decide to set txSkelOptBalance = DoNotBalance you will have trouble satisfying the balancing equation by hand unless you use ManualFee.

  Default is BalanceWithFirstSignatory

• txSkelOptFeePolicy :: FeePolicy

  The fee to use when balancing the transaction

  Default is AutoFeeComputation

• txSkelOptBalanceOutputPolicy :: BalanceOutputPolicy

  The BalanceOutputPolicy to apply when balancing the transaction.

  Default is AdjustExistingOutput.

• txSkelOptBalancingUtxos :: BalancingUtxos

  Which UTxOs to use during balancing. This can either be a precise list, or rely on automatic searches for utxos with values only belonging to the balancing user.

  Default is BalancingUtxosFromBalancingUser.

• txSkelOptModParams :: Params -> Params

  Apply an arbitrary modification to the protocol parameters that are used to balance and submit the transaction. This is obviously a very unsafe thing to do if you want to preserve compatibility with the actual chain. It is useful mainly for testing purposes, when you might want to use extremely big transactions or transactions that exhaust the maximum execution budget. Such a thing could be accomplished with

  txSkelOptModParams = Just $ ModParams increaseTransactionLimits

  for example.

  Default is Nothing.

• txSkelOptCollateralUtxos :: CollateralUtxos

  Which utxos to use as collaterals. They can be given manually, or computed automatically from a given, or the balancing, user.

  Default is CollateralUtxosFromBalancingUser

• txSkelOptDeferPhase2FailuresDuringBalancing :: Bool

  Whether to defer validation failures occurring during balancing (specifically during the computation of execution units) to the actual later submission of the transaction.

  When set to False: the phase 2 validation failures will be caught as early as possible, typically during balancing when the execution units are computed. This will shortcut the whole balancing process which iterates the body generation, and thus increase performances (by 40%). As a result, the balanced TxSkel will never be computed and thus will be absent from the log, which is the only downside.

  When set to True: the phase 2 validation erros will be ignored during the balancing process. This will result in a worst performance (40%), but will allow the log to display a balanced version of the failing TxSkel, which might be useful. Only use this when debugging complicated phase 2 failures which require a precise view of the balanced TxSkel sent for validation.

  Default is False

• txSkelOptMaxNbOfBalancingUtxos :: Maybe Integer

  The optional maximum number of Utxos that can be used during balancing. The algorithm which selects Utxos when permorming balancing is greedy. In the default use case where the are only a few wallets and Utxos (the most common case for testing purpose), this is fine. However, if the amount of candidate Utxos is big (let's say, bigger than 15), this is problematic. Use this option to limit the number of Utxos that can be used during the balancing process.

  Alternatively, this can also be used to pilot balancing in some way. For instance, setting this option to Just 1 will result in a single Utxo added in the inputs of the transaction, if such a Utxo exist.

  Default is Nothing