Prepare the approved run
Validate the recipient list before creating the route. The documented limit is 20 distinct wallets per transfer. Plan separate transfers and reconciliation for larger runs.
Use Multi-Send as the asset-distribution step in a payroll or contributor-payment workflow. Define the recipient allocations, authorize the route and track each destination’s payout.
Your application owns the business process. MultiHopper supplies the routing step.
For teams and platforms that already manage compensation approvals and need to distribute supported onchain assets to several wallets. MultiHopper supplies routing; your payroll system remains responsible for the underlying payment records and approvals.
Imagine a team approving twelve contributor payments for the month. Its payroll system validates the wallets and computes the intended allocations. The integration creates a Multi-Send transfer, checks the quoted amount each contributor will receive and reconciles the final payouts against the approved run. This is an example workflow, not a customer deployment claim.
Validate the recipient list before creating the route. The documented limit is 20 distinct wallets per transfer. Plan separate transfers and reconciliation for larger runs.
Destination allocations must sum exactly to the input amount. Fees are deducted from the total, and recipients receive proportional shares of the remainder. Compare every quoted payout with the amount your payroll process intends to deliver.
Follow the Multi-Send preparation, signing and confirmation sequence. Track each destination’s payout status and transaction signature. The documented completed state means all destinations have been paid.
Implementation reference: Multi-destination implementation guide.
Coordinate several wallet payouts through one documented routing workflow.
Link an approved reward, task or contribution record to its payout for support and reconciliation.
Let your application initiate future runs according to its own schedule and approval rules.
Use your existing payroll process for compensation calculations, deductions, employee records and reporting. Multi-Send is the transfer component.
Input allocations are not promises of exact take-home amounts. If your workflow requires a specific net amount, resolve it against the returned quote before approving the transfer.
SOL destinations must meet the documented post-fee account minimum. SPL payouts require support in the deployed program version. Test the actual token and environment you will use.
Routing does not erase onchain history or guarantee anonymity. Smart-contract and execution risks remain. Review the security model and current audit status before selecting the value and scope of an integration.
Recurring scheduling and approvals belong in your application. This page describes how to integrate a payout run, not a standalone recurring-payroll feature.
Use separately approved transfers for larger lists. Keep batch and recipient records so retries cannot accidentally pay the same allocation twice.
No anonymity guarantee is provided. Payouts remain observable onchain, so do not treat routing as a way to make salary amounts or wallet relationships secret.
Explore agent-funded contributor work ↗
The EarnFi case study illustrates a related contributor-payment workflow, not a payroll certification.
Reviewed October 5, 2026 against the linked documentation. Check the current guide and deployed cluster before implementation.
Bring your workflow, supported asset and operational requirements to the team.