Trust Stack Docs
Products

Multi-send

Send one Fungible Asset to as many as 100 recipients in one atomic transaction.

Multi-send distributes one standard Fungible Asset to a bounded list of recipients in one wallet-signed transaction. The batch is atomic: either every reviewed transfer succeeds or none of them does.

Multi-send workspace with token, recipients, totals, and review controls

When to use it

Use multi-send when every recipient should receive tokens immediately, for example:

  • paying a small group of contributors;
  • distributing prizes or community rewards;
  • moving treasury allocations to multiple wallets; or
  • sending refunds in one transaction.

Use a Merkle airdrop when recipients should claim for themselves or the list is too large for one 100-recipient batch. Use payment streams when value should accrue over time.

Before you start

You need the token metadata address, recipient addresses, amounts, enough token balance for the complete batch, and enough SUPRA for network gas. Multi-send accepts between 1 and 100 unique recipients per transaction.

Prepare data in the supported two-column form:

address,amount
0xabc...,125.5
0xdef...,250

Amounts are interpreted using the verified token decimals. Do not include names, emails, or private notes in a file that may be shared.

Send a batch

  1. Open Multi-send.
  2. Enter the Fungible Asset metadata address and verify its symbol, decimals, and your balance.
  3. Paste recipient rows or import the supported CSV.
  4. Review every canonical address and converted amount.
  5. Confirm the recipient count, total token amount, and live wallet balance.
  6. Sign the single transaction.
  7. Wait until BatchSent and every TransferSent event match the reviewed list.
  8. Save the transaction hash and final reconciliation result.

Do not retry only because the wallet window closed. First check whether the original transaction finalized; submitting the same batch again would pay recipients twice.

Practical example

A project distributes EXR rewards to three contributors:

RecipientAmount
Alice100 EXR
Bob200 EXR
Carol300 EXR

The wallet must hold at least 600 EXR. One successful transaction transfers all three amounts. If Bob's row is invalid or the sender has only 599 EXR, the entire transaction aborts and Alice and Carol are not partially paid.

Fees and costs

ActionTrust Stack protocol feeWho paysOther cost
Send one batchNoneNobodySender pays Supra network gas and the full token total
Receive tokensNoneRecipientNone
Review or reconcileNoneNobodyNone

Larger batches can require more gas than a simple transfer. A list above 100 recipients must be split into multiple transactions, and each transaction has its own gas cost and atomic boundary. Trust Stack does not deduct a percentage or fixed fee from recipients. See Fee governance.

Validation rules

  • 1 to 100 recipients per transaction
  • recipient and amount arrays must have equal length
  • no zero address, zero amount, or duplicate recipient
  • the aggregate base-unit amount must fit a Move u64
  • the sender must have enough live balance for the complete batch
  • dispatchable Fungible Assets are rejected

Dispatchable assets can execute custom transfer behavior that breaks simple conservation assumptions. They are intentionally outside this product.

What recipients need to do

Nothing. Multi-send deposits tokens directly into each recipient's primary Fungible Asset store. Recipients do not claim and do not pay gas. They should verify the token by metadata address and the transfer through the transaction hash.

Common problems

  • Duplicate recipient: combine that wallet's amounts into one row.
  • Too many recipients: divide the list into batches of no more than 100.
  • Balance changed after review: refresh and review again before signing.
  • Amount has too many decimals: use no more fractional digits than the token supports.
  • Dispatchable asset rejected: use a standard admitted Fungible Asset.
  • Uncertain submission: reconcile the transaction hash before retrying.

Recipient privacy

Addresses, amounts, and transfer events are public on-chain. Keep payroll names, email addresses, invoices, and other private context outside the distribution file and public transaction record.

On this page