What a withdrawal actually costs, and why the number moves

We are not going to give you a table of withdrawal fees. It would be right on the day it was written and quietly wrong within a month, and you would have no way of telling which. What does not expire is the structure underneath it.

Why there is no fee table here

Two independent things move, on different schedules, and a published figure is the product of both.

The chain's own cost conditions change continuously with demand for block space. The platform's published fee for that chain is a business decision, revised on no fixed schedule and with no announcement. A table freezes the second while the first keeps moving, and the result looks authoritative in exactly the way that misleads.

There is also an editorial reason worth stating. The source contains an unregistered referral arrangement. A table of withdrawal costs across platforms would be an easy place to shade a comparison and a hard place for you to check. Publishing structure instead of numbers removes both the temptation and the need for you to trust us about it.

The structure is durable. Knowing that a chain prices by transaction size rather than by amount tells you that splitting one withdrawal into five costs roughly five times as much, and that stays true regardless of what any page says today.

Three ways a chain prices a transfer

By how much room the transaction takes

On the Bitcoin family, the fee tracks the data size of the transaction, not the value being moved. Sending a very large amount and a very small one cost about the same if the transaction structure is similar.

The structure part is not a technicality. A transaction assembled from many small prior receipts takes more room than one assembled from a single large one, and therefore costs more, for the same amount sent. This is why an account funded by many small deposits can face a surprisingly expensive withdrawal later — the cost is a consequence of history, not of the transfer.

The unit rate floats with competition for block space, so the same transfer can cost several times more during busy periods than quiet ones.

By computation multiplied by a floating unit price

On the Ethereum family, every operation consumes a fixed quantity of computation, and the fee is that quantity multiplied by a unit price set by current demand.

The quantity is predictable: a plain transfer consumes a known amount, a token transfer more, a contract interaction considerably more. The unit price is not predictable at all, and it can rise many times over during congestion and fall back within hours.

This model has the widest quiet-to-busy spread of the three, which has a practical implication: on this family, waiting is a genuine cost-reduction strategy, in a way it is not on chains with near-fixed pricing.

A near-fixed, very low fee

Some chains are designed so that per-transaction cost stays very low and barely moves with network conditions. For an ordinary transfer this is the cheapest and by far the most predictable of the three.

The honest framing is that the cost has not disappeared, it has been relocated. Chains achieve very low fees through design choices with consequences elsewhere — in validator count, in hardware requirements for running a node, in how much historical data remains readily available. Whether those trade-offs matter to you depends on what you are using the chain for, and for moving funds between two places you control they may not matter at all. What they are not is free.

A note on layer two

Layer-two networks execute transactions cheaply and periodically post data back to their main chain, so their cost has a floor that follows main-chain conditions. Day-to-day transfers are very cheap; the number to check before you commit is what it costs and how long it takes to move back to the main chain, which is a separate operation with a separate price.

Why the fee you pay is not the fee the chain charged

Most platforms charge a flat published fee per chain and update it periodically. The real on-chain cost floats continuously. The two are therefore almost never equal, and both directions of the gap are worth understanding.

When the network is quiet, the flat fee usually sits above the real cost and the platform keeps the difference. When the network is congested, the real cost can rise above the flat fee and the platform absorbs it — or suspends withdrawals on that chain until conditions settle.

That suspension is the part worth knowing in advance. It is not usually a distress signal about the platform; it is the flat-fee model meeting conditions it was not priced for. But if it happens on a day you need to move funds, knowing it is a normal occurrence is considerably more comfortable than discovering it during an emergency.

Some platforms pass through the floating cost rather than charging flat. That is more honest arithmetic and less predictable budgeting. Neither approach is wrong; they optimise for different things, and the fee page tells you which one you are dealing with.

The choice that actually saves money

Widely-issued assets exist on several chains simultaneously. The same asset, the same amount, the same platform, sent over a different chain, can cost a small fraction of the price. No difference between platforms comes close to this.

So the sequence that saves the most is: check which chains your platform supports for that asset, check which of those the destination supports, and pick the cheapest chain both ends can handle.

Two warnings, both unforgiving.

