Documentation

Whether to adjust a potentially existing output to the balancing wallet with the change during transaction balancing.

What fee policy to use in the transaction.

Whether to balance the transaction or not, and which wallet to use to provide outputs for balancing. Either the first signer or an explicit wallet. In the second case, this wallet must be a signer of the transaction.

Which UTxOs to use when balancing. Note that utxos that are already known by the skeleton being balanced (in the sense of txSkelKnownTxOutRefs, i.e. inputs and reference inputs) will be filtered out during balancing.

Wraps a function that will be applied to a transaction right before submission, and after balancing.

Wraps a function that will temporarily change the emulator parameters for the transaction's balancing and submission.

Describe which UTxOs to use as collaterals

Describes how to resolve anchors in proposal procedures

Applies a list of modifications right before the transaction is submitted. The leftmost function in the argument list is applied first.

Set of options to modify the behavior of generating and validating some transaction.

A description of what a transaction mints. For every policy, there can only be one TxSkelRedeemer, and if there is, there must be some token names, each with a non-zero amount of tokens.

You'll probably not construct this by hand, but use txSkelMintsFromList.

Add a new entry to a TxSkelMints. There are a few wrinkles:

1. If for a given policy, redeemer, and token name, there are n tokens in the argument TxSkelMints, and you add -n tokens, the corresponding entry in the "inner map" of the policy will disappear (obviously, because all of its values have to be non-zero). If that also means that the inner map becomes empty, the policy will disappear from the TxSkelMints altogether.
2. If a policy is already present on the argument TxSkelMints with a redeemer a, and you add a mint with a different redeemer b, the old redeemer is thrown away. The values associated with the token names of that policy are added as described above, though. This means that any pre-existing values will be minted with a new redeemer.

If, for some reason, you really want to generate a TxSkelMints that has both a negative and a positive entry of the same asset class and redeemer, you'll have to do so manually. Note, however, that even if you do so, NO VALIDATOR OR MINTING POLICY WILL EVER GET TO SEE A TRANSACTION WITH SUCH CONFLICTING INFORMATION. This is not a design decision/limitation of cooked-validators: The Cardano API TxBodyContent type, that we're translating everything into eventually, stores minting information as a minted value together with a map from policy IDs to witnesses (which represent the used redeemers). That means that we can only store _one_ redeemer per minting policy, and no conflicting mints of the same asset class, since they'll just cancel.

Convert from TxSkelMints to a list of tuples describing eveything that's being minted.

Smart constructor for TxSkelMints. This function relies on addToTxSkelMints. So, some non-empty lists (where all amounts for a given asset class an redeemer add up to zero) might be translated into the empty TxSkelMints.

Another smart constructor for TxSkelMints, where the redeemer and minting policies are not duplicated.

The value described by a TxSkelMints

On transaction outputs, we have the options to use

1. no datum
2. only a datum hash
3. a "normal" datum
4. an inline datum

These four options are also what the type TxSkelOutDatum records. The following table explains their differences.

That is:

• Whenever there is a datum, we'll store it in the state of our simulated chain. This will make it possible to retrieve it later, using functions such as datumFromHash.
• Both of the TxSkelOutDatumHash and TxSkelOutDatum constructors will create an output that scripts see on the txInfo as having a datum hash. The difference is whether that hash will be resolvable using validator functions like findDatum.

Transaction outputs. The Pays constructor is really general, and you'll probably want to use one of the smart constructors like paysScript or paysPK in most cases.

Pay a certain value to a public key.

Pays a script a certain value with a certain datum hash, using the TxSkelOutDatum constructor. The resolved datum is provided in the body of the transaction that issues the payment.

Pays a script a certain value with a certain inlined datum.

Pays a script a certain value with a certain hashed datum, whose resolved datum is not provided in the transaction body that issues the payment (as opposed to "paysScript").

Pays a script a certain value without any datum. Intended to be used with withDatum, withUnresolvedDatumHash, or withInlineDatum to try a datum whose type does not match the validator's.

Set the datum in a payment to the given datum (whose type may not fit the typed validator in case of a script).

Set the datum in a payment to the given inlined datum (whose type may not fit the typed validator in case of a script).

Set the datum in a payment to the given hashed (not resolved in the transaction) datum (whose type may not fit the typed validator in case of a script).

Add a reference script to a transaction output (or replace it if there is already one)

Add a staking credential to a transaction output (or replace it if there is already one)

Withdrawals associate either a script or a private key with a redeemer and a certain amount of ada. Note that the redeemer will be ignored in the case of a private key.

A convenience template of an empty transaction skeleton.

Return all data on transaction outputs. This can contain duplicates, which is intended.

All validators which will receive transaction outputs

Decide if a transaction output has a certain owner and datum type.

The missing information on a TxSkel that can only be resolved by querying the state of the blockchain.

All TxOutRefs known by a given transaction skeleton. This includes TxOutRef`s used as inputs of the skeleton and TxOutRefs used as reference inputs of the skeleton. This does not include additional possible TxOutRefs used for balancing and additional TxOutRefs used as collateral inputs, as they are not part of the skeleton.

Returns the full value contained in the skeleton outputs

All validators in the reference script field of transaction outputs

All TxOutRefs in reference inputs