> 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-to-multi-relay.md). # Multi-to-Multi Relay: Mapped Hop Routing [Multi to Multi Relay](https://j.tools/en/tools/multi-to-multi-relay) moves SOL or one SPL token across many paired wallets at once, where each source-to-destination pair travels through its own chain of freshly generated relay wallets instead of a direct send. You map source row one to destination row one, row two to row two, and so on down the list. Every pair then hops its funds forward through a private chain of intermediate wallets you never reuse, and the tool tracks status, signature, and any error for every hop of every pair. ## What it is Multi to Multi Relay is the matrix version of [Relay Transfer](/tools/wallets/relay-transfer.md). Where Relay Transfer runs one route through a chain of relay hops, this tool runs many routes in parallel, one per source-to-destination pair. Each pair gets its own freshly generated chain of relay wallets, and the funds hop forward from source to relay to relay to destination. It works with native SOL and with a single SPL token, and it keeps a live, grouped table so you can watch every pair and every hop as it lands. The sources are raw private keys you import, paired by position to a list of destination addresses. The relay wallets in between are created in your browser session at run time, used once, and never seen again. Each hop is paid by the wallet sending it, so every source must hold enough SOL to cover its forward amounts plus the per-hop network and platform fees. An underfunded or empty source fails its whole pair before any hop runs, while the other pairs continue. ## Why use this tool Direct many-to-many transfers leave a clean on-chain line from each source straight to its destination. Routing each pair through its own chain of single-use relay wallets breaks that line into separate hops with separate wallets, which makes the path from any source to its paired destination far harder to read at a glance. It also scales. A large distribution might map hundreds of source wallets to hundreds of destinations, and running that one relay route at a time is slow and error-prone. Here the whole matrix goes in one batch, with the full cost and operation count shown before you commit. ## How it works (under the hood) When you start a run, the tool first auto-downloads one recovery `.xlsx` holding the private keys for every relay wallet it is about to generate, across every pair. This download happens before any funds move, so you always have the keys even if a hop later fails. Each pair is then processed on its own. The tool reads the source balance, plans the per-hop amounts, and generates a fresh chain of relay wallets at the depth you chose. The funds hop forward one transaction at a time: source to the first relay, first relay to the second, and so on, until the last relay delivers to the destination. Each hop is a real, signed Solana transaction. For SPL runs, the tool first seeds each relay wallet with a small amount of SOL so that wallet can pay its own network fee and the rent for the token account it creates, then forwards the token amount. Signing uses the imported source keys and the generated relay keys directly through the keypair flow, not your wallet extension. The connected wallet is optional and only attributes the commission, so your extension is never prompted for each hop. Every hop's sender is also its fee payer. A source that cannot cover its forwards plus each hop's fees fails its pair before any funds move, and the rest of the run keeps going. All transactions are non-custodial: every key lives in your session and in the recovery file you hold, and J Tools never stores them. ## When to use it * You have many source wallets that each need to reach a specific destination through controlled relay hops, not a shared sender or a single drop wallet. * You are running a large multi-wallet distribution or airdrop and want pair-by-pair and hop-by-hop progress before and during the run. If you want a single route through relay wallets, use [Relay Transfer](/tools/wallets/relay-transfer.md). For paired transfers without the relay hops, use [Many to Many](/tools/wallets/many-to-many.md). To fan one wallet out to many, use [Multi Sender](/tools/wallets/multi-sender.md). To sweep many wallets into one, use [Batch Collector](/tools/wallets/batch-collector.md). ## Before you start * A source wallet private key for each source row. This tool reads raw keys directly. The connected wallet is optional and used only to attribute the commission, not to sign the hops. * A list of destination addresses, exactly one per source row. The two counts must match or the run is blocked. * For an SPL run, the token's mint address (pick it with the built-in token selector) and Fixed amounts. All and Percentage modes do not work for SPL. If you are unsure which token standard you are routing, the [SPL vs Token-2022](/concepts/spl-vs-token2022.md) note explains the difference. * Enough SOL to cover the run. SOL runs need to cover every hop's forward amount, the per-hop network and priority fees, and the platform fee. SPL runs need more, because each relay wallet is first seeded with SOL for its fees and token-account rent. {% hint style="danger" %} **Keep the recovery file.** When the run starts, the private keys for every generated relay wallet, across every pair, are auto-downloaded as one `.xlsx`. If a hop fails, those funds sit in the last successful intermediate wallet, and that file is the only way to recover them. Treat it like cash. Store it offline and never paste a key back into chat or any web form. {% endhint %} ## Step by step {% stepper %} {% step %} ### Pick the asset Choose SOL, or switch to SPL and pick a token with the selector. The SPL list shows the connected wallet's tokens. The whole run moves one asset. {% endstep %} {% step %} ### Import the source wallets Use the import modal to paste your source private keys. Each row's SOL balance, and the selected token balance for SPL, is hydrated in bulk and shown per row. {% endstep %} {% step %} ### Import the destinations Paste destination addresses, one per line. The count must equal the number of sources. A mismatch warning blocks a clean run, so line both lists up in the same order. {% endstep %} {% step %} ### Set the amounts Apply a bulk amount mode to every source at once, or tune each pair by hand. **All** sends the full source balance after route fees and the reserve, **Fixed** sends an exact amount, and **Percentage** sends a share of the balance. For SPL, only Fixed works. {% endstep %} {% step %} ### Set relay depth, timing, and priority Choose the global relay depth with a preset or a custom value, and optionally override the depth for any single pair. Pick a fixed or random delay between hops, each from 0 to 120 seconds. Add a priority fee preset if you want to nudge transactions through during congestion. {% endstep %} {% step %} ### Review the summary Check total pairs, total operations (the sum of depth plus one across every pair), the estimated network fee, the platform fee, and the total cost. Fix anything flagged before running. {% endstep %} {% step %} ### Execute and let it run Click **Execute Multi Relay**. The recovery `.xlsx` of every generated relay key downloads automatically at the start. Each pair then reads its source balance, plans the hop amounts, generates a fresh chain of relay wallets, and hops the funds from source to relay to destination, charging the platform fee per hop. SPL pairs first seed each relay wallet with SOL for fees and ATA rent. {% endstep %} {% step %} ### Watch the live table The grouped table shows one row per pair, expandable to per-hop detail, with from, to, amount, status, signature, and any error. A failed hop stops only that pair; the others keep running. On completion a result modal shows successful and failed operation counts, the destination net amount, and the recovery download status. {% endstep %} {% endstepper %} {% hint style="info" %} Source rows are raw private keys, parsed through the keypair flow, so your wallet extension is not prompted for each hop. This is why the tool's Phantom risk is rated low: the extension is not in the signing path. {% endhint %} [**Open Multi to Multi Relay in the app →**](https://j.tools/en/tools/multi-to-multi-relay) ## The options, explained * **Token type:** SOL or SPL. SOL drains each hop forward; SPL seeds each relay wallet with SOL for fees, then forwards the token amount. * **Token mint:** Required for SPL. The mint of the token to route, chosen with the token picker. Ignored for SOL. * **Source rows:** One private key per source, up to 1000 rows. Each carries its own amount mode and value, and an optional per-pair relay depth. * **Amount mode (per row):** **All** sends the full balance after route fees and the reserve. **Fixed** sends an exact amount above zero. **Percentage** sends a share from 0 to 100. SPL supports Fixed only. * **Destination wallets:** One address per source row, paired by position. Counts must match, and each must be a valid Solana public key. * **Relay count (global):** The default hop depth applied to every pair. Presets and the slider reach up to 2500, and a custom value reaches 5000. Per pair, total hops equal relay count plus one. * **Relay count (per row):** Optional override for a single pair's depth, from 1 to 5000. Falls back to the global value when unset. * **Delay mode:** Fixed waits a set number of seconds between hops; random samples a wait between a minimum and maximum. Each value is capped at 0 to 120 seconds. * **Priority fee:** An extra fee added per transaction to prioritize it during congestion. Presets run from none up to express, with a custom option. Default is none. {% hint style="info" %} Limits at a glance: up to 1000 pairs, relay depth from 1 to 5000 per pair, delays from 0 to 120 seconds, and a priority fee up to 2,000,000 micro-lamports. Large depth across many pairs produces very large total operation counts, and each hop is a separate signed transaction with its own network and platform fee. {% 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.00023 SOL per hop.** Every hop transaction carries the fee on-chain, so the total equals your total operation count (the sum of depth plus one across every pair) multiplied by 0.00023 SOL. The amount is pinned to the tool's own constant rather than an admin dial, and the in-app summary shows the exact total before you run. Example: 5 pairs at a depth of 10 is 5 x 11 = 55 operations, or 0.01265 SOL. | Cost | Amount | | -------------------- | -------------------------------------------------------------------------- | | J Tools platform fee | 0.00023 SOL per hop (total operations × 0.00023 SOL) | | Solana network fee | a small amount paid to validators, plus rent for any new on-chain accounts | On top of the platform fee, every hop is its own Solana transaction and carries the usual network base fee plus any priority fee you add. Because each pair runs as many hops as its relay depth plus one for the final delivery, the network fee scales with both the number of pairs and the depth you pick. SPL runs cost more SOL still, since each relay wallet is seeded for its own fees and token-account rent. The in-app summary shows the full estimate, total pairs, total operations, network fee, and platform fee before you run anything. See the [Fee schedule](/reference/fee-schedule.md) for the current rate. ## Security and custody Every run here handles raw keys twice over: the source keys you paste, and the relay keys the tool generates for you. Both are parsed in your session and neither is retained after the run, so the recovery `.xlsx` is the only lasting copy of the relay keys. Keep it offline; if a hop fails, that file is the only way into the intermediate wallet holding the funds. Use source wallets you can afford to rotate, and rotate them once the run is over. ## Common mistakes and troubleshooting * **Source and destination counts do not match.** The run is blocked until both lists are the same length. Line them up in the same order, one destination per source. * **A hop failed mid-run.** That pair stops at the first failure, its remaining hops are marked failed, and its funds rest in the last successful relay wallet. The other pairs keep going. Recover the stranded funds with the downloaded `.xlsx`. The tool does not auto-retry or auto-recover. * **Not enough source SOL.** A SOL run checks that each source covers its forwards plus every hop's platform and network fees. SPL runs need more, because each relay wallet is seeded for fees and account rent; an underfunded SPL source throws an insufficient-balance error. * **SPL with All or Percentage.** Those modes need a token balance, not a SOL balance, so SPL rejects them. Switch the SPL rows to Fixed amounts. For the full list, see the [Error codes reference](/reference/error-codes.md). ## Advanced tips * **Start with a small pilot.** Run a handful of pairs at a shallow depth first to confirm your source keys, destinations, and amounts line up, then scale to the full matrix. * **Mind the operation count.** A deep relay count across many pairs can reach tens of thousands of transactions, each with its own fee and delay, so check the summary before you commit. * **Use per-pair depth overrides.** Set a sensible global depth, then raise the depth only on the pairs that need more separation, instead of inflating every route and paying for hops you did not need. ## Related tools {% content-ref url="/pages/nHTziE15NKeVLAQMnxv5" %} [SOL Relay Transfer](/tools/wallets/relay-transfer.md) {% endcontent-ref %} {% content-ref url="/pages/eyvl1w0Ri5KEBHvrUAxz" %} [Many-to-Many Transfers](/tools/wallets/many-to-many.md) {% endcontent-ref %} {% content-ref url="/pages/ABVX2mBQDoCv7DEdVmKp" %} [Multi Sender and Airdrop](/tools/wallets/multi-sender.md) {% endcontent-ref %} {% content-ref url="/pages/7CPBHR61Y6akMdkeSBGW" %} [Batch SOL and Token Collector](/tools/wallets/batch-collector.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-to-multi-relay.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.