For a concrete fully-constructed transaction, determine the minimum fee that it needs to pay.

This function is simple, but if you are doing input selection then you probably want to consider estimateTransactionFee.

This can estimate what the transaction fee will be, based on a starting base transaction, plus the numbers of the additional components of the transaction that may be added.

So for example with wallet coin selection, the base transaction should contain all the things not subject to coin selection (such as script inputs, metadata, withdrawals, certs etc)

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

TODO: we need separate args for Shelley vs Byron key sigs

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.

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.

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.