The Protocol is incompatible with tokens that have a fee-on-transfer mechanism. Such tokens for example are PAXG (officially supported as per documentation), while USDT has a built-in fee-on-transfer mechanism that is currently switched off.
One example of such code is in distributeAssets()
while using safeTransferFrom()
(L232). This will work incorrectly if the token has a fee-on-transfer mechanism due to following sequence of events -
The rewards
will be calculated based on the variable _portion
on L227.
However, the amount which is added to the contract via safeTransferFrom
will only be _portion - fee
on L232.
Since now the funds in the contract are less than the sum of all rewards (less than the sum of all _portions
), the first few users calling claimRewards may receive their full reward, but eventually subsequent users' call will start reverting due to insufficient funds.
Also an additional note: When L175 makes the transfer of reward to the user, the user will actually only receive _rewardAmount - fee
, but I think that can be signed off to as an acceptable effect/risk of using fee-on-transfer tokens.
Users unable to claim their reward
Impact: High, as some users will lose value
Likelihood: High, as such tokens (example: PAXG) are officially supported currently as per documentation
Manual inspection
Cache the balance before a transferFrom / transfer
to the contract and then check it after the transfer and use the difference between them as the newly added balance.
In our context, it basically means that the _portion
variable needs to be decreased by the token-transfer-fee before adding it to the rewards[]
variable.
Also best to implement a nonReentrant
modifier, as otherwise ERC777
tokens may manipulate this.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.