Dear saucepoint:
I find that a potential risk can arise from the possible parameter manipulation of the function afterSwap(). Malicious attackers can input any value of parameters key and params to manipulate intermediate variables and the key stop loss operation in the internal function fillStopLoss() can also be influenced.
I think critical hooks should all be protected which can only be invoked by pool manager. For example, the afterInitialize() is protected in your StopLoss contract. However, the afterSwap() isn't. So adding a simple protective modifier may be good to avoid potential risk.
Dear saucepoint: I find that a potential risk can arise from the possible parameter manipulation of the function afterSwap(). Malicious attackers can input any value of parameters key and params to manipulate intermediate variables and the key stop loss operation in the internal function fillStopLoss() can also be influenced.
I think critical hooks should all be protected which can only be invoked by pool manager. For example, the afterInitialize() is protected in your StopLoss contract. However, the afterSwap() isn't. So adding a simple protective modifier may be good to avoid potential risk.
Hope it helps and glad to discuss further.