A Bitcoin network fee pays for recording an on-chain transaction. During a BTC exchange, that fee may apply when you send BTC to the service, when the service sends BTC to you, or at both stages if two separate Bitcoin transactions are required. It is not automatically the same as an exchange fee, a quoted rate adjustment, or a withdrawal charge.
Key Takeaways
- The on-chain fee is the difference between a Bitcoin transaction’s total inputs and total outputs.
- Its size depends mainly on the transaction’s virtual size and fee rate, not on the market value or BTC amount being transferred.
- A service charge shown to one customer may not equal the fee visible in the blockchain, particularly when several payouts are included in one transaction.
- A high fee rate can improve a transaction’s relative position for confirmation, but no ordinary fee estimate guarantees inclusion in a particular block.
- Before approving an exchange, separate the quoted exchange result, service charges, and any BTC network or withdrawal fee.
The Minimum Vocabulary
| Term | Meaning | Why it matters during an exchange |
|---|---|---|
| Network fee | The difference between the value of all transaction inputs and all transaction outputs. A miner may claim it when including the transaction in a block. [1] | It is the actual on-chain cost of the transaction, not a general label for every deduction made by a service. |
| Fee rate | The fee paid per unit of virtual transaction size, commonly displayed as satoshis per virtual byte, or sat/vB. | Transactions competing for block space are assessed by fee rate rather than by the BTC amount sent. Bitcoin Core fee estimation also works with virtual transaction size. [2] |
| Virtual size | A size measurement that accounts for the SegWit witness discount. It may differ from the transaction’s serialized byte size. [3] | More or heavier inputs and outputs generally produce a larger transaction and therefore a higher total fee at the same fee rate. |
| UTXO | An unspent transaction output that can be selected as an input for a new transaction. A wallet balance may consist of one UTXO or many separate UTXOs. [1] | Spending several UTXOs usually requires more transaction data than spending one suitable UTXO. |
| Mempool | A node’s pool of valid transactions waiting to be confirmed. Bitcoin Core exposes its transaction count, virtual size, fees, and minimum accepted fee rate. [4] | A transaction visible in a mempool has been broadcast but has not necessarily been included in a block. |
| Confirmation | The transaction receives its first confirmation when it is included in a block. Each subsequent block increases its confirmation count. [5] | An exchange service may wait for a direction-specific number of confirmations before processing deposited BTC. |
What Determines the Bitcoin Network Fee?
A useful approximation is:
Total network fee = transaction virtual size × selected fee rate.
This formula explains why sending more BTC does not necessarily require a larger fee. A transaction sending a large value from one suitable input can be smaller than a low-value transaction assembled from many inputs.
Transaction structure
Bitcoin does not deduct funds from a single account balance. A transaction consumes one or more UTXOs and creates new outputs. Those outputs can include the recipient’s payment, change returned to the sender, and payments to other recipients. Any input value not assigned to an output becomes the transaction fee. [1]
Each additional input or output adds data. The address and script types used by the inputs and outputs also affect virtual size. The final size cannot be inferred from the BTC amount alone.
Demand for block space
Fee rates respond to competition among unconfirmed transactions. Bitcoin Core’s fee estimator calculates an approximate fee rate for a chosen confirmation target using previously observed transactions and blocks; it can return an error when insufficient data is available. The result is an estimate, not a promise that a transaction will confirm within the selected number of blocks. [2]
Who constructs the transaction
When you deposit BTC, your wallet usually constructs and broadcasts the transaction, so the wallet’s coin selection and fee settings determine the on-chain fee. When receiving BTC from an exchange, the service usually constructs the payout transaction and chooses its inputs, outputs, timing, and fee rate.
A payout may contain outputs for several customers. In that case, the blockchain shows one total fee for the complete transaction. A customer-facing withdrawal or network charge may be allocated according to the service’s own policy, so it should not automatically be interpreted as that customer’s precise share of the miner fee.
Mechanism Map: From Exchange Request to Confirmed BTC
| User action | What happens in the service or wallet | What happens in Bitcoin | Observable result | How to verify it |
|---|---|---|---|---|
| Choose an exchange direction involving BTC. | The interface presents an estimated or fixed exchange result and any disclosed charges under the applicable terms. | No Bitcoin transaction exists merely because a quote is displayed. | There is an order summary but no transaction ID. | Check which amount is sent, which amount is expected, and whether network and service charges are shown separately. |
| Provide a Bitcoin receiving address or request a deposit address. | The service records the address associated with the order. | No transfer occurs until a valid transaction is signed and broadcast. | The order waits for payment or payout. | Compare the complete address, confirm that Bitcoin mainnet is the required network, and avoid relying only on its first and last characters. |
| Send BTC to the deposit address. | Your wallet selects UTXOs, creates outputs, calculates change, sets a fee rate, signs the transaction, and broadcasts it. | Nodes validate the transaction. If accepted, it can enter mempools and compete for block inclusion. | A transaction ID appears; initially the transaction may have zero confirmations. | Use the TXID in a reputable Bitcoin block explorer and verify the destination output, status, fee, virtual size, and fee rate. |
| Wait for the required deposit confirmation status. | The service monitors the deposit under its processing and compliance rules. | A miner may include the transaction in a block; later blocks add confirmations. | The explorer changes from unconfirmed to one or more confirmations. | Match the TXID and destination amount, then compare the confirmation count with the order status. |
| Receive BTC as the exchange output. | The service constructs or schedules a payout, possibly with other outputs, and broadcasts it. | The payout transaction enters the fee market and awaits block inclusion. | The service can provide a payout TXID, and the receiving wallet detects the transaction. | Confirm that the expected address appears as an output and distinguish the output amount from the transaction’s total fee. |
| Wait for settlement. | The receiving application updates the balance according to its own confirmation policy. | The transaction gains confirmations as new blocks are added. | The wallet or service marks the transfer as confirmed or available. | Check the same TXID rather than relying solely on a status message or screenshot. |
A Realistic Exchange Scenario
A user wants to exchange BTC for another supported asset. Before creating the order, the user checks that the required direction is currently available and reviews the quoted output and disclosed charges. Availability of a particular pair, network, or direction should not be assumed merely because both assets are supported separately.
The service supplies a Bitcoin deposit address. The user verifies that it is intended for native Bitcoin, copies it through the authenticated order page, and checks the full address before sending. The user’s wallet selects several UTXOs, adds a change output, estimates a fee rate, and broadcasts the deposit.
The resulting TXID reveals the transaction’s inputs, outputs, virtual size, total fee, fee rate, and confirmation status. The deposit fee is determined by the wallet-created transaction. It is not determined solely by the amount being exchanged.
After the service recognizes the required confirmation status and completes any applicable checks, it processes the exchange under the order terms. If the chosen output were BTC instead, the service would construct the outbound Bitcoin transaction. The fee shown on that payout transaction would represent the entire transaction, which could contain multiple customer outputs.
This scenario does not establish a universal processing time, confirmation requirement, fee, limit, or available pair. Those conditions depend on the direction, current network state, service terms, and any compliance review applicable to the operation.
How to Read the Numbers Before Confirming an Exchange
| Displayed item | What it may represent | Question to ask |
|---|---|---|
| Exchange rate | The conversion relationship used for the order. | Is the quote fixed for defined conditions or recalculated before execution? |
| Amount you send | The amount expected at the service’s receiving address. | Must the wallet fee be paid in addition to this amount, or will the wallet subtract it? |
| Amount you receive | The expected output after the deductions disclosed in the order. | Can the received amount change if the actual deposit differs from the order? |
| Service or exchange fee | A charge for processing the conversion. | Is it separate from the exchange rate and the blockchain fee? |
| Network or withdrawal fee | A charge associated with sending the output asset on-chain. | Is it fixed by the service, estimated, or reflected directly in the final output? |
| On-chain transaction fee | The mathematical difference between all inputs and outputs in the broadcast Bitcoin transaction. | Does this belong to your deposit transaction or to a service-created payout transaction? |
Do not compare two services using only a field labelled “network fee.” Compare the complete outcome: the amount sent, the final amount received, the quoted rate, and every disclosed deduction. Labels and fee-allocation methods can differ even when both services ultimately use the same Bitcoin network.
What You Can and Cannot Conclude from the Blockchain
What can be verified
- Whether a transaction with the stated TXID is visible.
- Which Bitcoin addresses or scripts received its outputs.
- The value of each output.
- The transaction’s total on-chain fee, virtual size, and resulting fee rate when the necessary input data is available.
- Whether it is unconfirmed or included in a block, and how many confirmations it has.
Bitcoin Core exposes transaction size, virtual size, weight, inputs, outputs, and confirmation-related data through its transaction RPCs. [5]
What the blockchain does not prove by itself
- How a service calculated its exchange rate or allocated a customer-facing withdrawal charge.
- Which output belongs to which customer unless the address is already known.
- Whether an order passed internal processing or compliance checks.
- Why a service waited before broadcasting a payout.
- That a displayed service fee was paid entirely to the miner.
- That an unconfirmed transaction will enter the next block.
The model applies directly to native on-chain Bitcoin transactions. It should not be transferred unchanged to custodial balance updates, internal account transfers, wrapped representations of BTC, payment channels, or another blockchain. Those systems can have different fee and settlement mechanisms.
Common Failure Points and Their Visible Signs
| Problem | Observable sign | What to check |
|---|---|---|
| The wallet subtracts the fee from the intended deposit. | The service receives less BTC than the order requested. | Review whether the wallet’s “subtract fee from amount” option was enabled and compare the actual destination output with the order amount. |
| The fee rate is low relative to competing transactions. | The TXID remains unconfirmed while transactions with higher effective fee rates are confirmed. | Inspect the transaction’s fee rate and current fee estimates. A mempool presence confirms broadcast status, not a specific confirmation time. |
| The service has not broadcast a payout. | No payout TXID is available and the receiving address shows no corresponding transaction. | Check the order status and contact support through the authenticated service interface. Network congestion cannot explain a missing on-chain transaction before broadcast. |
| The payout is broadcast but still unconfirmed. | A TXID exists, the correct output is visible, and the confirmation count is zero. | Separate service processing from network confirmation. Once broadcast, confirmation depends on transaction validity, fee conditions, package relationships, and block inclusion. |
| The wrong address or network is used. | The expected destination does not appear in the Bitcoin transaction, or the provided identifier belongs to a different system. | Stop before sending. Confirm the asset, native network, full address, and order details. Bitcoin transactions are not designed to be reversed after confirmation. |
| A phishing page substitutes an address. | The copied address changes between the order page, clipboard, wallet, or signing device. | Verify the domain and session, compare the entire address on the signing screen, and distrust addresses received through unsolicited messages. |
| The service’s displayed charge is mistaken for the miner fee. | The customer deduction differs from the fee shown for the complete payout transaction. | Check whether the payout contains multiple outputs and review how the service describes its withdrawal or network charge. |
| Compliance review changes the processing flow. | The deposit is confirmed, but the order requests information or remains under review. | Consult the requirements for that specific direction before creating an order. Verification conditions can depend on the transaction and compliance results. |
Pre-Exchange Checklist
- Confirm that the required BTC pair and direction are currently available.
- Identify which party will create each Bitcoin transaction: your wallet for a deposit, the service for a payout, or both.
- Separate the exchange rate, service fee, network or withdrawal charge, and final amount received.
- Check whether your wallet adds the mining fee on top of the payment or subtracts it from the destination output.
- Verify that the address is for the intended native Bitcoin transaction.
- Compare the entire destination address on the final signing screen.
- Save the order identifier and TXID, but never expose seed words or private keys.
- Use the TXID to verify the destination output and confirmation status independently.
- Review current verification and compliance requirements for the selected direction before sending funds.
Once these points are clear, the next practical step is to check the available BTC exchange direction and its fee breakdown before creating an order.
Understanding Check
You should now be able to explain and verify the following:
- Why the BTC amount does not set the network fee: the fee follows transaction virtual size and fee rate.
- Why many inputs can matter: spending more UTXOs generally adds transaction data.
- Who controls the fee: normally the party constructing and broadcasting that particular transaction.
- Why a displayed withdrawal charge can differ from the blockchain fee: the service may apply its own allocation policy, and one transaction may pay several recipients.
- What a TXID proves: that a specific transaction can be inspected for outputs, fee data, and confirmations.
- What zero confirmations means: the transaction may have been broadcast but is not yet recorded in a block.
- Where service processing ends and Bitcoin settlement begins: a missing TXID points to a pre-broadcast stage, while an unconfirmed TXID points to an on-chain transaction awaiting inclusion.
The decisive check is not the label attached to a charge. It is the complete path of funds: which transaction was created, who created it, what outputs it contains, what fee it pays on-chain, and what amount finally reaches the intended address.