Contracts are vulnerable to fee-on-transfer accounting-related issues

[hats-bug-reporter[bot]]

Github username: -- Twitter username: -- Submission hash (on-chain): 0x8bb4ee95f8c8984ad0239f6d01dd2493040277662ee36f99250ddf5e103383e3 Severity: medium

Description: Description\ There are ERC20 tokens that charge fee for every transfer() or transferFrom(), E.g Vader token.

The current implementation assumes that the received amount is the same as the transfer amount.

Consistently check account balance before and after transfers for Fee-On-Transfer discrepancies. As arbitrary ERC20 tokens can be used, the amount here should be calculated every time to take into consideration a possible fee-on-transfer or deflation. Also, it's a good practice for the future of the solution.

Use the balance before and after the transfer to calculate the received amount instead of assuming that it would be equal to the amount passed as a parameter.

Attack Scenario\ call sendRequest with any fee on transfer token and it will not adhere to protocol description/ working.

File: contracts/Most.sol

148:         token.safeTransferFrom(msg.sender, address(this), amount);

Attachments

1. Proof of Concept (PoC) File

Files:

• PoC - fee on tfr.sol (https://hats-backend-prod.herokuapp.com/v1/files/QmRpQGu2vZzGkHoSEQgWMQ96DmQSVXNKjVW1pEqLbbCHbT)

[krzysztofziobro]

The protocol is not intended to support any tokens with non-standard indirect balance changes. Whitelisting such a token would be considered an owner error.