What is the best way to pay a team in crypto?

The best way to pay a team in crypto depends on one thing before any other: whether the people you pay are employees or contractors. Seven families of methods do the job (transfers by hand, a batch from a multisig wallet, a crypto payroll provider, an employer-of-record or contractor platform, a streaming tool, an exchange's batch withdrawal and, for one specific case, an onchain payment router), and what separates them is who produces the payslips and filings, who holds the funds before pay day, and how many approvals stand between a mistake and a final transfer.

This article is written for the founder or operations lead of a company or collective that pays five to fifty people in several countries, partly or wholly in a stablecoin. It compares the methods on the same criteria, then runs one monthly pay run through each of them. Employment and tax rules change from one country to the next, so what follows is general information, not legal or tax advice.

Which methods can pay a team in crypto, and what separates them?

Seven families of methods can pay a team in crypto, and the first thing that separates them is who holds the money before pay day: your own wallet, a provider, an exchange, a contract, or nobody at all. The second is whether the method pays fixed amounts on a schedule, which is what a payroll is, or divides one incoming payment by percentage, which is something else.

Read the last row carefully. A router does not draw on a treasury and does not pay salaries; it only exists when a client pays for a piece of work that several people share. It has its own section further down, and it is absent from most of the payroll comparison for that reason.

What controls, recipient requirements and paperwork come with each method?

Controls, recipient requirements and paperwork are where the methods differ most: only payroll providers and employer-of-record platforms produce payslips and filings, and only some methods force a second person to approve a run. Every other method moves money correctly and leaves the documents to you.

Two points in that table carry more weight than the rest. The first is that a wallet's approval rule is enforced by the wallet: a two-of-three multisig cannot send a payroll with one signature, whereas a rule written in a procedure can be skipped on a busy day. The second is that "payslips in supported countries" is a real limit. A payroll provider that files in six countries is a transfer tool in the seventh, and you are back to doing that country's paperwork yourself or through a local accountant.

Does it matter whether the person is an employee or a contractor?

Whether the person is an employee or a contractor matters more than any tool, because employment law, payroll tax and minimum-wage rules apply to an employee whatever currency the wage is paid in. Paying in a stablecoin changes the rail, not the status of the person or the obligations of the employer.

For an employee, pay day produces more than a transfer. In most countries the employer must calculate tax withholding and social contributions, pay them to the authorities in local currency, issue a payslip, and respect minimum-wage and overtime rules. A wallet transfer does none of that. If you send an employee their full gross salary in stablecoins and file nothing, the payment arrived and the payroll did not happen.

The United States gives two clear illustrations of how national rules treat crypto wages. The Internal Revenue Service, in Notice 2014-21 and its published questions and answers on virtual currency, states that virtual currency paid by an employer as remuneration for services is wages: it is subject to federal income tax withholding and to the social security and unemployment taxes, it is reported on Form W-2, and it is measured at its fair market value in US dollars on the date of receipt. The same guidance treats virtual currency received by an independent contractor as self-employment income, also valued in dollars at the date of receipt. Separately, a US Department of Labor regulation under the Fair Labor Standards Act says the minimum wage and overtime the Act prescribes must be paid in cash or a negotiable instrument payable at par. State wage-payment laws add their own conditions, and other countries have their own rules, some requiring wages in legal tender or local currency. Check the rule where each employee works before promising a salary in crypto.

For a contractor, the picture is lighter. The contractor invoices, you pay the invoice, and each side reports its own taxes. Any wallet-based method can pay a contractor's invoice properly, provided you keep the invoice, the amount in the currency of the contract, and the transaction reference together. The risk on this side is misclassification. Employer-of-record platforms exist for the person who is in fact an employee in a country where you have no entity: a local entity becomes the legal employer in the person's country and runs the local payroll, and the stablecoin, where offered, is only how the net pay is delivered.

A mixed arrangement is common and often the practical answer for employees: the statutory part (taxes, contributions and at least the legally required wage) goes through a local payroll in local currency, and an agreed part of the net pay is delivered in stablecoins where the country allows it.

Stablecoin or volatile token: when is the amount fixed?

The amount of a crypto payment is fixed either in a currency or in tokens, and the contract must say which and at what moment the conversion is made. A salary of $5,400 paid in a dollar stablecoin is 5,400 units whatever the day; the same salary paid in a volatile token is a number of tokens that depends on the price used and the minute it was read.

With a dollar stablecoin the question almost disappears, which is why most teams that pay in crypto use one. The person knows what they will receive, your books carry the same figure as the contract, and the tax value at the date of receipt is the face amount or close to it. Two things remain to state in writing: which stablecoin and which network, since the same stablecoin exists on several networks and an address on one may not be usable on another; and who bears the network fee, which is normally the sender.

With a volatile token, three moments can each fix the amount: the date of the contract, the date the pay run is prepared, or the moment of the transfer. The contract should name the reference currency, the price source and the time the price is read. Take a contributor owed $5,400, paid in a token priced at $2,700 when the run is prepared: they receive 2 tokens. If the token falls 8% before they convert, those 2 tokens are worth $4,968 and the person has absorbed a loss of $432 on a month of work. In both cases the tax value is generally the value on the date of receipt, as in the US guidance above, so a recipient can owe tax on $5,400 while holding $4,968.

Streaming changes the timing rather than the unit. A stream of $7,500 over a 30-day month accrues $250 a day, a little under a third of a cent per second, and after 12 days the recipient can withdraw $3,000. Nothing in that removes the questions above: the stream is still denominated in one token, and its value at each withdrawal is what counts for the person receiving it.

What does a monthly run to eight people look like under each method?

A monthly run to eight people is eight transfers signed one by one when done by hand, and a single approved transaction or a single funding payment under every other treasury method. What changes with the method is the number of things the company signs, who approves them, and what record is left.

Here is a worked example. A studio pays $38,400 a month in a dollar stablecoin to eight people. Three are employees, paid $7,500, $6,800 and $6,200, which is $20,500. Five are contractors, paid $5,400, $4,600, $3,500, $2,800 and $1,600, which is $17,900. The amounts shown are the stablecoin amounts each person receives; for the employees they are net of whatever a payroll withheld.

The run is the same $38,400 in every row; only the handling differs. Under a payroll provider or an employer-of-record platform the $20,500 of employee pay arrives with its payslips. Under the four other treasury methods that $20,500 arrives as plain transfers, and the withholding, contributions and payslips for those three people still have to be produced somewhere else.

Over a year, the gap in manual work becomes visible.

Fewer signed transactions is not automatically safer. A batch carries eight lines in one approval, so an error in the list goes out eight times as fast; the gain comes only when the list itself is controlled, which is the subject of the pay-run section below.

What does a wrong address cost under each method?

A wrong address costs the full amount of the line under any method that ends in an onchain transfer, because that transfer is final and only the holder of the receiving address can send the money back. The debt to the person does not disappear: the company still owes the pay, so the mistake is paid twice.

In the worked example, sending the $4,600 line to a wrong address and then paying the contractor again brings the month to $43,000 instead of $38,400. If the address belongs to someone reachable, such as a former contributor whose line was not removed, recovery depends on their goodwill; otherwise the amount is gone.

The methods differ in who types the address and who answers for it:

• Transfers by hand. The sender pastes each address at each run. The exposure is renewed eight times a month, and the company bears the loss.
• Multisig batch. Addresses sit in a list that signers can read before approving. The error has to pass two people, and the company bears the loss if it does.
• Crypto payroll provider and employer-of-record platform. The recipient usually enters and confirms their own payout address in their account. An error then starts on the recipient's side, and the provider's terms say who bears it; read them.
• Streaming tool. The address is entered once, when the stream is opened. A stream to a wrong address accrues until someone notices and stops it, so the loss is the amount streamed up to that point, where the tool lets the sender cancel.
• Exchange or custodian batch withdrawal. An address allowlist, where the platform offers one, blocks withdrawals to addresses not approved in advance. Once a withdrawal is broadcast it is as final as any other transfer.
• Onchain payment router. Destinations are fixed and signed before the client pays, so an address is checked by its owner before any money moves.

A wrong network is the same mistake under another name. An address copied correctly but used on a network the recipient's wallet or exchange account does not support can leave the funds out of reach. Ask each person for the address and the network together, and write both on the list.

Which controls should every pay run have?

Every pay run needs four controls whatever the method: a verified address list, a test payment to any new or changed address, approval by a second person, and a record that ties each transfer to a payslip or an invoice. Tools make these controls easier or enforce them; none of them supplies all four on its own.

Two details make these controls hold over time. Separate the roles: the person who can change the address list should not be the only person who can approve a run, otherwise the second approval protects nothing. And remove people on the day they leave; a list that still carries last quarter's contributors is the most common source of a payment nobody intended.

Where does an onchain payment router fit, and where does it not?

An onchain payment router fits one situation in a team's finances: a client's payment for a project is divided among the people who worked on it, by agreed percentages, at the moment the client pays. An onchain payment router is not a payroll tool: it does not pay salaries from a treasury, does not run on a schedule and produces no payslip or filing.

Shaka is one such router. Each party's share is set as a percentage of the deal, and each recipient can sign their share before the client pays, which costs them nothing. The client pays once, through a payment link, and every party receives their share at the same moment, in one transaction. Shaka routes the payment and never holds the funds. Destinations are fixed and signed before the payment, so the money cannot be redirected at the last minute. The payment is onchain and final, every party can see that the others were paid, and a payment record can be kept for the file. A deal has at most 20 recipients.

A second worked example shows the case. A client pays $24,000 for a project delivered by four parties: the studio at 40%, a designer at 25%, a developer at 25% and the person who introduced the client at 10%.

• Through the studio's wallet. The client pays $24,000 to the studio. The studio keeps $9,600 and sends $6,000, $6,000 and $2,400 in three transfers: four transactions in all, with $14,400 belonging to others sitting in the studio's wallet until it pays them.
• Through a router. The client makes one payment of $24,000. The same transaction delivers $9,600, $6,000, $6,000 and $2,400 to the four parties. Nobody holds anyone else's share, and nobody waits for the studio's next pay run.

The limits are just as plain. A router needs an incoming payment to divide, so it cannot pay the eight people of the monthly example from the treasury. It works in percentages of a deal, not in fixed monthly amounts. It handles no withholding, and the tax and status questions for each recipient stay exactly as described above. A team with salaried employees needs a payroll for them whatever it uses for project payments.

How do you choose a method for your team?

Choose by status first, then by team size, then by who you are willing to let hold the funds. No method is the best in general; each one answers a different combination of those three points.

• You have employees in countries where a provider or a platform operates. Use a crypto payroll provider if you already have a legal entity there and want payslips and filings handled; use an employer-of-record platform if you have no entity in the country. The stablecoin is then a payout option on top of a compliant payroll.
• You have employees in a country no provider covers. Run a local payroll through a local accountant for the statutory part, and deliver the agreed crypto portion by multisig batch if local rules allow it.
• You pay only contractors, five to fifty of them, against invoices. A batch from a multisig wallet gives one transaction a month, an approval rule enforced by the wallet, and funds that stay under your keys. Add the four controls and an invoice file.
• You pay fewer than five or six people and rarely. Transfers by hand are acceptable if a second person checks each address before sending. Move to a batch when the list grows or when the same person prepares and sends.
• Your funds already sit on an exchange or with a custodian. Its batch withdrawal saves a transfer to a wallet first. Accept that the platform holds the money until pay day, turn on address allowlists where offered and export the history after each run.
• Contributors want access to pay as it is earned, or leave mid-month often. A streaming tool pays to the second and stops when stopped. It ties up the deposit in advance, and it suits a handful of streams better than fifty.
• The team is paid out of client payments, project by project. An onchain payment router divides each client payment by agreed shares when it arrives. Keep a treasury method for anything that is a salary.

Many teams end up with two methods rather than one, for instance a payroll provider for the employees and a multisig batch for the contractors. That is a sound result, as long as each person appears on one list only and each payment can be traced to a payslip, an invoice or a signed share.