search

code-423n4 / 2022-04-xtribe-findings

2 stars 0 forks source link

QA Report #88

Closed code423n4 closed 2 years ago

code423n4 commented 2 years ago
  1. another check implementation of getPastVotes()

https://github.com/fei-protocol/flywheel-v2/blob/77bfadf388db25cf5917d39cd9c0ad920f404aad/src/token/ERC20MultiVotes.sol#L71

Since it was ERC20MultiVotes.sol from flywheel-V2 inspired by OpenZeppelin Contracts v.4.4.1 it was updated into v.4.5.0, in this line code it can be used implementation below for using for changing if blockNumber >= block,number for check if Block not mined yet, it has the same output.

POC

https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC20Votes.sol#L77

Recommended Mitigation

        require(blockNumber < block.number, "ERC20Votes: block not yet mined");
  1. Missbehavior of xTribe.sol

Since xTribe was xTribe is an ERC-4626 compliant TRIBE token. it should be implementors intend to support EOA account access directly, they should consider adding an additional function call for deposit/mint/withdraw/redeem with the means to accommodate slippage loss or unexpected deposit/withdrawal limits, since they have no other means to revert the transaction if the exact output amount is not achieved.

POC

https://eips.ethereum.org/EIPS/eip-4626

Recommended Mitigation

It should be checked wheter function call not lossing anything or revert the transact since no deposit/mint/withdraw/reedem in the contract.

Joeysantoro commented 2 years ago

neither issue makes sense. ERC4626 doesn't require slippage protection and the router could be used instead

0xean commented 2 years ago

closing as invalid.