# Mass Crypto Payouts: 150 Recipients, One Request > How Vaultody batches up to 150 recipients into one request and one approval, where UTXO chains settle in one transaction and where EVM and Solana do not. Published: Oct 14, 2026 Categories: Technology Source: https://vaultody.com/blog/633-mass-crypto-payouts-150-recipients-one-request --- **TL;DR:** Vaultody lets a payouts desk pay up to 150 recipients per request under one approval: one on-chain transaction on Bitcoin-family chains, orchestrated sends on six Ethereum Virtual Machine (EVM) chains and Solana, where the cap is 20. ## A batch turns a queue of withdrawals into one request and one approval A payouts lead at an iGaming operator or payment service provider (PSP) usually runs withdrawals as individual sends. Each send is a request. Each request waits for an approver. The approval queue grows with player activity, not with risk. Vaultody's mass payouts change the unit of work. A batch of up to 150 recipients is submitted as one tx-request and passes through one approval workflow. Approvers review the batch as a whole. Your system groups pending withdrawals into batches, and the approval policy sees one item per batch. How the batch settles on-chain depends on the chain model. That distinction affects fees, reconciliation and failure handling, so each model is covered separately below. ## On Bitcoin-family chains, up to 150 recipients settle in a single transaction Bitcoin, Bitcoin Cash, Dash, Dogecoin, Litecoin and Zcash use the unspent transaction output (UTXO) model. A transaction consumes existing outputs as inputs and can create many new outputs. Vaultody's multiple-transfer uses this directly. It pays one coin to many recipients in one transaction. Three controls sit around that transaction. - **Automatic UTXO selection.** By default, Vaultody chooses which inputs fund the batch. Your integration supplies recipients and amounts. - **Coin control.** When treasury policy requires it, you choose the inputs yourself. This is UTXO coin control applied to a batch rather than a single send. - **Dry-run validate.** A validation call checks a batch before it becomes a request. Run it inside your batching job so malformed batches never reach an approver. The 150-recipient cap is enforced at every layer. Build the splitting logic into your own scheduler, so a payout run of any size becomes a sequence of batches of 150 or fewer. Multiple-transfer pays a single coin per transaction, so plan one batch per coin. ## On EVM chains and Solana, a batch is one approval, not one transaction Account-based chains have no outputs to fan out. Vaultody handles them through a separate batch endpoint on six EVM chains plus Solana. The cap is 150 recipients on the EVM chains and 20 on Solana. A fee payer is required. Be precise about what happens on-chain. On account-based chains, a batch is a set of orchestrated sends: one approved request that produces an individual transfer per recipient. It is not a single UTXO-style transaction. The operational gain sits in the request and approval layer, not in the on-chain footprint. That changes how the back office should work: - Reconcile per recipient. Each recipient maps to its own on-chain transfer, not to one shared transaction identifier. - Track status per recipient in your ledger, so each player withdrawal can be answered individually. - Keep the fee payer funded as a standing operational task. - Size Solana batches at 20, not 150. Chain group | Path | Recipient cap | On-chain result | What to plan for | Bitcoin, Bitcoin Cash, Dash, Dogecoin, Litecoin, Zcash | Multiple-transfer | 150 | One transaction, one coin to many recipients | UTXO fragmentation, coin control | Six EVM chains | Batch endpoint | 150 | Orchestrated sends, one per recipient | Fee payer, per-recipient reconciliation | Solana | Batch endpoint | 20 | Orchestrated sends, one per recipient | Fee payer, smaller batch size | Tron, XRP | No batch path | Not applicable | Individual transfers | Request volume tracks withdrawal volume | ## Fragmented deposit wallets need consolidation before they batch reliably The UTXO model has a cost. A wallet that receives many small deposits accumulates many small UTXOs. Funding a large batch from those inputs can fail on the fee-rate floor. The fix is consolidation, which merges small outputs into fewer, larger ones before a payout run depends on them. For a desk that collects player deposits and pays out on the same chain, treat consolidation as a scheduled treasury task, not an incident response. Coin control and the dry-run validate call give two checkpoints. Choose inputs deliberately, then confirm the batch passes before it is submitted. Teams new to the mechanics should start with how the UTXO model shapes transaction construction. ## Approval thresholds should be set against a 24-hour rolling total Vaultody's approval bands evaluate a 24-hour rolling total. A batch is assessed in the context of what has already moved in that window, not only on its own value. This has two consequences for a payouts desk. Splitting a large run into smaller batches does not keep it in a lower band, because the window accumulates. A busy day can also push later batches into a higher band with stricter approval requirements. Set band thresholds against expected daily payout volume, and staff approvers for the band your peak days reach. ## The client key share signs every batch Batching changes the number of requests, not the signing scheme. Vaultody is non-custodial multi-party computation (MPC) wallet infrastructure. Every vault key is split 3-of-3: two shares on Vaultody nodes and one share held by the client, which is mandatory. Vaultody cannot move funds alone and never holds client funds. Signing uses DKLS23 for the Elliptic Curve Digital Signature Algorithm (ECDSA) and FROST (Flexible Round-Optimized Schnorr Threshold signatures) for the Edwards-curve Digital Signature Algorithm (EdDSA). Key material sits in hardware security modules (HSMs). For a regulated operator, the practical point is that your organization remains the custodian of record. Your compliance team should map its own obligations on that basis. ## Frequently asked questions about mass crypto payouts ### How many recipients can one crypto batch payout include? Up to 150 recipients on Bitcoin, Bitcoin Cash, Dash, Dogecoin, Litecoin, Zcash and six EVM chains. Solana batches are capped at 20. The cap is enforced at every layer, so larger runs must be split into multiple batches. ### Is an EVM batch payout one on-chain transaction? No. On EVM chains and Solana, a batch is one request and one approval that produces orchestrated sends, one transfer per recipient. Only the UTXO chains settle a batch as a single on-chain transaction. ### Why would a Bitcoin batch payout fail? One documented cause is a wallet fragmented into many small UTXOs, which can fail on the fee-rate floor. Consolidating small outputs addresses it. The dry-run validate call lets you check a batch before an approver sees the request. ### Can I send batch payouts on Tron or XRP? No. Tron and XRP are supported for transfers, but neither has a batch payout path. Withdrawals on those chains run as individual requests. ## This fits Bitcoin-family and EVM payout desks, not Tron-first ones If most withdrawals settle on Bitcoin, Litecoin, Dogecoin or the other UTXO chains, multiple-transfer reduces both request count and on-chain transaction count. If they settle on EVM chains, the gain is fewer requests and fewer approvals, with per-recipient reconciliation. Solana desks get the same model at batches of 20. Tron-first payout desks are not the fit. There is no Tron batch path, so request volume tracks withdrawal volume. TRON fee optimization, a discount on network cost that varies by plan, lowers the cost per transfer but does not reduce the number of requests. To test the workflow against your own payout files, review our [mass payouts feature page](/features/mass-payouts) and request a demo with your batching scheduler in scope. We will walk your team through multiple-transfer, the batch endpoint, dry-run validate and approval bands.