Compute the transaction fee for a proposed transaction, with the assumption that there will be the given number of key witnesses (i.e. signatures).

Use calculateMinTxFee if possible as that function is more accurate.

Estimate minimum transaction fee for a proposed transaction by looking into the transaction and figuring out how many and what kind of key witnesses this transaction needs.

It requires access to the portion of the UTxO that is relevant for this transaction in order to lookup any txins included in the transaction.

The only type of witnesses that it cannot figure out reliably is the witnesses needed for satisfying native scripts included in the transaction.

For this reason number of witnesses needed for native scripts must be supplied as an extra argument.

Give an approximate count of the number of key witnesses (i.e. signatures) a transaction will need.

This is an estimate not a precise count in that it can over-estimate: it makes conservative assumptions such as all inputs are from distinct addresses, but in principle multiple inputs can use the same address and we only need a witness per address.

Similarly there can be overlap between the regular and collateral inputs, but we conservatively assume they are distinct.

TODO: it is worth us considering a more precise count that relies on the UTxO to resolve which inputs are for distinct addresses, and also to count the number of Shelley vs Byron style witnesses.

Compute the ExecutionUnits needed for each script in the transaction.

This works by running all the scripts and counting how many execution units are actually used.

The different possible reasons that executing a script can fail, as reported by evaluateTransactionExecutionUnits.

The first three of these are about failures before we even get to execute the script, and two are the result of execution.

TODO: We should replace ScriptWitnessIndex with ledger's PlutusPurpose AsIx ledgerera. This would necessitate the parameterization of ScriptExecutionError.

Compute the total balance of the proposed transaction. Ultimately a valid transaction must be fully balanced: that is have a total value of zero.

Finding the (non-zero) balance of partially constructed transaction is useful for adjusting a transaction to be fully balanced.

Use when you do not have access to the UTxOs you intend to spend

This is much like makeTransactionBody but with greater automation to calculate suitable values for several things.

In particular:

• It calculates the correct script ExecutionUnits (ignoring the provided values, which can thus be zero).
• It calculates the transaction fees, based on the script ExecutionUnits, the current ProtocolParameters, and an estimate of the number of key witnesses (i.e. signatures). There is an override for the number of key witnesses.
• It accepts a change address, calculates the balance of the transaction and puts the excess change into the change output.
• It also checks that the balance is positive and the change is above the minimum threshold.

To do this it needs more information than makeTransactionBody, all of which can be queried from a local node.

The possible errors that can arise from makeTransactionBodyAutoBalance.