How BSV Transaction Fees Are Calculated: Total Inputs Minus Total Outputs

In a BSV transaction, the transaction fee is not a separate field written into the transaction. It comes from a simple but important rule:

In other words, the total value of all inputs minus the total value of all outputs is the fee. Miners receive this difference as the transaction processing fee.

This rule looks simple, but it is essential when manually building transactions, managing UTXOs, estimating fees, and debugging failed transactions. In particular, if you forget to create a change output, funds that should have returned to you may become part of the fee.

The Short Version: Fees Come From the Input–Output Difference

BSV uses the UTXO model. A transaction consumes existing outputs as inputs and creates new outputs.

In this model, there is no dedicated field that says:

Instead, the fee is implied by the value difference:

As long as the total input value is greater than the total output value, the amount not assigned to any output is treated as the fee available to miners.

How the Fee Is Calculated

Suppose a transaction has two inputs:

• input 1: 1000 satoshis
• input 2: 500 satoshis

The total input value is:

The transaction creates two outputs:

• output 0: 600 satoshis to the recipient
• output 1: 895 satoshis as change

The total output value is:

The fee is therefore:

The transaction itself does not store an additional “fee field.” Miners and nodes can calculate how much fee the transaction pays directly from the input and output values.

Why This Design Is Used

In the UTXO model, an input spends an existing UTXO, while an output creates a new UTXO.

If a transaction spends 1500 satoshis of old outputs but only creates 1495 satoshis of new outputs, the missing 5 satoshis are not assigned to any recipient. The protocol treats that difference as the transaction fee.

This design has several properties:

• No extra fee field is required.
• The fee is directly tied to the transaction structure.
• Anyone can verify the fee from the input and output values.
• Fee calculation naturally fits with UTXO spending and change creation.

Therefore, when you manually construct a transaction, you must be clear about the value of every input, the value of every output, and how much difference is intentionally left as the fee.

What Happens If You Forget the Change Output

Forgetting change is one of the most common and serious mistakes when manually constructing transactions.

Suppose you have a UTXO worth 100000 satoshis and want to pay someone 1000 satoshis.

If you create only one output:

The transaction fee becomes:

The remaining 99000 satoshis will not automatically return to your wallet. It becomes the transaction fee.

You may have intended to pay only 2 satoshis as the fee, but because no change output was created, the entire unallocated balance is treated by the protocol as the fee.

Wallets usually handle change automatically, including selecting inputs, creating the recipient output, creating the change output, and estimating the fee. But if you construct transactions manually in code, you must explicitly create a change output and make sure the total output value matches the intended fee.

The Relationship Between Fees and Transaction Size

Fees are usually related to transaction size. Larger transactions may require higher fees.

Factors that affect transaction size include:

• Number of inputs
• Number of outputs
• Script length
• Size of OP_RETURN data
• Number of signatures
• Whether additional proofs or contextual data are included

As a result, a small payment amount does not necessarily mean a small transaction.

For example, a transaction that transfers only a small amount can still be large if it contains many inputs or carries a large OP_RETURN payload. Miners and transaction processing services typically decide whether to accept a transaction based on fee rate, transaction size, and their own policies.

For large transactions, see the BSV TypeScript SDK Large Transactions guide:

https://bsv-blockchain.github.io/ts-sdk/guides/large-transactions/

Low Fees on BSV Do Not Mean Zero Fees

BSV emphasizes low fees, with the goal of supporting micropayments and high-frequency data transactions. But low fees do not mean zero fees, nor do they mean that unlimited spam data can be submitted.

Developers still need to consider:

• Minimum acceptable fees
• Dust outputs
• Transaction size
• Miner policy
• Service provider API limits
• Total cost for high-volume transactions

Low fees are one of BSV’s important advantages, but they need to be supported by proper fee estimation and UTXO management. For production applications, fees are not a detail that can be ignored. They are part of transaction construction, broadcasting, and operating cost.

Fees and Miner Incentives

Miners need economic incentives to process transactions and include them in blocks.

In Bitcoin/BSV, miner revenue mainly comes from two sources:

• Block subsidy
• Transaction fees

As the block subsidy declines over the long term, transaction fees become increasingly important.

BSV’s economic model emphasizes low fees at high volume: the fee for a single transaction can be very low, but if transaction volume is high enough, total fees can still support the revenue of transaction processors.

So low transaction fees do not remove incentives. Instead, the economic model is based on higher transaction volume and lower per-transaction cost.

How SDKs and Wallets Handle Fees

When using @bsv/sdk or wallet interfaces, many fee details are usually handled automatically.

Wallets or SDK-related tools typically perform the following tasks:

• Select inputs
• Create recipient outputs
• Create a change output
• Estimate the fee
• Sign the transaction

However, automatic handling does not mean developers can ignore how fees work. Production applications may still encounter issues such as:

• Failed fee estimation
• Transactions that are too large
• Sufficient balance but unsuitable UTXOs
• Service responses indicating insufficient fees
• Duplicate transactions caused by retries

Understanding that “fee = total inputs - total outputs” helps developers debug these issues. For example, when a service reports insufficient fees, you can check the transaction size, input and output values, change settings, and whether the fee rate meets the policy of the miner or service provider.

For ARC-related implementation details, see:

https://github.com/bitcoin-sv/arc

Common Misunderstandings for Beginners

The following misunderstandings are common when constructing and debugging transactions:

• The fee is not an independent output in the transaction.
• The fee equals total inputs minus total outputs.
• If you forget the change output, all remaining value becomes the fee.
• Low fees do not mean zero fees.
• A small payment amount does not mean the transaction is small.
• Transactions with many inputs may require higher fees.
• Automatic fee estimation by a wallet does not mean errors can never happen.

Practical Recommendations

If you are manually constructing BSV transactions, always check the following:

1. Confirm the value of every input.

2. Confirm the value of every recipient output.

3. Explicitly create a change output.

4. Calculate the actual fee with the formula:

   TEXT

   1fee = sum(inputs) - sum(outputs)

5. Check whether the transaction size is as expected.

6. Confirm that the fee meets the policy of the miner or transaction processing service.

7. Estimate the total cost for high-volume transactions.

Once you understand this core rule, fee-related issues in BSV transactions become much clearer: the money is not “deducted separately.” The part that is not reassigned from inputs to outputs becomes the transaction fee.

References

• Transaction Inputs and Outputs
• Large Transactions guide
• ARC GitHub