The Standard

Summary

SmartVaultV3 assigns MINTER_ROLE and BURNER_ROLE to new vaults, but only the liquidateVault() function revokes these roles upon liquidation. This can lead to a potential risk where liquidated vaults mistakenly retain sensitive roles, especially if liquidate() is called instead.

Vulnerability Details

When a new vault is created(mint()), the MINTER_ROLE and BURNER_ROLE are assigned to it. This allows users to mint or burn Euros based on the collateral value that the vault holds in Euros. If a vault is undercollateralized, there are two functions for liquidation: SmartVault3#liquidate(), which is exclusively called by VaultManager, and smartVaultManagerV5#liquidateVault, which is exclusively called by the 'Liquidator.' Both functions perform liquidation, but only liquidateVault() revokes the Minter/Burner roles from the vault.

If the VaultManager and Liquidator have the same address, and the VaultManager mistakenly calls liquidate() instead of liquidateVault(), they might wrongly believe the vault is fully liquidated and the roles are revoked.

The SmartVaultV3 contract design, including its ifNotLiquidated and ifMinted modifiers, effectively prevents the misuse of mint and burn functions after a vault's liquidation. However, it's not a best practice to allow a liquidated vault to retain sensitive roles like MINTER and BURNER.

Impact

Based on the protocol design, it's not advisable to allow liquidated vaults to retain the BURN and MINT roles.

Tools Used

Manual

Recommendations

It's recommended to modify SmartVault3#liquidate() to ensure that the MINTER/BURNER roles are revoked upon liquidation.