Open Dollar security record

The Open Dollar Protocol introduces the ability of Safe ownership via an NFT. This is done via a `Vault721` contract that acts as the minter of the NFTs and an `ODSafeManager` that is the entry point to manage all the NFV (Non-Fungible Vault) positions. However, by calling `SafeEngine.modifySAFECollateralization()` directly, a user can open a position that does not map to an NFV. Users also have the ability to bypass the `ITaxCollector(taxCollector).taxSingle`, as this call is done in `ODSafeManager` and not in `SAFEEngine` directly. This would allow the user to directly manage the Vault position without interacting with the tax collector and hence take on debt without having to fund the surplus fund, which would be used to cover bad debt.

The `ChainlinkRelayer.latestRoundData()` function fetches the latest price of an asset from Chainlink price feeds. However, as the protocol is intended to be deployed on Arbitrum, checking the sequencer's uptime before querying price data is crucial. If the sequencer is down, there is a chance of using an incorrect or stale price. Please refer to the [Chainlink L2 Sequencer Uptime Feeds](https://docs.chain.link/data-feeds/l2-sequencer-feeds) document for more details.

A user can assign an `ISAFESaviour` to their NFV. If a liquidation attempt is ever made, the `LiquidationEngine` will first make a call to `ISAFESaviour.saveSAFE()` to give the savior an opportunity to restore the safe to a healthy collateralization ratio before it is liquidated. The current implementation maintains the assigned savior after an `NFV` transfer. Whilst the savior implementations may vary, the `LiquidationEngine.protectSAFE()` call assigns a savior to a particular safe rather than the safe owner. A user may want to maintain their savior to protect their NFV until a sale is guaranteed, but there is no clear way to facilitate the removal of a savior before an NFV transfer. Though this behavior is documented, we would like to note that this behavior is restrictive for listed NFV's.

The report gives no description here.

One of the protections introduced for issue OD-1 is the `blockdelay` for addresses on the `_allowlist`. It adds an extra check that the last `_hashState[_tokenId].lastBlockNumber` is at least `blockdelay` blocks old compared to the current `block.number`. This is a good idea, but `blockDelay` is a `uint8`, which can maximum be 256 blocks, which may be insufficient for validating NFV purchases.

To help marketplaces accurately list NFVs and protect users from trading NFV's whose prices have recently changed, the `NFTRenderer` calculates a `stateHash` that reflects the value of each vault. `Vault721` validates that a sufficient number of blocks have passed for a given `stateHash` before facilitating a transfer, giving users to time to be accurately informed about the value of a safe. However, the current `stateHash` only includes a vault's `SAFE.lockedCollateral` and `SAFE.generatedDebt`. This does not capture the additional value held in a vault's `SafeEngine.coinBalance` and `SafeEngine.tokenCollateral`. Additionally, a vault's `stateHash` is not updated when `ODSafeManager.transferInternalCoins()` is called. If a vault transfers its internal coins to another address, its value would drop, and thus the transfer should enforce the time delay.

The `handlerCan[]` mapping in `ODSafeManager` tracks permissions for performing operations on a specific `SafeHandler`. It is used in the `quitSystem()` and `enterSystem()` functions. However, there is no way for a `SafeHandler` to call `ODSafeManager.allowHandler()`, making the functions uncallable.

`DebtAuctionHouse` facilitates auctions to pay off bad debt. Users bid to pay off debt in exchange for governance tokens. If an auction expires without any users placing a bid, the auction can be restarted by calling `restartAuction()` with a more favorable payout of governance tokens. However, it is unclear who would be responsible for restarting the auction. A user who calls `restartAuction()`, places a bid, and then is later outbid will have fronted the gas costs for restarting the auction. This may disincentivize users from restarting auctions, in hopes that a different user might pay the gas costs.

It is important to validate inputs, even if they only come from trusted addresses, to avoid human error. Specifically, in the following functions: * `AccountingEngine.constructor()`: Validate that `_debtAuctionHouse` is a non-zero address. * `AccountingEngine._validateParameters()`: Validate that `debtAuctionMintedTokens` is non-zero. * `Authorizable._addAuthorization()`: Validate that `_account` is a non-zero address. * `CollateralAuctionHouse._validateParameters()`: Validate that `minimumBid` is non-zero. * `DebtAuctionHouse._validateParameters()`: Validate that `bidDecrease` and `amountSoldIncrease` are non-zero. * `SurplusAuctionHouse._validateParameters()`: * Validate that `bidIncrease`, `bidDuration`, and `totalAuctionLength` are non-zero. * Validate that `totalAuctionLength` is greater than `bidDuration`. * Validate that `recyclingPercentage` is less than 100%. * `Vault721.updateVaultHashState()` doesn't check if SAFE exists. * `initializeManager()` and `initializeRenderer()`should have access controls.

`Vault721._afterTokenTransfer()` checks whether the NFV recipient has an `ODProxy` contract deployed. If no `ODProxy` is linked to their address, it will deploy and link a new `ODProxy` to the recipient. However, this assumes that the `_from` address will be an EOA. If the `_from` address is an `ODProxy`, a new `ODProxy` will be deployed and the original `ODProxy` will be added to the `_userRegistry[]`.