214 recipients, paid monthly in USDC, one CSV. Row 87: a typo in the address, doesn't fail until the transaction's already built. Row 140: no trustline for the asset, so the payment doesn't bounce, it just never arrives. Row 203: a brand-new account, short of the 1 XLM reserve, fails too. 214 recipients needs at least three transactions. Stellar caps one at 100 operations. Transaction two lands. Transaction three times out. Now: which of the first 140 already got paid?
sendall: Non-custodial bulk payments on Stellar. XLM or any trustline asset, up to 5,000 recipients per batch, on Testnet and Mainnet.
Built after enough Tuesdays like that one.
The alternative is usually a script somebody wrote once and is scared to touch, or handing a payout company your recipient list and your trust. Neither checks a trustline before it fails. Neither tells you which of 140 already got paid.
A typo in one address. Usually fails a checksum, but not until the transaction's already built.
Every address is checked before you're asked to sign anything.
A recipient's wallet has no trustline for the asset. The payment doesn't fail, it just doesn't land.
Trustlines are checked per recipient against live chain state before you send.
A brand-new account needs 1 XLM before it can hold anything else.
New accounts are checked against the reserve automatically.
Stellar caps a transaction at 100 operations. Past that, you're splitting the batch and tracking chunks yourself.
Batches split into transactions of 100 operations or fewer, signed in order, automatically.
One transaction in a large batch fails. Now you're checking the ledger by hand to see who got paid.
Every recipient's status is tracked on its own. Retry only touches what failed.
A payout tool asking to hold your key, or a server signing on your behalf.
The server only builds unsigned transactions. Your wallet signs, locally, every time.
What if my CSV has a mistake in it?
You find out before it costs anything. Every row is checked against live chain state and shown in a table before you're asked to sign.
What happens if a transaction fails partway through a large batch?
Only that transaction's recipients are affected. Retry the failed rows on their own; nothing that already settled gets touched again.
Does sendall ever hold my private key?
No. Signing in is a signed challenge that proves you control the wallet without touching the chain. Every transaction is built unsigned and signed locally in your wallet.
Can I test this before sending real funds?
Yes. The same flow runs on Testnet: same validation, same chunking, same retries.
What if I have more than 5,000 recipients?
Split the list and run it as two batches. Validation and chunking work the same either way.
What assets can I send?
Native XLM, or any Stellar asset your recipients already hold a trustline for. Add the asset code and issuer.
The next batch doesn't have to be a Tuesday like that one.
Non-custodial. Testnet and Mainnet. Nothing gets signed until you're ready.
$ app.sendall.xyz