Crypto Payroll Guide: How to Pay Your Team in Stablecoins

Crypto payroll means paying employees or contractors in stablecoins such as USDC, USDT, or EURC, sent from a wallet your business controls to wallets your people control. The core decisions are which token, which chain, and how payouts are batched and recorded. Inzi charges 0% per transaction on every plan, and batch payouts start on the $49/month Growth plan.

What does crypto payroll actually mean?

The phrase covers three different setups, and mixing them up is the most common source of confusion in this topic.

1. Contractor payments in stablecoins. A business pays freelancers or agencies abroad in a dollar- or euro-pegged token. This is the most common case and the one with the fewest moving parts.
2. Employee pay, fully or partly in stablecoins. The employer pays a salary, or a portion of it, in a stablecoin. This is where local employment rules, withholding, and social contributions come into play.
3. Treasury-to-wallet payouts as a funding method. The business keeps its payroll logic elsewhere (a payroll provider, an internal spreadsheet) and uses stablecoin transfers only as the last step that moves value to the payee.

This guide is about the mechanics common to all three: moving stablecoins from a business wallet to many payee wallets, reliably and with a usable record. It does not replace payroll software. Inzi is a non-custodial payment platform, not a payroll-compliance suite, so calculating withholding, issuing payslips, and filing returns sit outside what it does.

Why digital businesses look at it

The reasons that come up most often are practical rather than ideological:

• Payees in several countries, each with different local banking costs and delays.
• Contractors who already hold or prefer dollar-denominated stablecoins.
• Transfers that settle on-chain at any hour, with no bank cutoff.
• A treasury that already holds stablecoins from customer payments, so paying out in the same asset avoids a conversion step.

The last point matters most for businesses that accept stablecoins from customers. If revenue arrives as USDC in a merchant wallet, paying contractors from that same wallet in USDC removes a conversion in each direction.

Which token and chain fit which payee?

Before sending anything, two choices have to line up: the token the payee wants, and the chain they can receive it on. A payee who holds USDT on Tron cannot receive USDC on Base to the same effect without a swap or bridge, and a wrong-chain transfer can be unrecoverable.

This is the per-chain token support on Inzi today:

Chain	USDC	USDT	EURC
Polygon	Yes	Yes	No
Base	Yes	No	Yes
Ethereum	Yes	Yes	Yes
Tron	No	Yes	No
TON	No	Yes	No
Solana	Yes	No	No

The same support as a reference list:

• Polygon: USDC, USDT
• Base: USDC, EURC
• Ethereum: USDC, USDT, EURC
• Tron: USDT
• TON: USDT
• Solana: USDC

No single token runs on all six chains, so a payroll that spans token preferences needs a chain plan.

How payee preference usually drives the choice

A few patterns tend to hold regardless of provider:

• Payees who want euros. EURC is available on Base and Ethereum, which narrows the chain choice immediately.
• Payees who use USDT. Tron and TON carry USDT, and Polygon and Ethereum do as well. Many contractors in regions with heavy USDT usage already have a Tron or TON wallet.
• Payees who want low and predictable network fees. Fee levels vary by chain and by congestion. The chains' own documentation is the place to check current fee mechanics rather than relying on a number in a blog post.
• Payees who are new to crypto. A single chain and a single token reduces mistakes. Supporting four chains for twelve contractors multiplies the ways a payout can go to the wrong place.

A workable approach for a small team is to standardize on one or two chains and ask each payee to confirm a receiving address on that chain, in writing, before the first run.

How does a stablecoin payroll run work step by step?

The mechanics are the same whether the run is five contractors or fifty. What follows is a product-level walkthrough, not a legal procedure.

1. Create the payee list. For each person: legal name or entity, token, chain, and receiving wallet address. Keep this list versioned, because address changes are the most common point of error and fraud.
2. Send a test transfer. A small first transfer to each new address confirms the chain and token match before the full amount moves.
3. Fund the paying wallet. The business wallet needs the payout token plus the chain's native asset to cover network fees. Running out of the native asset mid-run is a routine, avoidable failure.
4. Execute the payouts. Either one transfer at a time or as a batch.
5. The record. Transaction hash, timestamp, token, chain, amount, and payee make up the usual record of each payout. Many accountants also log the fiat value at the time of the transfer.
6. Reconciliation. Many teams match the on-chain transfers against the payee list and the agreed amounts.

An illustrative example

Take a hypothetical business that pays 12 contractors a flat $3,000 each per month, $36,000 in total. All of them have confirmed a receiving address on Polygon and want USDC. The run is 12 transfers of 3,000 USDC each, from one merchant wallet. The business pays network fees in Polygon's native asset on each transfer. If it receives customer payments in USDC on Polygon into that same wallet, nothing is converted at any point. These figures are illustrative only and say nothing about what any provider charges.

What does Inzi cover, and what does it cost?

Inzi is a non-custodial payment platform. Customer payments go straight to the merchant's own wallet, and Inzi does not hold a balance on the merchant's behalf. That shapes how payroll works: the funds that pay your team are in a wallet you control, not in an account Inzi operates.

The pricing is built around a flat monthly fee, not a cut of volume:

Plan	Monthly price	Per-transaction fee	Notes
Starter	$0/month	0%	No subscription, for small merchants
Growth	$49/month	0%	Batch payouts, for growing businesses
Scale	$149/month	0%	For high-volume merchants; contact sales

