To start building an customized transaction, you need to first initialize MeshTxBuilder:

The MeshTxBuilder instance has the following signature:

There are 6 optional fields to pass in to initialized the lower level APIs instance:

1. serializer: The default serializer is CSLSerializer. You can pass in your own serializer instance.
2. fetcher: When you build the transaction without sufficient fields as required by the serialization library, we would index the blockchain to fill the information for you. Affected APIs are txIn, txInCollateral, spendingTxInReference.
3. submitter: It is used if you would like to use the submitter submitTx API directly from the instance.
4. evaluator: It would perform redeemer execution unit optimization, returning error message in case of invalid transaction.
5. isHydra: Use another set of default protocol parameters for building transactions.
6. params: You can pass in the protocol parameters directly.
7. verbose: Set to true to enable verbose logging.

Sending value with MeshTxBuilder come with the .txOut() endpoint:

In order to send values (so as every Cardano transaction), we have to fund the transaction to do so. There are 2 ways to provide values in a transaction:

• Specifying which input to spend with

• Providing an array of UTxOs, and perform auto UTxO selection:

Since the input and output values might not be the same, we have to specify the address (usually own's address) to receive change:

The following shows a simple example of building a transaction to send values with UTxO selection:

The main idea of a multi-signature (multisig) transaction is to have multiple signatures to authorize a transaction.

In the above code snippet, we are signing the transaction with the user wallet and then signing the transaction with the minting wallet. ThesignTx function is used to sign the transaction. The second argument is a boolean value that indicates whether the transaction is a multi-signature transaction.

Here is an example of creating a multi-signature (multisig) transaction with a native script, where you need to spend from a script address.

Create native script

First, we need to create a native script. In this example, we will create a native script with two signatures. That means we need to get the key hashes of the two wallets.

Next, we will create a native script object with the two key hashes. The native script object will be used to create a multi-signature transaction.

The native script object is then serialized into a CBOR object and an address.

Create transaction

Now that we have the native script, we can create a transaction with the script. We first need to get the UTXO from the script address.

Finally, we sign the transaction with the two wallets and submit the transaction.

One alternative to use the lower level APIs is to build the transaction with JSON.

The following shows a simple example of building a transaction to send values to a recipient:

You can select UTxOs from a list of UTxOs using the selectUtxosFrom method. This method allows you to specify the conditions for selecting UTxOs. The method signature is as follows:

The second parameter of selectUtxosFrom is the strategy to be used for selecting UTxOs. There are 4 strategies (UtxoSelectionStrategy) available for selecting UTxOs:

• experimental
• keepRelevant
• largestFirst
• largestFirstMultiAsset

We may introduce more strategies in the future. Check the Mesh Docs for more details.

The threshold parameter is used to specify the minimum amount of lovelace to be selected. You may specify a larger amount to if the transactions requires it.

The last parameter is includeTxFees which is a boolean value to include transaction fees in the selection.

Add messages / comments / memos as transaction metadata. This is useful for attaching additional information to a transaction. This is an example of setting metadata with transaction message.

The specification for the individual strings follow the general design specification for JSON metadata, which is already implemented and in operation on the cardano blockchain. The used metadatum label is 674: this number was chosen because it is the T9 encoding of the stringmsg. The message content has the key msg: and consists of an array of individual message-strings. The number of theses message-strings must be at least one for a single message, more for multiple messages/lines. Each of theses individual message-strings array entries must be at most 64 bytes when UTF-8 encoded.

Sets the required signers for the transaction. This is useful when you want to include multiple signers, such as in a multi-signature transaction or smart contracts.

We can define the time-to-live (TTL) for the transaction. TTL is the time limit for our transaction to be included in a blockchain, if it is not in a blockchain by then the transaction will be cancelled. This time limit is defined as slot.

In order to get the slot of the time you wish the transaction would expire, you can use resolveSlotNo. For example, if you would like the transaction to expire in 5 minutes, you can get the slot in the following way:

Next, we set the TTL with invalidHereafter and providing the slot, this means that if the transaction is submitted after after slot will not be valid.

Likewise, we can set a "validity start interval" for the transaction, where it is the time the transaction will be valid. We can define the start time with invalidBefore and providing the slot:

Sets the network to use, this is mainly to know the cost models to be used to calculate script integrity hash. You can set the network for the transaction with setNetwork.

The network parameter is a string that can be one of the following:

Set the fee for the transaction.

The following shows a simple example of building a transaction to send values with UTxO selection: