Potential PirexReward's producerTokens's rewardToken unsynced with PirexGmx rewardToken can miss calculate the actual reward for user

Lines of code Vulnerability details Impact Potential PirexReward's producerTokens's rewardToken unsynced with PirexGmx rewardToken can miss calculate the actual reward for user Proof of Concept PirexReward initialization does not include rewardToken initialization for producerTokens. Meanwhile...

recoverERC20() in StakingRewards shouldn't allow transfer of rewardToken because it belongs to users who stacked their funds and owner shouldn't be able to immediately withdraw those users funds

Lines of code Vulnerability details Impact rewardToken balance in StakingRewards contract is belongs to staking users and owner shouldn't be able to withdraw all balance of rewardToken immediately, because this can cause users to lose their funds if owner perform this action by intention or by...

BkdLocker#depositFees() can be front run to steal the newly added rewardToken

Lines of code Vulnerability details Every time the BkdLockerdepositFees gets called, there will be a surge of rewards per locked token for the existing stakeholders. This enables a well-known attack vector, in which the attacker will take a large portion of the shares before the surge, then claim...

Unable to updateReward if there are too many rewardTokens

Lines of code Vulnerability details Impact If there are too many rewardTokens, updateReward might run exceed block gas limit and freeze fund since stake and withdraw have the updateReward modifier. Proof of Concept function addReward address rewardToken, address veAssetDeposits, address...

setFlywheelRewards can take any rewardToken

Lines of code Vulnerability details Impact Though setFlywheelRewards has requiresAuth, it still has rug risk that a privileged user can move all rewardToken of flywheelRewards to new malicious newFlywheelRewards unconditionally. Proof of Concept A malicious user or a compromised admin can call...

check for deposit token and reward token are not same

Handle hack3r-0m Vulnerability details Impact createStream does not check if deposit token and reward token are different addresses. Proof of Concept Not Required Tools Used Manual Review Recommended Mitigation Steps add check requirerewardToken != depositToken --- The text was updated...

Broken logic if rewardToken == depositToken

Handle gzeon Vulnerability details Impact There doesn't seems to be anything to prevent one the deploy a Stream with rewardToken == depositToken. If rewardToken == depositToken, some logic might be broken. Proof of Concept For example, 1. recoverTokens logic would be broken because it does not...

depositToken != rewardToken

Handle pauliax Vulnerability details Impact function createStream should validate that depositToken != rewardToken, otherwise, some functionality may not work as intended, e.g. in function recoverTokens it will become impossible to reach the second 'if' statement. Recommended Mitigation Steps...

Locke.sol:Stream - arbitraryCall can be used to drain incentive tokens

Handle ScopeLift Vulnerability details Impact Governor can drain incentive balance via arbitraryCall Proof of Concept The Stream contract offers createIncentive and claimIncentive which is the way the contract "expects" incentives to go. Access to claiming incentives is limited to the stream...