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 Sophie vs Cole 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 Sophie vs Cole 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.

The transaction validity interval is too far into the future.

Transactions with Zerepoch scripts need to have a validity interval that is not so far in the future that we cannot reliably determine the UTC time corresponding to the validity interval expressed in slot numbers.

This is because the Zerepoch scripts get given the transaction validity interval in UTC time, so that they are not sensitive to slot lengths.

If either end of the validity interval is beyond the so called "time horizon" then the consensus algorithm is not able to reliably determine the relationship between slots and time. This is this situation in which this error is reported. For the Bcc mainnet the time horizon is 36 hours beyond the current time. This effectively means we cannot submit check or submit transactions that use Zerepoch scripts that have the end of their validity interval more than 36 hours into the future.

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.