How Prop Firms Pay Out Traders in Crypto

“Prop firm payout proof.” “Fastest prop firm payouts.” “Prop firm payout leaderboard.” Those are real search phrases, typed by real traders, month after month.

Traders search that way because the payout is the only part of the relationship where a firm has to prove it is real. Everything before it is a promise. That makes the payout rail less of a back office decision than it looks. It is the part of your product that customers write about in public.

This post covers how crypto payouts work for a firm sending a lot of small amounts to individuals in a lot of countries. What the batch flow actually allows, who on your team is permitted to send, what the screening does, and where we do not publish a number.

---

Is payout day currently a spreadsheet and a long afternoon? See how crypto payouts work, or open an account and send a test batch through it.

---

Why payout speed is effectively the product

Evaluation fees pay the bills. The payout is what makes an evaluation fee worth paying. So the speed and reliability of your payout run is doing a share of your acquisition work whether you planned it that way or not.

A firm that pays within hours has a marketing asset it did not have to buy. A firm that pays in nine working days has a support queue, and a support queue eventually becomes a review thread.

The awkward part is that marketing makes the payout promise and finance has to keep it, using whatever rails exist. Those rails were mostly designed for a different shape of payment than this one.

What breaks with cards and wires at this size and frequency

The shape here is specific. Many small payments, to individuals, across a lot of countries, on a schedule you do not fully control, because it depends on when traders request.

Wires. Fixed costs per transfer that do not shrink when the amount does, so a small profit split loses a painful share of its value on the way. Intermediary banks can deduct in transit, which means the trader receives less than the number on their dashboard and opens a ticket about the difference. Cut-off times and weekends add days that have nothing to do with your process. And a return for a name mismatch can land days later, after the trader has already been told the money is on its way.

Card payouts. Push-to-card availability is uneven across countries and issuers, so the same process works for one trader and quietly fails for another. That inconsistency is worse than a slow rail, because it is unpredictable per person and impossible to promise around.

Local methods and e-wallets. Each one solves a region and adds an integration, a reconciliation format and another balance to keep funded. Three rails means three ways to be out of sync at month end.

We worked through the cost arithmetic for high-volume partner payments in a separate post on running mass payouts at volume, and the shape of that problem is the same as yours.

What changes when the payout goes on-chain

Your traders do not need an account with us

Start with the part that surprises people. Recipients do not need a CoinGate account. Our own answer on the payouts page is short: “Recipients only need a compatible wallet address for the selected asset and network. Funds are sent directly on-chain.”

That removes the step where a trader in another country has to register with a company they have never heard of before they can be paid. Every payout method that asks the recipient to sign up loses people exactly there.

However, the requirement does not disappear. It moves to your side. Each row of a batch carries the recipient’s details and not only an address: person or business, name or company code, email, country, the asset and the network, the amount, and a purpose for the payment. For a prop firm that is usually good news, because your own onboarding already holds all of it. Check that before you plan the export from your platform.

What it costs

On the Standard plan a crypto payout costs 0.50 EUR + 0.5%. If the payout involves conversion, the rate is 0.50 EUR + 1.5% instead, and that is a replacement figure rather than something added on top of the first one. Enterprise pricing is custom. Both rows are on our pricing page.

Limits, tiers, and the numbers we do not publish

We do not publish payout minimums or maximums. Minimums depend on the asset and the network, and the values that apply to your account are visible in the dashboard or through the API. There are no verification tiers in the account model either, so there is no tier to climb in order to move more.

If that reads like a dodge, it is at least a consistent one. The same answer sits in our payouts FAQ and in our guide to stablecoin payouts.

Which assets, and the euro problem

Volatility between approval and receipt is a fair concern when the amount is a profit split a trader has already earned. Stablecoins are the usual answer, and there are exactly two on our list: USDC and EURC.

The difference between them matters more than it looks. USDC is payable across seven networks, including Solana, Base, Arbitrum and Polygon. EURC runs on Ethereum only. A firm settling euro-denominated splits in EURC is therefore committing to one network and its fee levels, which is worth checking against your typical payout size before you standardise on it.

Payout, withdrawal, settlement

One vocabulary note, because these three get mixed up in internal documents and then in support replies.

A payout goes to someone else’s external wallet address. A withdrawal goes to your own bank account or your own wallet. Settlement is the moment a customer payment becomes final and is credited to your CoinGate balance, which is not the same thing as money reaching a bank. We separated the three properly in a post on settlement, payouts and withdrawals.

Bulk payouts, by CSV and by API

There are two ways to run a payout batch, and most firms end up using both.

CSV upload in the dashboard

A batch is capped at 300 rows and 1 MB, UTF-8 encoded, so a heavy payout day gets split across several files. The header row has to match the expected columns in the expected order, so the export from your own platform is better built once than repaired by hand every Friday.

Each row carries a destination address and the funds go on-chain to that address. There is no email step in this flow, which is worth stating plainly because people assume otherwise. If you want the email version, that is Payout Links, a separate flow where the recipient supplies their own wallet. A wrong address in a row is a wrong payment, and an on-chain payment cannot be recalled the way a wire sometimes can, so address validation belongs in your platform at the point where the trader saves it, not in a finance review at the end.

Two operational details cause most of the real incidents here:

• A draft batch expires in 5 minutes if it is not confirmed. Treat upload and confirmation as one continuous action, because whoever uploads a file and then walks into a meeting comes back to an expired draft and starts again. Nothing is deducted when a draft expires.
• Identical rows are deduplicated inside a batch. The same beneficiary, the same amount and the same purpose collapse into one payment. If a trader legitimately has two identical payouts in one run, split them across batches or make the purpose distinct.

The API

