We should add a parameter to transfer in the Balances module so that the sender can prefer to have the transaction fail rather than have the account reaped.
Currently, extrinsics pay an inclusion_fee = base_fee + byte_fee + weight_fee. This is charged prior to execution of the extrinsic and doesn't know anything about the internal logic of the extrinsic.
The inclusion fee is updated for block N+1 based on the weight of block N compared to the target weight according to TargetedFeeAdjustment so you can calculate the inclusion fee for the next block. However, it is possible that a transaction is in the pool for several blocks before inclusion. The sender may intend to leave enough balance to keep the account but have it reaped.
Users
This is a problem for exchanges who manage thousands of accounts. Not having this feature makes them leave a large margin of safety on ED to prevent nonce reset. This is undesirable because it represents a lot of wasted capital.
Example
As a concrete example, imagine the following scenario:
balance = 10
ED = 1
current_inclusion_fee = 1
next_block_inclusion_fee = 1.5
The user attempts to transfer 7 tokens, but the extrinsic is in the pool for several blocks and the inclusion_fee increases to 2.1. Substrate then:
- Takes the inclusion fee
- Executes the extrinsic, leaving
balance = 0.9 and reaping the account
The user should be able to add an optional parameter to transfer to avoid executing the transaction if it would lead to the account getting reaped.
We should add a parameter to
transferin the Balances module so that the sender can prefer to have the transaction fail rather than have the account reaped.Currently, extrinsics pay an
inclusion_fee = base_fee + byte_fee + weight_fee. This is charged prior to execution of the extrinsic and doesn't know anything about the internal logic of the extrinsic.The inclusion fee is updated for block
N+1based on the weight of blockNcompared to the target weight according to TargetedFeeAdjustment so you can calculate the inclusion fee for the next block. However, it is possible that a transaction is in the pool for several blocks before inclusion. The sender may intend to leave enough balance to keep the account but have it reaped.Users
This is a problem for exchanges who manage thousands of accounts. Not having this feature makes them leave a large margin of safety on ED to prevent nonce reset. This is undesirable because it represents a lot of wasted capital.
Example
As a concrete example, imagine the following scenario:
The user attempts to transfer 7 tokens, but the extrinsic is in the pool for several blocks and the
inclusion_feeincreases to 2.1. Substrate then:balance = 0.9and reaping the accountThe user should be able to add an optional parameter to
transferto avoid executing the transaction if it would lead to the account getting reaped.