What a payout run costs
Why network choice dominates
The fee is per transfer, so cost scales with the number of recipients rather than with the total amount.
A thousand payouts on Ethereum at a few dollars each is thousands of dollars in fees. The same thousand on TRON is around a thousand dollars. On Solana or TON it is a few dollars in total.
That difference is not marginal, and at any real volume it becomes the largest single decision about how payouts are run. For a business paying out weekly to hundreds of recipients, moving from Ethereum to a cheap network changes the annual figure by an order of magnitude.
Batching
Some networks let one transaction carry many outputs, which reduces the per-recipient cost further.
Bitcoin supports this natively: a single transaction can pay hundreds of addresses, and the fee scales with transaction size rather than with recipient count, so batching cuts it substantially. Ethereum and similar chains require a smart contract to achieve the same, and whether the saving justifies the contract depends on volume.
Where batching applies, the trade-off is granularity: a failed batch fails for everyone in it, so batch sizes need to balance saving against blast radius.
How to prepare a run
What to have ready before a run
Four things, and skipping any of them turns a payout run into an afternoon of manual work.
Native coin for fees
Every chain needs its own, and a payout run that stops halfway because the gas ran out leaves half the recipients paid. The native token entry explains why.
Validated addresses
Check format against network before sending, not after. A batch containing one malformed address behaves differently depending on the system, and none of the outcomes are good.
Correct networks per recipient
Recipients specify where they want funds, and a list mixing networks needs the network field populated per row rather than set once.
Approval separation
The person preparing a run and the person releasing it should be different people above a threshold. This is standard practice in fiat payouts and applies identically here, and it is part of what a merchant wallet provides.
Screening applies outgoing too
Worth stating, because it surprises people.
Sending to a sanctioned address is prohibited in the same way receiving from one is, so providers screen outgoing transfers against the same lists. A payout to a flagged recipient will be held, and the sanctions screening entry explains why there is no discretion in that.
For iGaming operators this comes up regularly, since player withdrawal addresses are not chosen by the operator.
What goes wrong
Three recurring failures.
Partial completion
Gas exhausted, network congested, one address rejected. The system needs to report exactly which rows succeeded, and reconciling this by hand is what a proper payout tool prevents.
Duplicate runs
A run repeated after an unclear failure pays everyone twice, and crypto transfers cannot be recalled. Idempotency on the request is the defence.
Wrong network per recipient
Funds arrive on a chain the recipient does not watch, and recovery depends on whether they control the key there.