For firms where payouts are triggered by the platform rather than by a person, the API removes the file entirely. Payouts get created when your own logic says a trader is eligible, which is how a weekly payout day turns into something closer to continuous. We wrote a walkthrough of automating crypto payouts through the API.

One thing to design around. If the sending currency differs from the balance the payout is funded from, an exchange step is required and the payout waits until that exchange is confirmed or cancelled. Conversion is not silent, so build the confirmation into your flow rather than discovering it on payout day.

Who is actually allowed to send one

Access is restricted on purpose, and the role names matter if you are drawing up who does what on payout day.

• Owner and Administrator can execute payouts.
• Accountant and Support can view them.
• Developer has no access to payouts at all, which tends to surprise teams who assume the person who built the integration can also run it.

On top of that, four-eye approval can be switched on so every batch submitted by one person has to be approved by another. The creator cannot approve their own batch, the funds are held while the approval is pending, and a rejection releases the hold back to your balance. It needs at least two users holding Owner, Administrator or Accountant roles. We described the mechanics in more detail in our crypto payouts overview.

There is also a gate before any of this. Sending to third parties is enabled per account after we review what you are paying for and where, so a firm planning a launch should build that lead time into the plan rather than discovering it in the week traders expect their first split.

Status tracking and callbacks

“Where is my money” is the most expensive question in prop firm support. Not because it is hard to answer, but because of how many times it gets asked.

A send request moves through seven statuses, from draft through to completed, failed, expired or canceled, and you can query it at any point. Callbacks push those changes into your system as they happen, which is what lets a trader dashboard show the real state instead of a spinner labelled processing.

Treat callbacks as signals rather than the source of truth. Handle duplicate events safely and confirm the final state through the API before doing anything irreversible on your side, such as marking a split settled in your own ledger.

On top of that, an on-chain payout produces a TXID you can surface to the trader directly, along with the number of network confirmations behind it. A TXID is a verifiable answer, and it ends the conversation in a way that “it has been sent” never does.

The support saving is real, but it is not the main point. A trader who can see the state of their payout does not need to ask. A trader who does not need to ask does not post about it.

The compliance reality of paying individuals across borders

Paying individuals in a lot of countries is a regulated activity. There is a version of this post that glides over that, and this is not it.

We are authorised as a Crypto-Asset Service Provider under MiCA by the Bank of Lithuania, authorisation code LB002323. The same regulator licenses us as a Payment institution to provide transfer services for electronic money tokens, authorisation code LB002324.

On the destination side, the blockchain itself has no country gate. Screening does. Our terms are direct about it: before any payout we may run AML, CFT, sanctions and fraud checks, and transacting with a sanctioned person, entity or jurisdiction is prohibited outright. The destination wallet is screened too. Eligibility therefore follows that screening rather than a fixed list you can design around in advance, so word the payout promise on your own website with that in mind. A promise that assumes every trader everywhere gets paid identically will eventually be broken by something outside your control.

The sender side is the more constrained side, and it is the one people forget. The list of countries we can onboard a business from is finite, and considerably shorter than the list of places a payment can reach, so check your own jurisdiction before you plan a migration around us.

As for whether we serve prop firms specifically, we do not publish a policy by vertical, and this post is not the place to invent one. What does exist is clause 12 of our general terms and conditions, and it is conditional rather than absolute. It prohibits operating or facilitating unlicensed or unregulated financial services, including investment schemes, securities, derivatives and synthetic assets. Whether your model sits inside that sentence is the question onboarding will ask, so answer it before you apply.

If your firm has already been labelled high risk by a card acquirer, that is a related but separate conversation, and we covered it in what the high risk label actually changes.

Frequently asked questions

Do traders need a CoinGate account to receive a payout?

No. They need a compatible wallet address for the asset and network you are sending, and the funds go on-chain to that address. Your side supplies the rest of the row, including the trader’s name, country and a purpose for the payment.

How big can a payout batch be?

A CSV batch is capped at 300 rows and 1 MB, and the file needs to be UTF-8. Bigger payout days get split across several batches. A draft also expires in 5 minutes if it has not been confirmed, so upload and confirm in one sitting.

What are the minimum and maximum payout amounts?

We do not publish them. Minimums depend on the asset and the network, and the values that apply to your account are visible in the dashboard or through the API. There are no verification tiers, so there is no upgrade path that changes them.

What does a crypto payout cost?

On the Standard plan it is 0.50 EUR + 0.5%. If the payout involves conversion it is 0.50 EUR + 1.5% instead, not on top. Enterprise pricing is custom.

Can we pay traders in any country?

No, and it would be careless to tell you otherwise. The networks themselves reach anywhere, but every payout passes through sanctions and compliance screening, and a sanctioned destination or party will not clear it. Check the destinations that matter to your trader base instead of assuming full coverage.

Who on our team can run payout day?

Owner and Administrator roles can execute payouts. Accountant and Support can view them. The Developer role cannot execute them at all. With four-eye approval enabled you need at least two people holding Owner, Administrator or Accountant roles, and whoever created a batch cannot be the one to approve it.

The bottom line

Prop firms compete on payouts and get judged on payouts, so the rail underneath deserves more attention than it usually gets. Crypto fits the shape of the problem, which is many small payments to individuals across borders.

The specifics that matter are ordinary ones. No account needed on the trader’s side, though your side supplies their details. Batches of up to 300 rows, confirmed in one sitting. Two stablecoins, one of which runs on a single network. Roles that decide who is allowed to send. Callbacks and a TXID so nobody has to ask where the money is. And screening that decides who can actually be paid.

Get those right and payout day stops being the thing your traders write about.

Still running payouts off a spreadsheet? See how our crypto payouts work, or start with us and send a test batch first.