Centralization risk

There are two types of privileged accounts for the StrategyPassiveManagerUniswap contract:

• The owner

• The manager

The manager can call the panic and unpause functions, which essentially pause the system, remove the liquidity and the allowances, or unpause the system and add the allowances and the liquidity.

The owner can do everything the manager can do and also set the paths for the token0/token1 to native swaps, set the allowance of deviation from the TWAP, and set the position width.

Because the owner can essentially set the deviation from the TWAP and the position width, they could theoretically manipulate the system to their advantage. This is an important consideration for the security of the system, as it could lead to a loss of funds for the users of the system.

Special consideration should be given to the inCaseTokensGetStuck function, which allows the owner to withdraw tokens from the Vault contract. At the time of the audit, the funds do not persist in the Vault contract, as they're transferred straight away to the underlying strategies during any action, so it does not pose a direct security threat. This persistency of funds might change in the future, if the team was to use the Vault to actually store funds. In that case, the inCaseTokensGetStuck function would allow the owner to withdraw all funds from the Vault, posing a significant risk to all the users of the protocol.

The Beefy team considers improving decentralization in the future; however, it is important to note that the current implementation is not fully decentralized.