What a network fee actually is
A blockchain has finite room. Each block can hold only so many transactions, and far more people want their transaction included than there is space in the next block. The network resolves that competition with a fee: you attach a payment to your transaction, and the validators who assemble blocks prioritize the transactions that pay more. The fee is the price of a seat in the next block — nothing more exotic than that.
On Ethereum and EVM chains this fee is called gas, because every operation a transaction performs costs a measured amount of computational work, and you pay per unit of that work at a price the market sets. A plain transfer is cheap because it does little; a complex smart-contract interaction costs more because it does more. On Bitcoin the fee is priced by the size of the transaction in bytes rather than by computation, but the principle is identical — you are bidding for limited block space.
Crucially, that fee is paid to the network's validators or miners — the independent operators who secure the chain — as the incentive to keep processing transactions and producing blocks. It is not a fee any payment processor sets, collects, or profits from. It exists whether you move money through halfin, through another platform, or by hand from your own wallet. The chain charges it; everyone moving value on that chain pays it.
- Block space is scarce — the fee is what you pay to claim a seat in the next block.
- On EVM chains it is called gas and priced by computational work; on Bitcoin it is priced by transaction size.
- The fee goes to the chain's validators or miners as the incentive to secure and process the network.
- It is a property of the blockchain itself, not a charge added by halfin or any processor.
Why fees vary — by chain, and by the minute
The first reason fees differ is the chain. Different blockchains are built with different throughput, block sizes, and fee mechanics, so the baseline cost to move value is simply not the same across them. A transfer on Bitcoin and the same logical transfer on a high-throughput chain are priced by entirely different rules, which is why the cost can differ by orders of magnitude depending on which rail the funds travel.
The second reason is congestion, and it moves in real time. Fees rise when demand for block space spikes — a busy trading day, a popular token launch, a network-wide event everyone is reacting to at once — because more transactions are bidding for the same limited space. When the network is quiet, the same transaction costs less. This is why a fee estimate is a moving target: the cost to confirm a transaction now and the cost an hour from now can differ purely because the crowd thinned or thickened, with nothing about your transaction having changed.
The third reason is what the transaction does. A simple native transfer is the cheapest case. Moving a token (a stablecoin transfer, for instance) does more work than moving the chain's native coin and therefore costs more on the same chain. None of these three factors are levers halfin controls — they are determined by the chain you chose, the moment you transact, and the kind of transaction it is.
| What drives the fee | Direction it pushes the fee | Whose decision it is |
|---|---|---|
| Which chain | Some chains are structurally low-fee (e.g. Tron, Solana), others structurally higher (e.g. Bitcoin, Ethereum mainnet) — qualitatively, not by any fixed number. | The network you or your customer chose to transact on. |
| Network congestion | Higher when block space is in demand, lower when the network is quiet — and it changes minute to minute. | The whole market competing for the same blocks; nobody sets it centrally. |
| What the transaction does | A native transfer is cheapest; a token (e.g. stablecoin) transfer costs more; a contract interaction more again. | The kind of payment being made. |
Who pays the fee, in each direction
The confusion almost always comes from not knowing which side of a payment carries the fee. It depends entirely on who is broadcasting the transaction, because the fee is always paid by the party whose transaction is being included in a block. Walk the two directions separately and it stops being mysterious.
On the inbound side — a customer paying an invoice, or a deposit landing on one of your static addresses — the customer's wallet broadcasts the transaction, so the customer pays the network fee on top of the amount they send. This is why a deposit can arrive looking a fraction short of a round number, or why a customer who sends from an exchange receives slightly less than they expected: their sending wallet or exchange deducted the network fee to broadcast. That deduction happened on the customer's side, before the funds ever reached the chain's view of your address. It is not a haircut halfin took.
On the outbound side — a payout you send to a recipient — the transaction that moves the money is broadcast on your behalf, so the network fee is incurred to get that payout onto the chain. Again, this is the cost of block space for that specific transfer, on whichever network the payout uses, at the congestion level of that moment. A payout on a low-fee chain costs little to broadcast; the same value sent over a higher-fee chain costs more — the same value, a different rail, a different network fee.
- The fee is always paid by whoever broadcasts the transaction into a block.
- Inbound (invoice payment, deposit): the customer's wallet pays it, which is why a deposit can land a little short.
- Outbound (payout): a network fee is incurred to broadcast the transfer onto the chosen chain.
- In every case the fee goes to the chain's validators — it is never a halfin charge.
How this shows up in halfin
Because halfin moves real value on real chains, the network fee is unavoidably present — but it is the chain's fee, surfaced honestly, not a markup. Understanding where it appears keeps you from mis-reading your own ledger.
On invoices, the amount you bill is the amount you expect to settle. If a customer's wallet deducts a network fee from what they send, the on-chain amount that arrives can be lower than the invoice total — which is exactly the underpaid case halfin makes first-class. The invoice records the shortfall instead of silently swallowing it, so you can decide whether to request a top-up, settle partially, or treat it per your policy. The 'missing' amount was the customer's network fee, paid to the chain, not a deduction on halfin's side.
On payouts, broadcasting the transfer to the recipient incurs the network fee for that chain and that moment. Choosing the network the recipient can actually receive on is therefore also a fee decision: the same payout value over a low-fee chain like Tron or Solana costs less to broadcast than over a structurally higher-fee chain. The chain you pick for a payout is a lever you do hold — which asset and network to send — even though the fee on that chain, once chosen, is set by the network and not by halfin.
- A deposit or invoice payment can arrive short because the customer's wallet paid the network fee to send it — that surfaces as the underpaid state, not a hidden charge.
- Broadcasting a payout incurs the network fee for that chain at that moment.
- Selecting the asset and network is the fee lever you control; the per-chain fee itself is the network's, not halfin's.
- halfin surfaces on-chain reality (reorg-aware crediting, per-chain confirmations) rather than hiding fee effects in rounding.
The single curl that makes the point
Nothing about a network fee shows up in the request you send to halfin — and that is the clearest way to internalize that the fee is not a halfin charge. A payout request names the currency, the amount, and the destination; you do not pass a fee field, because the fee is not yours to set. It is incurred on-chain when the transfer is broadcast, on whichever network the currency names.
The amount you state is what the recipient is owed. The network fee to deliver it is a separate, on-chain reality determined by the chain you chose — here Tron, via USDT_TRC20, a structurally low-fee rail — and the congestion at broadcast time. Switch the currency to a higher-fee chain and the value owed is identical while the cost to broadcast it is not.
# A payout names what the recipient is owed — there is no fee field,
# because the network fee is the chain's, not a halfin charge.
curl -sS -X POST https://api.thehalfin.com/api/v1/payouts \
-H "Content-Type: application/json" \
-H "X-API-Key: $HALFIN_API_KEY" \
-d '{
"currency": "USDT_TRC20",
"amount": "50.00",
"destination": "TXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"idempotency_key": "payout-2026-06:acct_4821"
}'
# The same value over a structurally higher-fee chain costs more to broadcast.
# The amount owed does not change; the network fee to deliver it does.
# Per-chain confirmation and fee behavior live at docs.thehalfin.com.Practical takeaways
Three habits keep network fees from looking like a problem. First, expect inbound payments to sometimes arrive a touch short, and read that as the customer's network fee rather than a deduction on your side — the underpaid state is the platform telling you exactly that, not hiding anything. Second, treat the choice of asset and network as a real decision: it is the one part of the fee equation you control, and a low-fee chain meaningfully changes the cost of moving the same value. Third, stop comparing a live fee estimate to one you saw an hour ago — congestion moved, and that is the whole explanation.
Above all, separate the network fee from anything you might pay a processor. The network fee is the chain's, paid to validators, qualitatively different by chain and by the minute. It is the cost of using a public, permissionless ledger — the same cost you would pay sending the funds yourself from a wallet. Knowing that turns a confusing line item into a predictable characteristic of the rail you chose.