> For the complete documentation index, see [llms.txt](https://docs.j.tools/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.j.tools/tools/wallets/multi-sender.md). # Multi Sender: Airdrop SOL or Tokens in Bulk [Multi Sender](https://j.tools/en/tools/multi-sender) sends SOL or an SPL token out to a whole list of recipient wallets in a single run on Solana mainnet. You bring the list from a holder snapshot or a CSV, pick how each address gets its amount, and the tool builds the transfers in batches that you sign from your own wallet. Queue a 500-wallet airdrop in under a minute instead of clicking through 500 transfers by hand. ## What it is Multi Sender is a batch distribution tool. You start with a sending wallet that holds either SOL or an SPL token, you add your list of recipients, and you tell the tool how much each one should receive. It then groups those transfers into batches and walks you through signing them. Recipients are read straight from a paste, a CSV upload, a holder snapshot, or hand-typed rows. It handles both currency types. For native SOL the tool sends lamports directly to each address. For an SPL token it builds the token transfer and, where a recipient has no account for that mint yet, adds an idempotent create instruction so the delivery still lands. ## Why use this tool Sending the same token to many wallets one transfer at a time is slow and error-prone. You retype amounts, you risk funding the wrong address twice, and a big list eats an afternoon. Multi Sender collapses that into one reviewed run: the whole list is queued together, amount modes fill the numbers for you, bad rows are stripped before a lamport moves, and a failed batch re-sends only the rows that have not landed yet. ## How it works (under the hood) You give Multi Sender a sending wallet, a currency, a recipient list, and a per-recipient amount. From there it does a few things on your behalf: * It builds batched transfer instructions. Rather than one giant transaction, the tool groups recipients into batches sized to stay within Solana's transaction limits, then asks you to sign them in order. A SOL batch starts at 18 recipients per transaction and an SPL batch at 6, since a fatter token batch is exactly what trips a wallet's "could be malicious" warning, and the size shrinks automatically if a batch comes back too complex. When the address-lookup-table route is available, it packs 50 SOL or 30 SPL recipients per transaction instead. * For SPL tokens, each recipient that has no account for the mint gets an idempotent associated-token-account create instruction packed alongside the transfer. That small account costs a one-time rent, paid from your wallet, and is what lets a brand-new holder receive the token. * It pre-simulates before asking you to sign, so a batch that would fail is caught and surfaced as a plain message instead of a wallet warning. * You sign every batch in your own wallet. On the private-key path, used only by people who paste their own key, the run's whole platform fee goes out first as one standalone transfer, and then each recipient gets its own transaction and its own signature. With a connected wallet the platform fee rides inside the batch transactions themselves, split across them in proportion to the recipients each one carries, and the running summary shows the total before you commit.
How Multi Sender works
## When to use it * You are running an airdrop or a community and reward distribution. Working from a holder list? The [Airdrop to holders](/guides/airdrop-to-holders.md) guide walks the full flow. * You need batch payouts to many wallets at once. * You are handing out presale or test allocations from a fixed list. * You want to send one token to a known set of recipients instead of clicking through transfers one by one. If every transfer should come from its own sender wallet rather than one funding wallet, use [Many to Many](/tools/wallets/many-to-many.md). To pull funds in from many wallets instead of pushing them out, use [Batch Collector](/tools/wallets/batch-collector.md). Not sure what an SPL token is? The [glossary](/getting-started/glossary.md) has a quick definition, and [SPL vs Token-2022](/concepts/spl-vs-token2022.md) covers the two standards Multi Sender handles. ## Before you start * A connected wallet ([how to connect](/getting-started/quick-start.md)), or your own imported wallet if you sign with a private key. * Enough balance to cover every recipient amount plus the platform fee, the network fee, and account rent for any new SPL recipients. * For an SPL token: the token's mint address, picked with the built-in token selector. Your sending wallet must already hold that token. * Your list of recipient addresses, ready to paste, upload as CSV, or add by hand. {% hint style="info" %} For SOL, each recipient amount has to be at least the rent-exempt minimum shown in the tool. Anything smaller cannot create a fresh recipient account, so the tool blocks it. {% endhint %} ## Step by step {% stepper %} {% step %} ### Pick the currency Choose **SOL** or **SPL Token**. For an SPL token, select the mint and the page reads your balance from the active wallet. Opening the tool with a `?token=` link fills the mint in for you and switches to SPL automatically. {% endstep %} {% step %} ### Add your recipients Open the Import Wallet terminal to paste addresses or upload a CSV. Each line is either `recipient` or `recipient,amount`. You can also use **Add Row** to type addresses in by hand. There is no fixed recipient cap. The tool splits the list into batches sized to fit a Solana transaction and you approve them in order, so a longer list simply means more batches. The lookup-table route, which packs the most recipients per transaction, tops out at 3000 recipients. {% endstep %} {% step %} ### Set the amounts Open **Advanced Send Settings** and choose a mode: Equal, Random, or Percentage. Enter a total (Equal and Percentage) or a min and max (Random). Amounts fill across the editable rows on their own, no Apply button. The **Max** helper fills the largest total you can actually send. Any row you edited by hand stays as you left it. {% endstep %} {% step %} ### Clean up the list If the list has problems, use **Clean up list** to drop invalid, duplicate, and self-address rows. These block the send, so clearing them is required before you can run. {% endstep %} {% step %} ### Review the summary The summary shows total recipients, total amount, the platform fee, the network fee, account rent for any new SPL recipients, what recipients receive, and the total leaving your wallet. Read it before you commit. {% endstep %} {% step %} ### Send to all Click **Send to All**. With a connected wallet, the run pre-simulates, then asks you to sign the transactions in batches. With a private-key sender, transfers are signed right in your browser with the pasted key, one signature per recipient. The key is never uploaded to J Tools servers. {% endstep %} {% step %} ### Track and retry Each row shows pending, success, or failed, with a signature and a Solscan link. Failed rows can be retried: **Send** only re-sends rows that have not succeeded yet, so a delivered row is never charged twice. Download a CSV receipt when the run is done. {% endstep %} {% endstepper %} [**Open Multi Sender in the app →**](https://j.tools/en/tools/multi-sender) {% hint style="info" %} **About wallet warnings.** Some tools bundle several instructions into one transaction, for example creating a token and its metadata together. Phantom can show a caution banner for these transactions. The banner is expected here and does not mean something is wrong. Read what you are signing, then approve. {% endhint %} ## The options, explained * **Token type:** Send native SOL or an SPL token. Toggle between **SOL** and **SPL Token**. The choice changes which fees and rent apply, since SPL deliveries may create recipient accounts. * **Token mint:** The SPL mint address, required only for SPL sends. Pick it with the built-in token selector, or let a `?token=` link fill it for you. Your sending wallet must already hold this token. * **Recipients:** Your list of address and amount targets. Every address must be a valid Solana pubkey and every amount above zero. Bring them from a paste, a CSV, a holder snapshot, or hand-typed rows. * **Distribution mode:** How per-recipient amounts get worked out. Equal splits a total evenly across all rows. Random gives each row a random amount between a min and a max you set. Percentage splits a total by weight inside a min and max percentage band. * **Max helper:** Fills the largest total you can actually send right now, after reserving the platform fee, the network fee, and any recipient rent. Useful when you want to empty a wallet across the list without overdrawing it. * **Clean up list:** Strips invalid, duplicate, and self-address rows in one click. These rows block the run, so this step is required before you can send. * **Sender private key:** Used only on the private-key path, for self-custody users entering their own key. The connected-wallet path uses your wallet adapter and never touches a raw key. {% hint style="info" %} The amount modes only write numbers into your rows. You can still hand-edit any single row after filling, and the summary recalculates on the fly. {% endhint %} ## Fees and costs {% hint style="warning" %} **About fees.** Every action has two costs: the Solana **network fee** paid to validators, and the **J Tools platform fee**. The platform fee always shows in the app before you confirm, and nothing is charged until you sign. Fees can change over time, so trust the in-app summary rather than a number you saw once. {% endhint %} **Current platform fee: 0.001 SOL per recipient.** It is counted per address, not per transaction, and one transaction on this tool carries several recipients. With a connected wallet the run's total is split across the batches you sign; on the private-key path it goes out as one transfer before the first recipient is paid. | Cost | Amount | | -------------------- | -------------------------------------------------- | | J Tools platform fee | 0.001 SOL per recipient | | Solana network fee | a small amount per transaction, paid to validators | Example: 100 recipients cost about 0.1 SOL in platform fees. On top of the platform fee you pay Solana's own network fees. Every batch you sign carries a small base transaction fee in SOL, and any SPL recipient that does not yet have an account for your mint needs a one-time rent deposit to create it. The summary breaks all of this out before you commit, so the total leaving your wallet is never a surprise. ## Security and custody The private-key path is the one thing here that deserves care. A key you paste stays in the browser session, signs one transfer per recipient locally, and is never sent to J Tools servers, but a key out of its vault is still a key out of its vault. Treat any wallet you import this way as disposable: use it for the run at hand, then rotate it. For everyday sends, connect a wallet instead. ## Common mistakes and troubleshooting * **Send is blocked by invalid rows.** Invalid, duplicate, or self-address rows stop the run. Duplicates would double-pay and self-sends just waste fees, so run **Clean up list** first. * **Amount too small (SOL).** Each SOL recipient needs at least the rent-exempt minimum shown in the tool to create its account. Raise the per-address amount. * **Not enough balance.** Caught up front, for both SOL and SPL, so a run never fails halfway through. Lower the total or use the **Max** helper. * **A few rows failed.** Network hiccups happen mid-run. Hit **Send** again and only the non-success rows go out. For the full list, see the [Error codes reference](/reference/error-codes.md). ## Advanced tips * **Stage from a holder snapshot.** Pull a recipient list from a token's holders, then feed it straight into Multi Sender for a clean airdrop. The [Airdrop to holders](/guides/airdrop-to-holders.md) guide covers the end-to-end path. * **Vet the list before you pay it.** Run the recipient addresses through [Wallet Scope](/tools/utilities/wallet-scope.md) first and strike the rows that should never be paid. Plan around its limits on a long list: 500 addresses per run, funder clusters for the first 300, so a 900-recipient list is not fully checked after one pass. ## Related tools {% content-ref url="/pages/eyvl1w0Ri5KEBHvrUAxz" %} [Many-to-Many Transfers](/tools/wallets/many-to-many.md) {% endcontent-ref %} {% content-ref url="/pages/7CPBHR61Y6akMdkeSBGW" %} [Batch SOL and Token Collector](/tools/wallets/batch-collector.md) {% endcontent-ref %} {% content-ref url="/pages/o5eO6abVdoCCB4WkfKVR" %} [Solana Holder Booster](/tools/boost/holder-booster.md) {% endcontent-ref %} {% content-ref url="/pages/tvk3KydrniyizApPkWZi" %} [Wallet Scope: Bulk Wallet Analyzer](/tools/utilities/wallet-scope.md) {% endcontent-ref %} {% hint style="success" %} **J Tools is non-custodial.** We never store or transmit your private keys and never ask for your seed phrase. Every transaction is signed in your own browser, and nothing about a key ever reaches our servers. A few multi-wallet tools do let you paste private keys for throwaway hot wallets, which stay in your browser tab and are used only to sign locally. Never paste a key tied to long-term holdings, and if a page ever asks for your seed phrase, stop and close it. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.j.tools/tools/wallets/multi-sender.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.