Open Dollar security record

The addition of NFT-owned Vaults introduces a new financial instrument with the ability to sell vaults of different collaterals. The ownership of the vault is determined via the ownership of the NFT. This raises a few concerns as until the moment of exchange, the user selling will have ownership, so they can do manipulations to the NFV. This can cause the buying party to receive the vault in a state that is not expected or in a position that is below the value that the buyer paid. Though the system has a `blockdelay` or a `timedelay` depending on the `_allowlist`, but as it is highlighted in OD-9, it is not sufficient and only provides protection for a few minutes. Below are examples of things that can go wrong: 1. NFT image render is only updated when `tokenURI()` is called. There could be a case where a vault gets liquidated whilst it is listed on an exchange and the exchange cashes the metadata, so doesn't call `tokenURI()`. This would mean that the image will not get updated, and the buyer could possibly not know it got liquidated. 2. A malicious seller could remove all the collateral before the sale and hence trick the buyer into paying much more than they should be. Overall, this issue stems from the fact that most NFT exchanges do not take custody of the NFT, and hence, the user selling is able to make changes to the vault. This is a hard design issue to fix, but there are a few options provided in the recommendation section. The team has informed us that the `_allowlist` will contain authorized NFT marketplaces that are custodial, which would solve the issues highlighted.

The report gives no description here.

The Open Dollar protocol allows minting stablecoins against a collateral of Liquid Staking Tokens such as Lido or Rocket Pool tokens. These tokens are issued based on deposits made in ETH and used to run validators on the user's behalf. The rewards generated based on the validator's performance are then distributed to the depositors, and the liquid staking token acquires more value over time due to these rewards. As there are risks associated with running a validator client, it is possible to get slashed, i.e., lose a proportion of your stake. This would mean that the underlying deposited tokens have been removed from the protocol, and if the slashing is significant enough, this could cause the LST to depeg and lose value. This, in return, would lead to multiple SAFEs going underwater at the same time and getting liquidated. There are procedures in place, like the ability to pause the protocol in case of this happening and global settlement that would sell off the debt, but these features need to be properly tested and simulated. There is also a cap on how much collateral one can have in one type of token. ### Comments from the client: Open Dollar has carefully analyzed and created risk profiles on the Liquid Staking Tokens (LSTs) rETH and wstETH which we intend to allow as collateral in the protocol. Through our risk analysis we came to following conclusions: 1. Risk of using LSTs can be minimized by requiring a minimum “Safety Ratio” of `125%`. 2. Adding new LSTs as collateral with greater client diversity that rely less on majority execution clients can limit exposure to the most extreme slashing scenarios. 3. Laying out a specific plan of action to follow in the event of an emergency slashing event can further limit the risk. **Risk of Slashing (Inactivity Leak)** The largest risk for backing Open Dollar with Liquid Staking Tokens lies in the risk of a mass slashing event of the underlying ETH, leading to a depeg between ETH/rETH or ETH/wstETH. The most extreme instance of slashing could occur due to a bug in a supermajority client leading to an "Inactivity Leak" across the network. Based on modeling by Ben Edgington and other Ethereum core developers, slashing would continue until the supermajority clients have a combined amount of ETH under 2/3 of the total [1]. **Current Network Conditions** 1. Lido Majority Execution Client (Geth) share: `67.05%` 2. Rocketpool Majority Execution Client (Geth) share: `~29%` 3. Ethereum Overall Majority Execution Client (Geth) share: `65%` In the most extreme case of an Inactivity Leak slashing event, Geth validators could be slashed until their share of the network is at most `33%`, a `53.333%` slashing of the entire network and an `82%` slashing of Geth nodes. `[53.333% = 65 - ( (100 - 65) * 1/3 )]` Remaining Deposited ETH after a `53.333%` slashing of Geth nodes on LST protocols: Lido: `(67.05 * 0.5333%) + (100 - 67.05) = 65.1%` remaining, and `34.9%` slashed. Rocketpool: `(29 * 0.5333%) + (100 - 29) = 86.5%` remaining, and `13.5%` slashed. If Open Dollar is `50%` backed by Lido ETH and `50%` backed by Rocketpool ETH, this kind of slashing event would cut the backing of the underlying ETH by `24.2%`. Therefore, given the current network conditions, the safety ratio for overcollateralization of both LSTs should never be less than `125%`. Therefore, even in the most extreme scenario, the protocol would still remain fully backed. Additionally, the most extreme slashing scenario would not result in an instantaneous loss, but rather occur gradually. Based on the simulations, an inactive validator starting with `32` ETH during an Activity Leak scenario would expect to reach the Ejection Balance of `16` ETH and be ejected from the system after `4686` epochs. The `1` epoch is approximately `6.4` minutes, so the loss would be over the course of ~3 weeks. This would be more than enough time for Open Dollar to initiate a mitigation strategy. **Other Slashing Risks** In the history of the beaconchain, Ethereum’s proof of stake network, there have been less than `500` total slashings throughout the nearly `10 Million` slots filled by the network. The vast majority of them are from missed attestations, with penalties of less than `10,000` gwei on average- which is less than $0.03 at the current ETH price. Slashing due to missed attestations is unlikely to cause a disturbance to the protocol. **Slashing Risk Mitigation** As part of Open Dollar’s mitigation plan, network client conditions will be continuously monitored. Total debt ceiling for each LST and minimum collateralization ratios will be adjusted in response to changing network client diversity. If client diversity of a particular LST decreases drastically then the debt limit can be lowered, and the safety ratio raised. These changes ensure the protocol will still be fully backed and could easily recover if an extreme event occurs. Additionally, we plan to promote client diversity through the selection o

`CollateralJoinFactory` allows the governance team to deploy `collateralJoins` contracts that manage the specific collateral type. The collateral then gets locked in the contract and virtually accounted for in the rest of the protocol. The `disableCollateralJoin()` function allows the disabling of that specific collateral contract if it needs to be redeployed or removed. When the collateral contract is disabled, a user cannot deposit into it but can withdraw. Whilst a contract is disabled, the factory can deploy another contract of the same type. This could lead to liquidity issues in a case where a user withdraws their funds from the old contract but has deposited them in the new one, as the total funds are now shared across 2 contracts. This would lead to UX issues, rather than users losing access to funds, as they would still be able to withdraw just from a different contract.

The function `Vault721.setSafeManager` allows to update `safeManager` in the vault contract. The `safeManager` tracks the IDs of minted safes(`safeId`) in order to call `vault721.mint` to mint a new safe. By allowing to update `safeManager` the `safeId` counter will start back at 0, preventing the minting of newer safes.

The report gives no description here.

The report gives no description here.

The report gives no description here.

The report gives no description here.

The report gives no description here.