• Splits the change proportionally between the given addresses. This algorithm makes the best effort to be as accurate as possible in distributing the amounts, however, due to rounding there may be a small error in the final distribution, I.E 8 lovelace divided in three equal parts will yield 3, 3, 2 lovelace with an error of 33% in the last change output as lovelaces can't be further subdivided (The error should be marginal for large amounts of lovelace).

    While lovelaces will be split according to the given distribution, native assets will use a different heuristic. We will try to add all native assets to the UTXO with the most coins in the change outputs, if they don't 'fit', we will spill over to the next change output and so on. We will assume a high fee (2 ADA) while doing this native asset allocation (this will guarantee that when the actual fee is computed the largest change output can afford to discount it without becoming invalid). This is a rather naive approach, but should work as long as the wallet is not at its maximum capacity for holding native assets due to minCoinAda restrictions on the UTXOs.

    Parameters

    • getChangeAddresses: (() => Promise<Map<PaymentAddress, number>>)

      A callback that returns a list of addresses and their proportions.

    • totalChangeLovelace: bigint

      The total amount of lovelace in the change.

    • totalChangeAssets: undefined | TokenMap

      The total assets to be distributed as change.

    • computeMinimumCoinQuantity: ComputeMinimumCoinQuantity

      callback that computes the minimum coin quantity for the given UTXO.

    • tokenBundleSizeExceedsLimit: TokenBundleSizeExceedsLimit

      callback that determines if a token bundle has exceeded its size limit.

    • fee: bigint

      The transaction fee to be discounted.

    Returns Promise<TxOut[]>

Generated using TypeDoc