Underpaying an order, what actually happens

You create an order for 0.05 BTC. You send 0.0498 BTC because your platform deducted its withdrawal fee from the amount rather than adding it. The order expects 0.05 and receives less. What does the system do?

Short answer: it processes what it received, at the locked rate, and pays you the matching amount. Nothing is stuck, nothing is lost, and there is no penalty. The long answer deserves an article, because not every gap is handled the same way.

Why the received amount is almost always different

A deposit exactly equal to the quoted amount is the exception, not the rule. Three mechanical causes:

1. The origin platform's withdrawal fee. Most interfaces offer "send max" or "withdraw all" and deduct their fee from the amount you typed. Type 0.05 and 0.05 minus the fee leaves.
2. Network fees on UTXO chains. On Bitcoin or Litecoin a transaction consumes inputs and creates outputs; fees come out of the difference. A wallet sending "the whole balance" adjusts the amount downward.
3. Display precision. A balance shown as 0.05 may be 0.04999998 in base units. Visual rounding is not accounting rounding.

A system requiring the exact amount to the satoshi would reject nearly every legitimate deposit. That is why the quoted amount is an intention, not a condition.

How an underpayment is handled

When the deposit received is below the quoted amount, the sequence is as follows.

The locked rate applies as is. The rate frozen at order creation does not depend on quantity. It is recomputed on the quantity actually received. You do not lose the benefit of the lock because you sent less.

Variable fees follow the amount. Being a percentage, the spread scales down. Fixed fees do not move: the estimated network cost and the rail fee stay the same. On a small gap that is negligible; on a deposit far below the order the relative share of fixed fees rises. That mechanism is described in Headline rate versus effective rate.

The net is recalculated and displayed. You see the new amount before payout, with the same line-by-line breakdown.

The payout goes out normally, as soon as confirmations are reached.

Only one condition can block it: if the amount received falls below the asset's minimum deposit. That minimum exists because below it fixed costs exceed the deposit's value; it is published on each asset page and repeated on the limits page. In that case the deposit is held and you get two options: top it up with a second send to the same address, or request a return to the origin address, less the network cost of the return.

How an overpayment is handled

The symmetric case, and simpler. The excess is processed with the rest, at the same locked rate, as long as the total stays under the ceiling applicable to your verification level.

If the total exceeds that ceiling, the portion above it is not converted automatically. It waits, with two possible outcomes: you complete verification to unlock a higher tier, or you request the return of the excess. Tiers are published on the identity verification page.

Multiple sends to the same address

The deposit address is dedicated to one order. Several sends to that address during the validity window are added together and treated as a single deposit.

Two important details:

• Each send has its own confirmations. The payout waits for the last send counted to be confirmed, not just the first.
• After the window expires the address is still watched but the rate is not. A late send triggers a new quote, described below.

The deposit lands after the rate expires

This is the most frequent case after underpayment, and the main source of confusion. The lock window — fifteen minutes for a volatile asset, thirty for a stablecoin — is calibrated on the typical confirmation time of a properly priced send. A send with fees set too low regularly overshoots it.

What happens then:

1. The deposit is detected and attached to your order.
2. The initial rate no longer applies. The system produces a new quote at the current rate.
3. You must explicitly accept the new amount. No payout leaves without that acceptance.
4. If you decline, a return to the origin address is offered, less the network cost.

The essential point: we cannot honour an expired rate. Between quote time and deposit arrival, the corresponding market cover no longer exists. A service promising to hold a rate indefinitely would not keep that promise on an adverse move — it would keep it only when convenient.

The wrong network

A different, heavier case. You sent the expected asset, but on a network the order was not expecting — ERC-20 USDT to a Polygon deposit address, for instance.

On EVM-compatible networks the same private key controls the same address on every chain. Recovery is therefore technically possible: it takes manual work on the chain concerned and has a cost, which is deducted from the recovered funds. Timing depends on the queue.

Off EVM, recovery is not guaranteed. Sending BTC to a Bitcoin Cash address, or a memoless XRP deposit, are special cases covered in The missing memo.

The wrong asset

You sent ETH to a deposit address created for ERC-20 USDC. The address is valid, the transaction succeeds, but the order expected something else.

Those funds are caught during reconciliation and handled as a manual case. If the asset is one we accept, a new order can be created at the current rate. If it is not — a token we do not list, an NFT, an enhanced-anonymity asset — we can neither convert nor hold it, and only a return is possible.

The summary

| Situation | Handling | What you need to do | | --- | --- | --- | | Slightly short deposit | Recalculated at the locked rate | Nothing | | Deposit below the asset minimum | Held | Top up or request a return | | Overpayment under the ceiling | Fully processed | Nothing | | Overpayment above the ceiling | Excess held | Complete verification or request a return | | Deposit after rate expiry | New quote | Accept or decline | | Wrong network, EVM chain | Manual recovery | Open a ticket | | Wrong network, non-EVM | Case by case | Open a ticket | | Wrong asset | Manual case | Open a ticket |

Why we do not simply refuse a mismatched deposit

A stricter system is conceivable: accept only the exact quantity, refuse everything else. Some services do exactly that, and it is worth explaining why we do not.

Refusing means returning. Returning costs a network transaction, taken out of your funds, and takes time. On a deposit short by a fraction of a percent — which is the overwhelming majority of mismatches — you would pay a real cost for a difference with no economic meaning.

Refusing also fails to solve anything. The cause of most mismatches is on the sending side: a platform deducting its fee, a wallet adjusting a full-balance send. A rule that rejects those deposits does not stop them happening, it just makes them expensive.

The design choice is therefore to process what arrives, recompute honestly at the locked rate, and show you the new breakdown before anything is paid. The only case where we hold rather than process is a deposit below the asset minimum, and that is arithmetic rather than policy: below it, the fixed costs exceed what you would receive.

How to avoid most of these

• Use the copy button for the amount rather than retyping it.
• Check whether your platform deducts its fee from the amount or adds it.
• Send with normal network fees, not the lowest tier.
• Check the network selector before pasting the address.
• For a large amount, send a test transaction when the network cost allows it.

Concrete cases and procedures are detailed in the help centre, Deposits section.