Split Payments
Pay 2–20 wallets in one atomic, same-network payment.
One asset, multiple recipients
Split Payments distributes ETH or a supported token to 2–20 distinct wallet addresses in one network transaction. Choose an asset and network, enter the total, add recipients and assign percentages totaling 100%. Split equally handles division automatically; adding or removing a recipient resets shares equally.
Robinhood, Base and Arbitrum are supported. Tokenized Robinhood stocks can be selected from the asset picker. This is a direct transfer of tokens you already own, not an exchange or cross-chain route. All recipients must accept the chosen token on that same network. Transfer restrictions imposed by a token still apply.
Create a split payment ↗Exact amounts before you sign
The review shows every full address and exact amount. Distribution uses integer token units; any rounding remainder is assigned to the largest fractional shares, with list order breaking ties. The displayed recipient amounts always add up to the total. A share too small to receive one unit is rejected.
Connect the sending wallet. Recipients do not connect or sign. For tokens, your wallet may ask for an exact-amount approval, followed by the payment. Native ETH does not need an approval. There is currently no Null Cash service fee for Split Payments; the sender pays network gas and any approval gas. This does not change the 0.5% fee or staking benefits for Exchange and Advanced.
Everyone is paid, or the payment reverts
All recipients are executed atomically. If an address rejects ETH, a token blocks a transfer, an allowance is insufficient, or a token deducts transfer tax, the whole payment reverts. Nobody receives a partial payout from that transaction. Failed transactions still cost gas. Fee-on-transfer and rebasing tokens are unsupported.
Each reviewed payment has an on-chain identifier that cannot be paid twice by the same sender. Keep the pending payment and transaction hash if you reload or lose connection. Do not start another batch because an RPC is slow. A successful receipt must contain the expected sender, token, total and every recipient transfer before the app marks it delivered.
Transactions shows the batch and the amount and status of each recipient. Save a JSON receipt to retain addresses, amounts and the transaction hash. Local history and the pending form are stored in this browser; clearing browser storage removes them. Blockchain transfers and explorer records remain public. Recipient labels are browser-only metadata. The app checks pending payments approximately every seven seconds while the page is open; the transaction does not depend on keeping the page open.