You can chain the component to send lovelace to multiple recipients. For each recipients, append:

You can chain the component to send assets to multiple recipients. For each recipients, append:

The Asset object is defined as:

The unit field is the policy ID and asset name in hex format. The quantity field is the amount of the asset to send.

Specify an output for the transaction. This funcion allows you to design the output UTXOs, either by splitting the outputs from multiple UTxOs or by creating reference inputs.

sendValue() is useful when working with smart contracts, when you want to redeem a UTxO from the script.

where UTxO has the following format (use one of our providers):

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

Here are a few scenarios where multi-signature transactions are useful:

• you want to create a transaction with a backend and send to the frontend for the user to sign
• when you use a forge script which requires the user to pay for the minting fee
• when redeeming an asset from a script

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.

Send assets to a handle. Initialize a provider and fetch the address of a handle.

The handle should be a valid handle on the mainnet.

Send assets to a Begin ID. Initialize BeginProvider and fetch the address.

Must be a valid name on the mainnet.

There are currently three coin selection algorithms available:

• Keep Relevant
• Largest First
• Largest First Multi-Asset

Keep Relevant

keepRelevant is a two-step coin selection algorithm. First, given a Map (of requested assets and respective quantities) and a set of UTxOs, it tries to eliminate the irrelevant UTxOs from the set. Next, it checks that this UTxO set includes enough lovelace to cover all/any multi-assets in the set. If the set does not include enough lovelace, then it will try to also pick up another UTxO from the wallet, containing the largest amount of lovelace.

Here is an example how you can use keepRelevant():

Largest First

To select UTXOs for transaction that only requires lovelace, use largestFirst.

For example, selecting the UTXOs for sending 10000000 lovelace:

Largest First Multi-Asset

largestFirstMultiAsset allows you to define which native assets you require for sending out by defining a Map. The Map is matches the Unit with the quantity of each asset.

Note that if lovelace, aside from the "minimum Ada" which in any case needs to accompany the other assets, this must be explicitly specified. This can also be useful in the case that your transaction only requires transfer of lovelace. In this case, the algorithm will exclude all multiasset UTxOs from the selection, which can result in more efficient selection of the required UTxOs.

The third parameter is includeTxFees. If True, Mesh will calculate the fees required for the transaction, and include additional UTxOs to necessary to fulfill the fees requirements.

Add messages/comments/memos as transaction metadata. This is useful for attaching additional information to a transaction.

Add messages/comments/memos as transaction metadata. This is useful for attaching additional information to a transaction.

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 choosen 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.

Specify the UTXOs that you want to use as collateral.

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 setTimeToExpire 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 setTimeToStart and providing the slot:

Note that, if you are using a policy locking script, you must define setTimeToExpire before the expiry; otherwise, you will catch the ScriptWitnessNotValidatingUTXOW error.