Designing reliable mass payouts for crypto operations
Context
Crypto Office is a Telegram Mini App designed for companies, crypto teams, and exchanges that manage operational cryptocurrency workflows.
One recurring need was sending funds to many recipients at once — for example recurring company payouts or payroll-like distributions.
Completing these transactions individually was slow and repetitive, especially for teams managing multiple operational wallets, currencies, and large recipient lists.
The goal was to create a mobile-first mass payout experience that allowed users to prepare, validate, and send large payouts efficiently without losing control over a high-impact financial operation.
Insights
The feature was designed before the product launched and shaped through close collaboration with the PM and stakeholders, informed by domain knowledge and access to users from the target audience.
Several recurring patterns defined the problem:
- Professional users often manage funds across multiple wallets.
- Payouts may contain many recipients rather than a single destination.
- Recurring distributions make rebuilding recipient lists inefficient.
- Imported data can contain invalid addresses, amounts, or network mismatches.
- Balance issues should not force users to rebuild an already prepared payout.
- Blockchain transactions may remain in progress after confirmation.
- All of this complexity still needs to remain manageable on a mobile screen.
Challenge
A mass payout looks simple at the highest level:
Choose recipients → send funds.
In practice, every payout had to coordinate currency and network selection, multiple source wallets, recipient data, validation, available balances, fees, confirmation, and asynchronous blockchain processing.
The challenge was to expose enough control for professional crypto users while keeping the workflow understandable, recoverable, and safe on mobile.
Operational scale
The workflow supported:
- 4 ways to prepare recipient data — manual entry, .XLSX, Google Spreadsheet, or a saved list;
- multiple source wallets within the same payout;
- 2 recovery paths for insufficient balance — top up immediately or save the payout as a draft;
- validation for 4 recipient-data conditions — invalid address, invalid amount, network mismatch, and empty rows;
- 1 structured batch flow for many recipients instead of repeatedly configuring individual transfers.
Design principles
Preserve context during complex configuration
Mass payout required many supporting actions: selecting wallets, choosing currencies, reviewing information, and correcting configuration.
Instead of repeatedly navigating users away from their payout, I used bottom sheets for contextual decisions.
This allowed users to:
- open supporting configuration;
- make a selection;
- close it;
- return immediately to the payout they were already preparing.
The payout remained the primary context while supporting actions appeared temporarily around it.
Make repetitive operations reusable
Recurring payouts should not require recurring setup.
Recipient lists could therefore be saved as presets and later:
- reopened;
- edited;
- saved as a new list;
- or updated in place.
This turned mass payout from a one-off transaction flow into a reusable operational tool.
Design recovery into the workflow
Errors are especially expensive in financial products.
The goal was not simply to prevent users from continuing when something was wrong, but to help them understand what needed attention and recover without losing their work.
Validation therefore happened inside the existing payout context rather than sending users into separate corrective flows.
Key improvements
Support multiple source wallets
Crypto teams often distribute operational funds across several wallets.
Requiring users to consolidate those funds manually before every payout would add unnecessary work.
The mass payout flow allowed users to select multiple source wallets. Funds from the selected wallets were aggregated into the mass payout wallet before distribution to recipients.
This matched the way professional users already organized their assets rather than forcing them into a simpler but less realistic wallet model.
Support multiple ways to prepare recipient data
Recipient data could be prepared directly inside the payout or brought in from existing sources.
Users could:
- enter wallet addresses and amounts manually;
- upload an .XLSX file;
- import data through a Google Spreadsheet link;
- reuse a previously saved recipient list.
That gave users 4 ways to prepare recipient data within the same payout workflow, supporting both occasional payouts and larger recurring operations without forcing every user into the same preparation method.
Make validation actionable
Invalid address
The affected address was highlighted and could be corrected before continuing.
Invalid amount
Incorrect or missing amounts were highlighted directly in the recipient list so users could fix them before continuing.
Network mismatch
Addresses incompatible with the selected network were highlighted before funds could be sent.
Empty rows
Unused rows were simply ignored rather than treated as errors.
This avoided unnecessary interruptions when working with larger imported lists.
Resolve insufficient balance without losing progress
An insufficient balance could be detected after the user had already spent significant time preparing a payout.
Restarting at that point would create unnecessary friction, so the recovery flow was designed around preserving the user’s work.
When the available balance was too low:
- the transfer amount and balance issue were clearly highlighted;
- users could top up the balance immediately and continue the same payout;
- if they could not add funds at that moment, they could save the payout as a draft and return to it later;
- cancelling remained available if they wanted to abandon the transaction.
This turned a blocking financial error into 2 clear recovery paths: resolve it now or continue later.
Make the final financial action inspectable
Before confirmation, users could review the complete payout in one place:
- selected currency;
- source wallets;
- mass payout wallet;
- recipient addresses and amounts;
- total payout amount;
- commission.
The confirmation step made a high-impact financial operation easy to inspect before commitment.
After confirmation, the workflow remained explicit: users saw that the payout had been created, were told that blockchain processing could take approximately 1–10 minutes, and could later see the completed payout in their transfer history.
Making the waiting state explicit reduced the risk of users interpreting processing time as a failure and attempting the payout again.
My role
I designed the mass payout feature end to end as the Product Designer, working closely with the PM, APD stakeholders, and engineers.
My ownership included:
- product definition and information architecture;
- end-to-end flows, wireframes, UI, and prototypes;
- reusable interaction patterns and recipient-list presets;
- validation, error recovery, and transaction states;
- behavioral documentation and engineering handoff;
- implementation review and iteration with developers.
I remained involved throughout development, clarifying wallet behavior, validation, transaction states, and interaction details as technical constraints surfaced.
Outcome
Mass payout became one of Crypto Office’s core product features.
The resulting workflow combined:
- 4 recipient-preparation methods;
- multiple source wallets within one payout;
- 2 recovery paths for insufficient balance — top up now or save as draft;
- validation for 4 recipient-data conditions;
- a single structured payout flow for many recipients instead of repeated individual transfers.
The design:
- reduced repetitive setup through reusable payout presets;
- matched real operational behavior through multiple source-wallet support;
- allowed users to correct validation issues without restarting;
- let users top up and continue the existing payout, or save it as a draft and return later when funds were unavailable;
- made blockchain processing delays explicit after confirmation.
After release, qualitative feedback gathered through support, stakeholders, and the company’s network of core users was strongly positive.
Users who regularly worked with multiple wallets and recurring crypto payouts became active advocates of the feature.