- 2 medium risk issues
- 3 low risk issues
- 5 informational
add() does not prevent the same LP token from being added more than once.
If a token is mistakenly added more than once, it would reset the rewards variables associated with the token (e.g., accSushiPerShare).
This could be prevented by creating a mapping from addresses to booleans, such that LP tokens get mapped to true once they've been added. The function could then have a require-statement preventing the same LP token from being added twice.
migrate() is dependent on a currently unspecified migrator contract.
Migrator can be set to any contract, potentially allowing the theft of funds, particularly if the owner's private key is compromised...
devAddr receives 9% of every SUSHI distribution instead of 10%.
According to the provided docs, "...10% of every SUSHI distribution is set aside for the development & future iterations, including security audit." However…
_moveDelegates() may not behave correctly after token transfers.
It is not clear if this functionality is as intended. If so, no changes are needed, but user documentation should exist describing the scenario above.
massUpdatePools() may run out-of-gas if too many tokens are added.
See the scope of the Security Review + read the full report here: