vusd security record

In the Treasury contract, when a token is removed from the whitelist via the `removeWhitelistedToken()` function a number of key state changes are made to clear any state related to the token to be removed. However, in the current implementation of the function, the `cTokens[_token]` mapping is mistakenly deleted twice, while the `oracles[_token]` mapping is not cleared. This means some stale state is left behind that refers to the now removed token.

In the Redeemer contract's `_calculateRedeemable()` function, the code converts the redeemable amount from 18 decimals (VUSD's precision) to the destination token's decimal precision. This conversion uses a hardcoded formula that assumes tokens will have at most 18 decimals: ```solidity return _redeemable / 10**(18 - IERC20Metadata(_token).decimals()); ``` While this approach works for tokens with 18 or fewer decimals, it would fail if a token with more than 18 decimals were added to the protocol in the future.

The Minter contract uses infinite token approvals (`type(uint256).max`) when adding a new token to the whitelist. This occurs in the `_addToken() `function with the line `IERC20(_token).safeApprove(_cToken, type(uint256).max)`. Similarly, in the Treasury contract, infinite approvals are granted in multiple places: when adding tokens via `_addToken()` and when updating the swap manager via `_approveRouters()`. While this approach eliminates the need for subsequent approval transactions, it exposes the protocol to greater risk if any of the approved contracts (cToken contracts or routers) were to be compromised.

The Redeemer and Minter contracts interact with Chainlink oracles to fetch price data for stablecoins, but they do not implement proper error handling mechanisms for these external calls. In the `_calculateRedeemable() `function of the Redeemer contract and the `_calculateMintage()` function of the Minter contract, the code directly calls `latestRoundData()` without any try-catch block or fallback mechanism. If Chainlink bans the contract address from accessing price feeds or if the oracle service experiences downtime, these functions will fail, leading to a temporary disruption of minting and redemption services.

The `updateMaxMintAmount()` function allows the governor to set a new maximum amount of VUSD tokens that can be minted. However there is no validation that the new mint limit is not less than the amount of VUSD already in circulation. If this were to happen it would immediately block the ability to mint tokens in the protocol and leave a potentially confusing mismatch between the mint limit and the currently circulating total supply of VUSD.

Description: From the VUSD documentation, it says: > VUSD is open source, designed for simplicity and security, peg stability, self-sustaining, backed by over-collateralized, yield-generating cryptocurrencies. VUSD is fully auditable on-chain, with real-time proof of reserves available at all times. Having a proof of reserve means that all VUSD should be backed by at least the corresponding amount in USD, as given the collateral assets in the treasury. This invariant, however, is not enforced in `VUSD.updateTreasury()`. Hence, a malicious governor may set a new treasury with no matching reserve to back the value of all the VUSD in circulation.

The protocol currently has no clear contingency plan on how it would handle the event where one of the stablecoins backing VUSD depegs. Currently, `redeem()` function allows the user to specify which token they wish to withdraw for their USDC, therefore in a depeg scenario holders of VUSD would race to withdraw their tokens for one of the whitelisted stablecoins that has not depegged, leaving the last users holding a token that is now only backed by the depegged stablecoin.