The feesetter can set or change satoshiPerByte, which is used as the unit of fee in the protocol. During withdrawal or deposit, the fee is calculated using satoshiPerByte. If transactions are instant, changing the fee per byte won't create any issue. However, if transactions aren't instant (e.g., a withdrawal goes into a queue), the fee per byte can be changed between the initiation and finalization of a withdrawal.
The withdrawal deducts BYTES_PER_OUTGOING_TRANSFER * satoshiPerByte as network fee based on the current chain conditions and then checks for amountAfterNetworkFee >= minWithdrawalLimit, which is incorrect since the transaction is not instant. It goes to the OutgoingQueue and is executed later at a possibly different satoshiPerByte, which then breaks the initial checks like minWithdrawalLimit and fee calculations.
We can see in startOutgoingTxSerializing it fetches the OutgoingQueue and updates the fee based on the current satoshiPerByte. Since a batch of transactions is executed together, it creates issues
Since a batch of tx executed together it creates issues
if updated satoshiPerByte is less than previous satoshiPerByte, User paid high inflated fees and left amount is not refunded to user.
If the updated satoshiPerByte is greater than the previous satoshiPerByte, it will inflate the fee, and the withdrawal which is now executed will cause
```
uint64 amountAfterNetworkFee = amount - (BYTES_PER_OUTGOING_TRANSFER * satoshiPerByte);
require(amountAfterNetworkFee >= minWithdrawalLimit, "AFL");
```
updated `satoshiPerByte` can cause `amountAfterNetworkFee < minWithdrawalLimit` but txn will be executed which should revert due to transfer amount is less than withdrawal limit
The protocol will have to pay more network fees than taken from the user, since network fees is more now.
This is based on an attack vector in a staking protocol which charges fees based on some rate and doesn't cut fees before changing the rate. Hence, if the rate becomes higher, it will take more fees than actual fees, and if the rate goes lower, it will take less fees than actual fees.
Therefore, before changing the satoshiPerByte, process all the pending OutgoingQueue transactions
Github username: -- Twitter username: -- Submission hash (on-chain): 0xf924ff991cdedc9443e2abcf3998f5ef516d029e0702448862bca5ed8f2695c5 Severity: medium
Description: Description
The
feesetter
can set or changesatoshiPerByte
, which is used as the unit of fee in the protocol. During withdrawal or deposit, the fee is calculated usingsatoshiPerByte
. If transactions are instant, changing the fee per byte won't create any issue. However, if transactions aren't instant (e.g., a withdrawal goes into a queue), the fee per byte can be changed between the initiation and finalization of a withdrawal.Proof of Concept (PoC) File
The withdrawal deducts
BYTES_PER_OUTGOING_TRANSFER * satoshiPerByte
as network fee based on the current chain conditions and then checks foramountAfterNetworkFee >= minWithdrawalLimit
, which is incorrect since the transaction is not instant. It goes to the OutgoingQueue and is executed later at a possibly differentsatoshiPerByte
, which then breaks the initial checks like minWithdrawalLimit and fee calculations.We can see in
startOutgoingTxSerializing
it fetches theOutgoingQueue
and updates the fee based on the currentsatoshiPerByte
. Since a batch of transactions is executed together, it creates issuesSince a batch of tx executed together it creates issues
if updated
satoshiPerByte
is less than previoussatoshiPerByte
, User paid high inflated fees and left amount is not refunded to user.If the updated satoshiPerByte is greater than the previous satoshiPerByte, it will inflate the fee, and the withdrawal which is now executed will cause
The protocol will have to pay more network fees than taken from the user, since network fees is more now.
This is based on an attack vector in a staking protocol which charges fees based on some rate and doesn't cut fees before changing the rate. Hence, if the rate becomes higher, it will take more fees than actual fees, and if the rate goes lower, it will take less fees than actual fees.
Therefore, before changing the
satoshiPerByte
, process all the pending OutgoingQueue transactions