Deferred Fee Allocation
by Tester1 Tester1 on 08 March 2022
Expiry date
Applies to
Standard Stage
In Consideration Draft Internal Review Public Review Published Recommended
Thanks for submiting your comments!

TS 2022.010-10

Deferred Fee Allocation

Proposer Jack Davies, Jad Wahab
TSC SponsorLin Zheming
Authors Jack Davies, Jad Wahab
ReviewersAaron Zhou, Jiehui Chen, Meysam Rezaei


The purpose of this specification/system is to defer the allocation of the (miner/node) fee paid for a Bitcoin transaction. Typically with Bitcoin, the sender/customer of a Bitcoin transaction is the one who pays the transaction fee, as opposed to the receiver/merchant. This poses some issues especially in terms of UX (user experience) and accounting, further detailed below. Using this specification/system, allows the receiver to pay the fee instead of the sender. This specification fits in very nicely with the Payment Protocol/Invoice-Based Payments Specification as an extension that does not change the payment flow but enhances it. In the rest of our payment systems, people are more used to having the merchant/receiver pay the transaction fee, even if they price the transaction fee into the cost of the good or service (so they would charge you $2.30 instead of $2.00 to cover for the transaction fee paid to a credit card processor such as VISA for example). With Bitcoin wallets, it’s not the best UX for the receiver to expect to be paying a specific amount and then when they make the payment realise that a bit more has been paid. It isn’t great to show the sender/receiver the transaction fee even though many in the industry are used to it by now. More importantly, is the responsibility of the receiver to get the transaction settled on the blockchain – not the sender who would be happy to receive the goods or services without having to pay for it. Not to mention, this makes accounting a lot easier and more straight forward.

Value proposition

The value proposition for this specification/system is to be able to delegate the responsibility of paying the transaction fee away from the sender. This brings the Bitcoin transaction functionality much closer to functionality people are naturally more used to, such as with credit card payments, where the receiver/merchant pays the fee for the transaction. Another value proposition is allowing miners to charge fixed fiat rates to their customers (as opposed to paying variable Bitcoin fees that change based on the price of Bitcoin with respect to fiat). A miner could charge a rate of $0.01/Byte for example instead of 1Satoshi/Byte to their customers. The miner would then fund the transactions themselves in order to avoid trying to mine a block with 0-fee transactions and risk that block getting orphaned by the rest of the network. This allows companies who submit many transactions to the Bitcoin network to have much more predictable accounting and financial forecasting/planning.



Prior art


Proposed solution

To be developed by the working group.

Comments are closed

This Standard is at the draft stage and comments are closed.

Suggest new tags for this standard
Become a Contributor
If you wish to join us on this mission to make BSV the public blockchain of choice please fill in our preliminary registration form below. We look forward to having you on board.