Users may unintendedly remove liquidity under a phishing attack.

Handle shw Vulnerability details Impact The removeLiquidity function in Pools.sol uses tx.origin to determine the person who wants to remove liquidity. However, such a design is dangerous since the pool assumes that this function is called from the router, which may not be true if the user is und...

Unrestricted access to lockUnits allows an attacker to steal funds from any user.

Handle shw Vulnerability details Impact The lockUnits and unlockUnits functions in Pools.sol allow anyone to call without any restrictions or access control on the caller. An attacker can steal any user's member units by directly calling lockUnits. Proof of Concept Referenced code:...

Pool functions can be called before initialization in init() of Pools.sol

Handle 0xRajeev Vulnerability details Impact All the external/public functions of Pools.sol can be called by other contracts even before Pools.sol contract is initialized. This can lead to exceptions, state corruption or incorrect accounting in other contracts, which may require redeployment of...

User may not get IL protection if certain functions are called directly in Pools.sol

Handle 0xRajeev Vulnerability details Impact Functions removeLiquidity and removeLiquidityDirectly when called directly, do not provide the the user with IL protection unlike when calling the corresponding removeLiquidity function in Router.sol. This should be prevented, at least for...

Incorrect operator used in deploySynth() of Pools.sol

Handle 0xRajeev Vulnerability details Impact The deploySynth function in Pools.sol is expected to perform a check on the token parameter to determine that it is neither VADER or USDV before calling Factory’s deploySynth function. However, the require incorrectly uses ‘||’ operator instead of ‘&&’...