Stablecoin Mass Payouts: How Batch Payouts Work for Business

A stablecoin mass payout sends USDC, USDT, or EURC from one business wallet to many recipient wallets in a single run, instead of one manual transfer at a time. The work is not the transfer itself. It is the recipient list, the chain choice, gas, address verification, and the records afterward. inzi's batch payouts are a guided pilot, available on request, and are not a self-serve feature of any plan.

What counts as a mass payout?

A mass payout is any run where one sender pays many recipients on a schedule or in one operation. Typical cases for digital businesses:

• Contractor and freelancer invoices settled at month end.
• Marketplace or platform seller disbursements.
• Affiliate and creator commissions.
• Prize, rebate, or refund runs.
• Payroll for a distributed team (covered separately in the crypto payroll guide).

The common thread is that the payer already knows who gets what. What changes versus a bank run is that settlement happens on a public blockchain, each transfer is final once confirmed, and the recipient needs a wallet on the right chain that can hold the right token.

How does a batch payout actually work?

There are two broad mechanics, and the difference matters for cost and for records.

Many individual transfers, run in sequence

The sender's wallet signs one token transfer per recipient. Each transfer is its own transaction with its own hash and its own network fee. This is the simplest model and works on every chain. A script or an API loops over the list.

One transaction that fans out to many recipients

Some chains and tooling let a single transaction carry several transfers, either through a multi-send contract (common on EVM chains) or through multiple instructions in one transaction (how Solana transactions are built). You pay base overhead once rather than per recipient, which can lower the total fee on busy networks. The tradeoff is more moving parts: contract risk on EVM chains, size limits per transaction, and one failed instruction can affect the whole transaction depending on how it is built.

Either way, the practical steps are the same:

1. Build the list: recipient, amount, token, chain.
2. Validate addresses and chains before anything is signed.
3. Fund the sending wallet with the tokens and with the native gas token for that chain.
4. Sign and broadcast.
5. Teams typically confirm every transfer and match each hash to its list row.
6. The result is usually stored for bookkeeping.

Which chain and token fit a payout run?

A payout only works if the recipient's wallet is on the chain where the token is sent. The token you can send on a given chain is fixed by what exists there. For the networks inzi supports:

Two things follow from the table. First, there is no chain where all three tokens are available, except Ethereum, so a run in EURC is limited to Base or Ethereum. Second, a recipient who only has a Tron wallet can receive USDT, not USDC. Collecting the recipient's chain and token preference up front avoids most failed or misrouted payouts.

Sending to a wallet address on the wrong chain is the classic payout error. Addresses on several EVM chains look identical, so a Polygon address is also a valid address on Base and Ethereum. A transfer to the right-looking address on the wrong chain may not be recoverable by the recipient. That is why the chain belongs in the list as its own column, not as an assumption.

Who pays the gas, and what does it cost?

The sender pays the network fee. The recipient receives the full token amount unless the payer chooses to deduct something from the payout. Fees are paid in the chain's native asset, not in the stablecoin, so the sending wallet needs both.

The cost structure differs by chain:

• Ethereum: fees move with network demand, so the same run can cost very different amounts on different days. See ethereum.org's gas documentation for how the fee is calculated.
• Solana: fees are set per signature plus optional prioritization, and are generally small relative to the transfer. Details are in Solana's fee documentation.
• Tron: USDT transfers consume bandwidth and energy, which are either obtained by staking TRX or paid for by burning it. See Tron's resource model.
• Polygon, Base, TON: each has its own native gas token and fee market; the chain's own docs give the current mechanics.

An illustrative example: a run of 200 small contractor payments of $150 each is $30,000 in total. If the network fee per transfer is a few cents, fees are a rounding error. If the fee is several dollars, they become a real line item and the chain choice matters. These figures are hypothetical, not inzi pricing. The point is that fees are per transfer, so the more recipients and the smaller each payment, the more chain choice moves the total.

For a deeper explanation of the fee side, see the crypto payment API post, which covers how payments flow without customer funds sitting in a third-party account.

What does non-custodial mean for a payout run?

Non-custodial means the money sits in a wallet the business controls, and no platform holds it in between. For payouts, that has two consequences.

The upside: no intermediary balance to top up, no waiting for a provider to release funds, and no provider that can hold your payout run. The business signs from its own wallet.

The cost, stated plainly: the business owns the wallet security. Whoever can sign can send the whole balance. A payout wallet that signs automatically, such as a script with a hot key, is a bigger target than a manual process. Common mitigations are a dedicated payout wallet holding only what the next run needs, a multi-signature setup requiring approval from more than one person, and a separate wallet for treasury. inzi does not operate those wallets for you; they are yours to design.

Instructions are irreversible once confirmed. A bank can sometimes recall a transfer. A stablecoin transfer to the wrong address generally cannot be recalled unless the recipient sends it back. Pre-send validation, small test transfers to new recipients, and a human check on totals are the standard controls.

Where do inzi's batch payouts fit?

Here is what is verifiable. inzi accepts stablecoin payments on Polygon, Base, Ethereum, Tron, TON, and Solana, with the money going straight to the merchant's own wallet. The per-transaction fee is 0% on every plan; the plans are Starter at $0/month, Growth at $49/month, and Scale at $149/month. See inzi's pricing for what each includes.

Batch payouts are not part of that plan list. They run as a guided pilot, available on request, and are not included in Growth or Scale and not available self-serve. A business that needs a payout run today would ask inzi about the pilot rather than expect a payout button in the dashboard. Details such as supported run sizes or timing are agreed in that conversation, and this post does not state any.

The pilot is also not a different custody model. inzi does not hold a balance for a merchant, and the payout wallet remains the merchant's.

A business that wants to start with receiving payments and add payouts later can register for inzi on Starter at $0/month.

What records does a payout run produce?

Each transfer in a run produces an on-chain record: a transaction hash, sender, recipient, token, amount, chain, and a timestamp. That is a stronger audit trail than most bank exports, but it is raw data. It does not say who the recipient is, what the invoice number was, or what the payout was for.

A workable reconciliation sheet usually carries these columns:

Tax treatment of payouts varies by country and by recipient status, and it is a question for the business's own tax adviser. Many finance teams log the fiat-equivalent value and the settlement timestamp for every transfer so that bookkeeping can be completed later. The crypto accounting guide for stablecoin payments walks through that ledger structure.

What goes wrong in practice?

Most failed payout runs trace back to a short list of causes:

• Wrong chain. The address is valid, but the recipient watches a different network.
• Wrong token. The recipient expected USDC, the run sent USDT.
• No gas in the sender wallet. The run stalls halfway because the native token ran out.
• Stale list. An address changed since the last run and nobody re-verified.
• Recipient wallet not set up. On some chains, such as Solana, a recipient needs a token account for that stablecoin before it can hold it, which adds a small cost or an extra step.
• Partial completion. Some transfers confirm and others fail, and the list no longer matches reality. Matching hashes back to rows after the run is what catches it.

A run that starts with a small test batch, checks totals against the source list, and records every hash tends to avoid most of these.

How should a business pick between manual, scripted, and pilot payouts?

The decision turns on volume and on who must approve what.

None of these is universally better. The right row depends on how many recipients there are, how large the balances are, and how much key risk the team is comfortable carrying.