AUDIT SUMMARY

VeneraSwap is building a new decentralized automated liquidity protocol trading platform that is used to exchange tokens, with additional contracts offering the ability to stake for rewards.

For this audit, we reviewed the following contracts on the Binance Smart Chain Mainnet:

AUDIT FINDINGS

Please ensure trust in the team prior to investing as they have substantial control in the ecosystem.
Date: January 28th, 2022.
Updated: April 27th, 2022 to reflect new mainnet addresses.

Finding #1 - VSWMaker - Low

Description: The swapping done within the contract is open to potential frontrunning.
Risk/Impact: A frontrunner could order transactions causing a change in price presenting an arbitrage opportunity. This is unlikely on BSC.
Recommendation: Implement a Time Weighted Average Price Oracle (TWAP) or use Chainlink for pricing to mitigate the potential price manipulations that allow frontrunning.

Finding #2 - Masterchef - Low (Resolved)

Description: The Masterchef deposit() function does not properly follow the check-effects design pattern.
Risk/Impact: The deposit() function is open to potential reentrancy issues from tokens with fallback functions.
Recommendation: Restructure the logic of the deposit() function to call all token transfers at the end of the function or ensure to not utilize ERC-777 or other tokens will fallback functions.
Resolved: The team has restructred the logic to avoid reentrancy.

Finding #3 - Masterchef - Informational

Description: If a pool's reward token is updated before all tokens have been distributed and no other pools are using that token as rewards, any remaining tokens are stuck in the contract.
Risk/Impact: The effective circulating supply of the token will be lowered, and the team will take a loss of the value of the tokens.
Recommendation: Exercise caution to ensure that tokens are properly distributed before updating the rewards tokens to prevent tokens being locked.

Finding #4 - GaugeProxy - Informational

Description: The setPID() function is non-functional after the first use.
Risk/Impact: Once a $mxVSW token is deposited into a Masterchef through the GaugeProxy, there is no way to withdraw it. As a result, changing the pool ID will cause the GaugeProxy to be unable to claim rewards from the previous pool and disrupt the reward flow to the Gauges.
Recommendation: The setPID() function should only be called once after deployment.

Finding #5 - Masterchef - Informational

Description: The owner can set the reward token for any pool to any token at any time.
Risk/Impact: If a reward token is added that is also being used as a staking token, users' rewards can be funded with staked tokens.
Recommendation: The team should exercise caution to not allow the same token to be used for staking and rewards, as users may withdraw another user's tokens as rewards if insufficient tokens are supplied for rewards.