A community payout can be ready on paper and still stop at the wallet. The sender holds the project token, the recipient list is complete, but the wallet cannot pay the network fee. Another payout can succeed on-chain while reaching a network the recipient did not expect.
Before sending tokens on Optimism, answer three separate questions: what asset is moving, which network holds it, and what balance pays for the transaction? Only then review the recipient list. These checks matter for a small contributor payment as much as a larger community distribution.
This guide follows SolCreate's existing OP Mainnet multisender. It describes preparation and the implemented wallet flow, not a completed transaction demonstration.
ETH gas is separate from the token you send
For the ordinary wallet-signed OP Mainnet flow described here, network fees are paid in ETH. A balance of OP or a project's ERC-20 token is not the same thing as a spendable ETH balance. Check the ETH held on OP Mainnet, rather than assuming ETH shown under another network is available for this transaction.
Keep three budget lines separate: the distribution asset, SolCreate's displayed service fee and network fees. If you distribute an ERC-20, you need enough of that token for the recipients as well as ETH for the remaining costs. If you distribute native ETH, the payout itself also comes from the ETH balance. Do not allocate the entire balance to recipients and leave nothing for fees.
Optimism's documentation describes execution, data-publication and operator components in transaction fees. That is a reason to use the current wallet estimate, not a remembered fixed gas number. A successful balance check is not a promise that every later transaction will fit the remaining budget.
Agree on OP Mainnet before accepting an address
Ask recipients to confirm both their address and their receiving network. "Send it to my Ethereum address" is not enough operational detail. A wallet address alone does not tell a sender which network the recipient plans to use.
For an exchange deposit, check that exchange's current support for the exact asset on OP Mainnet. Do not assume support merely because it accepts the token on a different chain. For a self-custody wallet, ask the recipient to check the asset on OP Mainnet after delivery.
The SolCreate route covered here distributes assets on OP Mainnet. It is not a bridge. If funds are on another network, moving them to OP Mainnet is a separate preparation step. Do not use a new token deployment to try to solve a network-balance mismatch. Creating a token through the Optimism token creator is a different action from sending an existing balance.
Build a recipient sheet that someone else can review
Use one row per intended payment, with the recipient address and amount in separate columns. Keep a private working copy that also identifies the reason for each payment. The pasted transaction list should not depend on someone remembering which contributor a shortened address belongs to.
For example, a community might prepare one payment for translation work and another for design work. The reviewer should be able to match each full address to the approved amount before anything is copied into a transaction tool. These are planning examples, not evidence of actual payouts.
Remove unintended duplicate rows yourself. SolCreate's current parser checks address format and positive amounts, but repeated addresses are not automatically a reason for rejection. Two rows for one wallet may represent two intentional payments, or one accidental copy. The tool cannot decide which you meant.
Use a decimal point for fractional amounts and omit thousands separators. Enter token amounts in ordinary token units, not manually expanded base units. The loaded token's decimals determine the accepted precision. Avoid using an illustrative address from an article as a real recipient.
Load the asset and validate the batch in SolCreate
Open the OP Mainnet multisender, connect the intended EVM wallet and confirm OP Mainnet. Choose the native-asset or ERC-20 mode according to what you actually intend to distribute.
For an ERC-20, enter the contract address on OP Mainnet and select Load token. Compare the loaded name, symbol and balance with your distribution record. A matching symbol alone is not enough: keep the contract address in the record as the asset identifier.
Paste one recipient per line using address, amount, then select Validate batch. Inspect every full address, the recipient count and the total. The current implementation accepts at most 200 recipient rows in one preview. Treat that as a product limit, not a recommendation to fill every batch to the maximum.
The preview rejects malformed addresses, non-positive amounts, excess decimal precision and an ERC-20 total above the loaded wallet balance. It does not establish that a recipient belongs to the person you intend to pay, that an exchange accepts the deposit, or that a token has no transfer restrictions. Those checks remain yours.
Review approvals, the service fee and execution separately
Select Confirm batch in wallet only after the preview matches the approved list. If the wallet must change networks, confirm the switch, wait for the connection to settle and review before continuing.
For an ERC-20 batch, the implementation may request an allowance transaction before the service-fee and distribution transactions. Review the spender and amount. Approval gives permission for a later token movement; it is not proof that recipients have been paid.
The service-fee transaction is also separate from the distribution. A confirmed fee payment alone is not distribution completion. If you stop, reject a prompt or encounter an error between steps, preserve the transaction hashes and check their status before trying again.
For an unfamiliar asset or receiving setup, consider a small, separately budgeted test first. Check the recipient's actual result before preparing the main distribution. A test still costs fees, and its success does not guarantee that a different batch or restricted token will behave identically.
Reconcile the receipt before sending again
After execution, use the tool's Open transaction link to inspect the distribution receipt. Check that it succeeded on OP Mainnet and reconcile token transfers or native-asset movements with the intended list. Keep fee and approval receipts separately so they cannot be mistaken for payout evidence.
If a recipient says the payment is missing, check the network, asset contract and destination first. Ask them to inspect the correct network in their wallet. Do not send a second payment merely because a token is not yet visible in their wallet interface.
If execution failed or remains unclear, stop and identify which step completed. A useful support record includes the network, token contract if applicable, sender, intended recipient, amount and relevant transaction hashes. Never include a seed phrase or private key.
Questions before a first OP Mainnet distribution
Can I use OP tokens instead of ETH for gas in this flow?
The ordinary wallet-signed SolCreate flow described here requires ETH on OP Mainnet for network fees. Holding OP or another ERC-20 does not replace that requirement.
Does validating a batch prove the recipients are correct?
No. Validation checks input and supported balance conditions. It cannot verify who controls an address, why a duplicate appears, or whether a destination service supports the asset and network.
Does the multisender create more tokens?
No. Distribution sends an existing balance. Creating a new token and minting additional authorized supply are separate workflows. Do not describe a transfer as a supply increase.
Is a service-fee receipt proof that the batch finished?
No. Check the final distribution receipt and the resulting asset movements. Keep fee, approval and execution evidence distinct.
Can the batch move tokens from Ethereum to Optimism?
Not through this route. Prepare the assets on OP Mainnet first. A same-network distribution does not bridge them between networks.
A useful payout record is simple: the right network, the right asset, a reviewed list and a successful execution receipt. Keep those four pieces together, and the next person reviewing the distribution will not have to reconstruct what happened from a wallet screenshot.
Sources and product checks
Optimism: transaction fees on OP Mainnet, checked October 17, 2026.
Optimism: OP governance token overview, checked October 17, 2026.
Product walkthrough: SolCreate OP Mainnet multisender. This guide describes the available workflow; it does not document a completed payout.