The destination must support the chain you send on. Address formats sometimes look identical across chains, which means the interface can accept the transfer without complaint and the assets arrive at a place nobody can reach. Recovery ranges from a slow support process to genuinely impossible. This is the most common way people lose funds during an entirely ordinary transfer, and it happens to experienced people.

Cheap to arrive is not cheap to leave. If the destination chain is somewhere you will later need to move off, the exit cost belongs in the same calculation. Optimising one leg of a round trip is how people end up holding an asset on a chain where consolidating it costs more than they saved.

The minimum, which is the real constraint on small transfers

Alongside the fee, every chain on a platform carries a minimum withdrawal amount, and for small balances this is the binding constraint far more often than the fee is.

The minimum is generally set as some multiple of the fee, which means it moves when the fee moves. A chain whose costs have risen can have a minimum that has risen with them, and a balance that was withdrawable last month may not be this month — without anything having happened to the balance.

This produces a genuinely annoying situation that people meet without warning: a balance too small to withdraw on the chain it is sitting on. There are usually two ways out and both are worth knowing before you need them. Convert to an asset with a cheaper chain, which costs a trade and its spread but changes which minimum applies. Or add to the balance until it clears the minimum, which is fine if you were going to anyway and is otherwise throwing good money after a stranded amount.

The general lesson is about sequencing rather than arithmetic. The cost of getting an asset out belongs in the decision at the moment you put it in, and on small amounts it can exceed anything you were optimising on the way in. The fee page shows both the fee and the minimum in the same table; the second column is the one people do not read.

The field that is not optional

Some chains require a second piece of information alongside the address — a memo, a tag, a note, depending on the chain's own terminology. It exists because on those chains an exchange holds many users' funds at one address, and the memo is what identifies which account an incoming transfer belongs to.

Omit it and the transfer succeeds. The chain records it, a block explorer shows it confirmed, and the funds arrive at an address that has no idea they are yours. Recovery is a support process with no guarantee of success, and the amount of effort involved is unrelated to the amount sent.

This is worth separating from the ordinary wrong-address problem because it feels different. Nothing looks wrong at any point. The withdrawal screen accepted it, the transaction confirmed, and the failure is invisible until you notice the balance never appeared.

Two habits close it. When a platform shows a memo field, treat it as mandatory rather than optional, because on those chains it is. And when withdrawing to another exchange, take both the address and the memo from that exchange's deposit screen at the same moment — copying the address today and the memo from a note you saved last month is how they end up mismatched.

Why many small deposits cost you later

On the chains priced by transaction size, there is a cost that accumulates quietly and appears only when you try to leave.

A wallet's balance is not a single number; it is a collection of separate prior receipts. When you spend, the transaction has to reference enough of those receipts to cover the amount, and each one referenced takes room, and room is what you are charged for.

So a wallet funded by fifty small deposits carries an expensive withdrawal even though the total is modest, while a wallet funded by one large deposit of the same total does not. The difference can be several multiples, for an identical transfer.

Two things follow. If you are accumulating on a chain of this family, fewer larger transfers cost less than many small ones — the fee is paid on the way in as well as the way out. And if a wallet has already accumulated many small receipts, consolidating them during a quiet period costs one transaction at a low unit rate rather than one transaction at whatever the rate happens to be on the day you need to move.

This has no equivalent on the computation-priced family, where a transfer costs what a transfer costs regardless of how the balance was assembled. It is a good illustration of why knowing which model a chain uses is worth more than knowing today's figure for it.

How to check the current figure

Three sources, in order of authority:

1. The withdrawal screen, after you have entered an amount and chosen a chain. This is what you will be charged. It is the only definitive source, and it overrides everything else.
2. The platform's withdrawal fee page. Usually correct, sometimes behind the interface.
3. A block explorer or fee estimator for the chain. Tells you what the network currently costs, which is what lets you judge whether the platform's flat fee is reasonable at this moment.

If the first two disagree, the first wins. If the first looks far out of line with the third, waiting a few hours often resolves it — on the computation-priced family especially, where the spread between quiet and busy is largest.

If you want the mechanics for a specific chain family without the numbers, the pricing-model lookup sets out how each one is built and what moves it. And if the withdrawal you are planning is your first on a new platform, do it small first: a small withdrawal test costs one fee and tells you things no fee page can.