Two points matter for payroll specifically. First, batch payouts are part of the Growth plan, so a team paying many people in one run is looking at the $49/month tier. Second, the Scale plan is not self-serve: its call to action is to contact sales. For current details on each plan, see Inzi's pricing.

The 0% per-transaction fee applies to Inzi's side. Blockchain network fees are a separate cost set by each chain, and they do not go to Inzi.

What Inzi does not do

To keep expectations accurate, this is what sits outside the scope of this guide and of the product as described here:

• It does not calculate or withhold payroll taxes.
• It does not produce payslips or file returns.
• It does not hold funds in custody for later disbursement.
• Bank-transfer or card-based payout rails are not part of what is shipped today.

A business running employee payroll will typically pair a payroll or accounting system for the compliance layer with a payment platform for the movement of value.

How is crypto pay treated for tax and record-keeping?

This section describes mechanics and cites sources. Rules differ by country, and by whether the payee is an employee or a contractor.

In the United States, the IRS has stated in Notice 2014-21 that virtual currency paid as wages to an employee is taxable to the employee and is subject to federal income tax withholding and payroll taxes, valued at its fair market value in U.S. dollars as of the date of receipt. The same notice says payments to independent contractors in virtual currency are subject to self-employment tax, and that payments of $600 or more may be reportable on an information return. The IRS's own FAQ on virtual currency transactions covers how the dollar value is determined and treated.

Other jurisdictions have their own treatment, and several treat employment pay in crypto as pay in kind or as a partial-salary arrangement with limits. The sources for those rules are national tax authorities and labor ministries, and they change.

What records accountants tend to ask for

Across jurisdictions, the questions that come up are consistent. Many accountants log, for each payout:

• The date and time of the transfer, with the on-chain transaction hash.
• The token and chain.
• The amount in tokens and the fiat-equivalent value at the time of transfer, along with the source of the rate used.
• The payee and the agreement or invoice the payment relates to.
• The sending and receiving wallet addresses.

Because a stablecoin is pegged, its fiat value is often close to face value, but a peg is not a guarantee, and some jurisdictions still expect a rate source for each transaction. Whether an accountant treats a stablecoin payment as a disposal of an asset, and what that means for the business's own gains and losses, depends on local rules.

A consistent export of the transaction history from the paying wallet makes any of these treatments easier to document after the fact.

Is it legal to pay staff in stablecoins?

The answer depends on the country of the employer, the country of the worker, and the worker's classification. Three patterns appear often enough to name:

• Contractors are the simpler case. In many places, a business and an independent contractor can agree on payment in any asset, and the main questions are invoicing and tax reporting.
• Employees are more constrained. Some jurisdictions require wages to be paid in legal tender, or permit alternative payment only for a share of pay or with the worker's written consent.
• Stablecoin regulation is moving. In the EU, the rules for stablecoin issuers and service providers are changing what tokens are available on which venues. A practical read of what this means for payments, and the underlying regulatory detail, is covered by xregos.com, which publishes the legal depth so this blog does not have to.

For payroll, the practical consequence is that the token a team prefers today may be less available through some licensed venues tomorrow. Businesses with EU-based payees often track which of USDC, USDT, and EURC their payees can actually convert to local currency through the venues they use.

What are the tradeoffs of non-custodial payroll?

A payment platform that never holds your funds has a clear upside: no third party can delay, hold, or restrict the money in your wallet. The matching cost is that the wallet's security is entirely the business's job, and that cost is real.

Security and key management

• A single private key controlling the payroll wallet is a single point of failure. A lost key means lost funds, and a stolen key means the same.
• Many teams use a multi-signature or shared-approval setup for the paying wallet so that no single person can send a full payroll run alone. The details depend on the chain and the wallet software.
• Separating the receiving wallet (where customer payments arrive) from a payroll wallet (funded for each run) limits what is exposed at any moment.

Irreversibility

On-chain transfers do not have a chargeback. A payout to a wrong address, or on the wrong chain, is usually not recoverable. This is why the test transfer in the walkthrough above is not optional in practice, and why address changes deserve a confirmation step outside the channel where the request arrived.

Payee-side friction

• Payees need a wallet and need to know how to hold and convert the token.
• Converting to local currency is the payee's problem to solve, and the cost and availability vary by country.
• A payee who loses access to their wallet cannot be paid again to the same address.

Volatility is lower, not zero

Stablecoins are designed to hold a peg to a currency, but they are not bank deposits. Issuers publish their own reserve and redemption information, and the risk profile differs by token. A payroll that depends on one token carries that token's specific risk.

What should a business decide before the first run?

These are the branch points, in the order they usually need answering:

Decision	What determines it
Employees, contractors, or both	Local employment and tax rules for each payee's country
Token	What payees want to hold and how they convert it
Chain	Which chains carry that token, and payee familiarity
Single payments or batches	Run size and plan tier; batch payouts begin on Growth
Wallet security model	Number of approvers, key storage, separation of wallets
Record format	What the business's accountant asks for per transaction

A team that can answer these six rows has most of the design. The remaining work is operational: keeping the payee list current, funding the wallet with enough of the native asset for fees, and running the same checklist every cycle.

For a small business testing the idea with a few contractors, the Starter plan has no subscription and a 0% per-transaction fee. To set up a merchant wallet connection and try it, create an Inzi account. A business that already runs larger recurring payouts can compare the plan tiers on the pricing page.