ferencdg
commented
2 years ago 'can cause issues for downstream applications who may send more tokens than is necessary if a fee is changed by the owner'
if userA sends 100 to userB, then userB will always receive 100, regardless of the owner changed the fee or not. I think what you mean is that the cost for the downstream system is 100 + fee, and because the fee can change, the downstream system cannot be sure how much the total cost was.
your first suggested solution is: fee + transfer value <= limit wouldn't really solve the problem, if the owner decided to decrease the fee: the downstream system would still not know how much the fee was
your second suggested solution is to have the amount transferred to be inclusive of fee. Unfortunately that also cannot work. If userA wants to transfer 100 to userB, and fee is inclusive, then userA would need to transfer 102 to userB. However as you said fee can change and userA wants to transfer the exact 100 amount.
solution 1 let the transfer method return the fee deducted (and keep the fee as exclusive).
solution 2 change method signatures like transfer(from,to,amount,expectedFee), and the method should fail if the currentFee is not the expectedFee
The caller of the transfer method can't reliably predict the fee amount that will be charged when transferring out. After a query call has been made to retrieve the fee value and before the actual transfer call, it's possible the fee could be changed by the owner. This may be a rare occurrence but can cause issues for downstream applications who may send more tokens than is necessary if a fee is changed by the owner.
Two possible fixes include making the transfer method have a limit parameter to ensure that fee + transfer value <= limit, or changing the transfer function so that the amount transferred is inclusive rather than exclusive of the fee.