
A cryptocurrency swap can involve two different cost layers: a network fee for recording a transaction on a blockchain and an exchange fee for processing the conversion. They may appear together in one quote, occur at different stages, or be paid in different assets. Understanding which party initiates each transaction makes the final amount easier to check.
Main takeaways
- A network fee goes to the participants responsible for processing blockchain transactions, not automatically to the exchange service.
- An exchange fee covers the conversion service and may be shown as a separate charge or reflected in the quoted input and output amounts.
- BTC fees are influenced by transaction data size and competition for block space, rather than simply being a fixed percentage of the amount transferred.
- Ethereum fees depend on gas consumption and the price of gas. A token transfer can require a different amount of gas from a simple ETH transfer.
- USDT exists on multiple blockchains, so “the USDT fee” has no single universal meaning. The selected network determines the transaction mechanism and fee conditions.
- The useful comparison is the amount delivered to the destination wallet, provided the quotes use the same assets, network and settlement assumptions.
The minimum vocabulary you need
Network fee
A network fee pays for submitting and processing an on-chain transaction. On Bitcoin, wallets construct transactions from unspent transaction outputs, or UTXOs. The fee is the difference between the selected inputs and the outputs, including any change returned to the sender. Transaction selection is influenced by the fee rate relative to the transaction’s data size and current demand for block space. [1]
On Ethereum, computation and storage operations are measured in gas. The actual fee is based on the gas used and the effective price per gas; gas is paid in ETH. More complex smart-contract interactions can consume more gas than a basic ETH transfer. A fee can also be consumed by a transaction that is included but fails during execution, because the network still performed computational work. [2]
Exchange fee
An exchange fee is the service’s charge for converting one asset into another. Depending on the quoting model, it can be displayed explicitly, included in the offered rate, or combined with other disclosed costs. The label alone is not enough to compare two offers: the decisive figure is the expected amount credited to the destination, under equivalent conditions.
Quoted rate and final output
The quoted rate links the input asset to the estimated or fixed output, depending on the service’s order terms. If a quote is floating, market movement while the deposit is being confirmed may change the conversion result. If it is fixed, the terms may specify a validity period, required deposit amount or other conditions. None of these details should be assumed; they must be checked before creating an order.
Deposit and payout transactions
A swap often has at least two operational legs. First, the user sends the input asset to a deposit address. Later, the service sends the output asset to the destination address. These are separate blockchain transactions and may use different fee mechanisms. An internal conversion does not itself prove that both legs occurred on the same blockchain—or that they occurred at the same time.
Mechanism map: from user action to a verifiable result
| User action | Service or wallet mechanism | Blockchain mechanism | Observable result | How to verify it |
|---|---|---|---|---|
| Selects BTC, ETH or USDT as the input and chooses an available output route | The interface prepares a quote and shows the deposit requirements | No transaction has occurred yet | Expected input, output, fee treatment and destination details are displayed | Read the order terms and confirm whether the quote is fixed or floating |
| Chooses a network where a network choice is offered | The service generates or displays a deposit address compatible with that route | The selected blockchain defines address rules, fee mechanics and transaction tracking | A network-specific address and deposit instruction appear | Compare the network labels in the sending wallet and the order before sending |
| Sends the input asset | The wallet selects funds, estimates a fee and broadcasts the transaction | Nodes validate the transaction; miners or validators may include it in a block | A transaction identifier appears and confirmations begin to accumulate | Search for the transaction identifier in an explorer for the selected blockchain |
| Waits for the deposit to satisfy the order conditions | The service monitors the deposit address and applies its confirmation and compliance rules | Additional blocks build on the block containing the deposit | The order may move from waiting to received or processing | Compare the explorer status with the status shown on the order page |
| Receives the converted asset | The service creates or arranges the payout according to the accepted order | A new transaction is broadcast on the output asset’s selected network | The destination wallet detects the payout and later shows confirmations | Check the payout transaction identifier, recipient address, asset and network in the appropriate explorer |
The map explains why a single “fee” figure can be misleading. The sending wallet may charge the user a network fee for the deposit, while the service may fund the payout transaction and account for its cost in the quote or disclosed fee structure. A receiving wallet may show only the amount delivered, not every cost involved earlier in the route.
How the three assets differ
BTC: transaction structure matters
A Bitcoin transaction can combine several UTXOs as inputs and create a recipient output plus a change output. More inputs and certain output types can increase the transaction’s virtual size, which can increase the total fee at the same fee rate. Sending more BTC does not necessarily cost more than sending less BTC; the structure of the transaction and competition for block space are more relevant. [1]
The fee shown by the sending wallet belongs to the BTC deposit transaction. It should not automatically be treated as the exchange’s commission. The transaction identifier lets the user inspect the inputs, outputs, fee and confirmation status independently.
ETH: gas used multiplied by gas price
Ethereum separates the amount of computational work from the price paid per unit of work. Under its fee model, a transaction includes a protocol-determined base fee and may include a priority fee. Wallets usually estimate appropriate parameters, but network demand can change between estimation and inclusion. [2]
A direct ETH transfer and an interaction with a token contract are not mechanically identical. This matters when comparing an ETH deposit with a USDT transfer on Ethereum: the latter is a token operation executed by a smart contract, and its gas use should not be assumed to match a basic ETH payment.
USDT: the blockchain must be identified
USDT uses the transaction system of the blockchain on which that particular token is issued. Consequently, a USDT address, fee mechanism and transaction identifier must be interpreted in the context of the selected network. [3]
The sender must use a network accepted for that exact deposit route. A matching ticker is not enough: USDT sent through one blockchain is not automatically credited to an address or order expecting another. Network availability can differ by service, asset and direction, so it must be confirmed for the current order rather than inferred from an earlier transaction.
A realistic BTC-to-USDT scenario
Suppose a user wants to convert BTC into USDT. The user first checks that the BTC-to-USDT direction is currently available and identifies which USDT payout networks can actually be selected. No specific network should be assumed merely because the service supports both assets.
- The order displays a required BTC deposit and an expected USDT output under stated quote conditions.
- The user copies the BTC deposit address and sends BTC from a personal wallet. That wallet constructs the Bitcoin transaction and charges a BTC network fee.
- The BTC transaction is broadcast. Its status, fee and confirmations can be inspected through its transaction identifier.
- After the deposit satisfies the order’s confirmation and applicable compliance conditions, the service processes the conversion.
- The service sends USDT on the network chosen in the order. This payout has its own blockchain record and fee mechanism.
- The user verifies that the payout transaction uses the expected network, reaches the specified address and credits the output amount shown under the accepted order terms.
This scenario contains two on-chain legs but only one conversion. The BTC network fee, the service’s exchange fee and the cost of the USDT payout are conceptually separate even if the interface combines some of them into the final quote.
When the model changes—and what it cannot prove
The two-leg model fits a typical wallet-to-service-to-wallet exchange, but the exact implementation may differ. A service can aggregate withdrawals, use internal accounting before payout, delay broadcasting until operational checks are complete, or apply route-specific pricing. An explorer reveals what happened on-chain; it does not reveal every internal pricing or risk-control decision.
The final result can change with network congestion, selected fee settings, transaction size, smart-contract gas use, quote type, confirmation requirements and market movement. Verification conditions may also depend on the exchange direction and the outcome of compliance checks. Current requirements should be reviewed before an order is created.
A low visible network fee does not prove that an exchange offer is inexpensive overall. Conversely, a noticeable network fee does not establish that the service charged a large commission. Only a like-for-like comparison of input required, output delivered, network, quote rules and separately disclosed charges can support that conclusion.
Failure points and their visible signs
| Failure point | What the user may observe | What to check |
|---|---|---|
| Wrong USDT network selected | The expected deposit does not appear even though a transaction exists elsewhere | Compare the order’s network with the sending wallet’s network and the explorer used for the transaction |
| Incorrect or altered address | The explorer shows funds sent to an address different from the order or intended wallet | Compare the full address with the original instruction; blockchain transfers are generally not reversible by cancelling a completed transaction |
| BTC fee rate too low for current demand | The transaction remains unconfirmed while later transactions may be included | Inspect its fee rate and mempool status rather than relying only on the wallet’s “sent” label |
| Ethereum transaction pending or failed | The wallet shows a pending state, or the explorer records a failed execution and a gas charge | Review the transaction status, gas parameters, recipient and contract interaction details |
| Quote conditions not met | The output differs from an earlier estimate or the order requires manual review | Check quote type, validity conditions, actual deposit amount and the time the deposit was detected |
| Phishing or substituted instructions | The domain, deposit address or support contact differs from the expected service interface | Stop before sending, reopen the service independently and verify every address on the confirmation screen |
Rules for cryptocurrency services, disclosures and customer checks also vary between countries. An on-chain transaction being technically valid does not by itself establish that a transaction complies with local legal, tax or reporting requirements.
How to compare a quote before sending
Record the input amount requested, the expected output, the selected network, the quote type and every separately displayed charge. Then check which network fees are paid outside the order by your own wallet. If two services use different payout networks or quote rules, their headline rates are not directly comparable.
For a current operation, check the available BTC, ETH and USDT exchange routes and their fee terms before creating the order. Pair and network availability should be confirmed at that moment rather than assumed from the list of supported assets.
Understanding check
After reviewing an order, you should now be able to:
- identify whether a charge belongs to the sending blockchain, the payout transaction or the conversion service;
- explain why a BTC fee depends on transaction structure and fee rate rather than only on the transferred amount;
- distinguish Ethereum gas consumption from the price paid per unit of gas;
- name the specific blockchain when discussing a USDT transfer;
- trace the deposit and payout as separate transactions using their identifiers;
- verify the asset, network, recipient address, transaction status and delivered amount;
- recognize that an explorer confirms on-chain activity but cannot disclose an exchange’s complete internal fee calculation;
- pause the transfer when the order, wallet and network labels do not match.