Who gets the fee
A Bitcoin transaction fee is the difference between the coins a transaction spends and the coins it sends. That difference is claimed by the miner who includes the transaction in a block. The fee is a payment to the network for space in a block, nothing more. It does not go to the wallet developer, and SatKeep adds no fee of its own on top. The Bitcoin developer guide on transactions is the primary reference for the mechanics described here.
Because block space is limited, fees are also how transactions compete. When many people want to transact at once, the ones offering more per unit of space tend to be confirmed sooner.
A rate, not a flat price
Bitcoin fees are not a percentage of the amount sent and not a fixed price per payment. They are a rate: satoshis per virtual byte, written sat/vB. A satoshi is one hundred-millionth of a bitcoin; a virtual byte is the unit the network uses to measure how much block space a transaction occupies.
The total fee is the fee rate multiplied by the transaction’s virtual size:
- Formulatotal fee = fee rate (sat/vB) × virtual size (vB)
- ExampleA 140 vB transaction at 10 sat/vB pays 1,400 sats, which is 0.000014 BTC. The same transaction at 50 sat/vB pays 7,000 sats.
- ConsequenceSending a large amount can cost the same fee as sending a tiny one. Size, not value, is what you pay for.
What makes a transaction large
A transaction’s size comes from its structure, not the amount of bitcoin involved.
- Inputs. Each coin being spent is an input, and each input adds data, including a signature. A wallet that has received many small payments may need many inputs to assemble one payment, which makes the transaction bigger and the fee higher.
- Outputs. Each destination is an output. Most payments have two: the recipient and your own change address.
- Address type. Spending from native SegWit addresses, the kind that begin with
bc1q, takes less space than spending from older address types, so the same payment costs less.
You usually cannot see this detail when you pay, but it explains why two payments of the same amount can carry different fees.
The mempool and why fees move
Transactions waiting to be confirmed sit in each node’s mempool, a queue of unconfirmed transactions. Roughly every ten minutes a miner assembles a block from that queue, generally favouring the transactions paying the highest fee rate. If more transactions arrive than blocks can hold, the queue grows and the fee rate needed to be included soon rises. When demand falls, it drops again.
That is why the “right” fee is different on a quiet Sunday night than during a busy market day, and why a fee estimate is always a snapshot. Block timing is also random: ten minutes is an average, and individual blocks can arrive in one minute or in forty.
Choosing a fee
Fee estimators look at the current mempool and suggest rates likely to get a transaction confirmed within a target, such as the next block, within an hour, or within a day. Choosing well comes down to one question: how soon does this payment need to confirm?
- Paying a merchant who is waiting? Pay for a near-term target.
- Moving coins to your own storage? A lower rate and a longer wait usually cost far less.
- Not sure? Look at the estimate, consider what happens if it takes a few hours, and choose accordingly. Fees only go to the miner once, so there is no benefit in overpaying “to be safe” beyond the target you actually need.
Small habits reduce fees over time: let payments accumulate rather than making many tiny ones, and if you ever need to tidy up many small inputs, do it when the network is quiet.
When a fee is too low
A transaction with a fee rate below what miners are currently including will wait in mempools until the rate it offers becomes competitive. Sometimes that is an hour; in a sustained busy period it can be days. Transactions that wait very long may be dropped from some nodes’ mempools, but that is not a cancellation: the signed transaction still exists, another node or the recipient may hold it and rebroadcast it, and it can still confirm later. Before making another payment for the same purpose, check the transaction’s status on the network and treat the first payment as live until you are certain it is not.
The wider Bitcoin ecosystem has techniques for speeding up a stuck transaction, such as replacing it with a higher-fee version or having the recipient spend from it at a high fee. Support for them varies between wallets and services, and this guide makes no claim about any particular wallet’s support, so do not plan around them. The dependable approach is to look at the fee before you approve, and to send a small test payment when you are trying something new.
How this looks in SatKeep
SatKeep keeps the fee visible. When you send bitcoin, the review step shows the network fee alongside the full recipient address, the network and the amount, and nothing is signed until you approve it with your device. The fee is paid from your bitcoin balance in BTC.
Fee estimates in the app are informed by current network conditions, but like every estimate they are a snapshot. Confirmation times and fees vary and cannot be guaranteed by any wallet. If a payment is still unconfirmed after a long time, check it in a public block explorer, which the Activity tab links to, before deciding what to do next.
Ethereum and Solana, briefly
The other networks SatKeep supports charge fees too, each in its own coin.
- EthereumFees are paid in ETH and depend on how busy the network is. They apply to USDC and USDT transfers as well, so a wallet holding only stablecoins cannot send them until it also holds a little ETH. SatKeep shows a maximum fee before you approve.
- SolanaFees are paid in SOL and are typically small, but the first transfer of a token to a recipient may require creating a token account for them, which has its own cost. SatKeep shows that cost separately when it applies.