30:T1187,md`

Float Protocol › Risks & Mitigations

# Risks & Mitigations In general, it is impossible to build a stablecoin without significant risk, and Float Protocol is not an exception to this. Float Protocol inherently relies on external participants to function and the value stored in the Protocol and its tokens, FLOAT and BANK. There is a possibility that Float Protocol’s system fails and both FLOAT and BANK tokens become worthless. ## Market Collapse In extreme circumstances, classical pegs can become impossible to maintain, at least in the short run. For example, a general panic in the cryptocurrency market may cause the value of FLOAT, BANK and the underlying basket to dramatically plummet until the reserves derived from the basket can no longer support the FLOAT target price. If we attempted to return to peg and everyone owning BANK immediately tried to sell their stake we would cause BANK to hyperinflate to try and return the peg. However, FLOAT is not rigidly tied to a target price. In this case, the auction would fail - all is not lost though. Instead, the auction will "fail" to correct the market price and once the panic is over FLOAT will gradually adjust down to the new normal, or recover back to its target price. If, instead, people try to panic sell FLOAT, this will actually result in the Protocol's favourite case - a confidence contraction - and we can resupply the basket even quicker. ## Smart Contract Failure There is a potential for funds to be lost due to code malfunction or bugs in the smart contracts. This is common among all blockchain applications. Float Protocol has been audited, but will also be reviewed by multiple industry experts. ## Non-ideal control parameters Control parameters that are set at the Protocol launch may be poorly set due to differences in the field compared to simulated scenarios. These parameters can be changed by a Governance vote to improve the functioning of the Protocol in such scenarios. ## Oracle Manipulation Version 1 relies on a ETH-USD ChainLink oracle to provide real-world price data in order to bootstrap its initial Target Price. If this price is incorrect, we will misprice the FLOAT target price of the auction. This is the primary reason we start from a position that should never be favourable, as it allows for arbitragers to quickly close off a badly priced auction, minimising damage. FLOAT Protocol's usage of TWAP oracles is less risk-prone, as these oracles require extensive and sustained collateral to manipulate. Keeping the TWAP periods long ensures that any necessary price movement away from market price is likely to cause substantial losses as it creates an arbitrage opportunity between different markets. Both of these only represent a risk when the Oracle Attack feeds in an unreasonably low price - otherwise the Dutch Auction would just take longer to settle to a clearing value. ## Frontrun Auctions This method can create an interesting game-theory balance for Arbitragers to wait as long as possible and try and front-run each other when the auction is about to clear. This, however, can be counterbalanced by a relative belief in their own ability to front-run, and the lower barrier to entry enabled by the Single Block Composability (which are necessarily mutually exclusive). ## Malicious Governance Currently, there is a timelock of 2 days on all privileged functions, allowing an opportunity for any attacker gains to be lost. In the future with the planned DAO, there is a potential for a 51% attack if enough BANK tokens are bought up to trigger control parameter changes that are unfavourable to FLOAT holders. We will continue to keep the TimeLock in place to allow emergency oracles to have time to react to an attack. We can also consider the BANK value to be in part based on the potential of a 51% attack, which would then mean that the market cap of BANK should grow alongside the growth of FLOAT to keep the 51% of BANK substantially more expensive than the ETH collateral supply. ## Stale price data As we are depending on TWAP data the TWAP is fairly resistant to change even in the event of an Oracle failure if enough TWAP data has been acquired before failure. [1]: https://arxiv.org/pdf/1906.02152.pdf `31:[] 2e:{"title":"Risks & Mitigations / Float Protocol ","cells":[{"id":0,"value":"$30","pinned":false,"hidden":false,"mode":"ojs"},{"id":41,"value":"md`Anything else?\n\nNext`","pinned":false,"hidden":false,"mode":"ojs"}],"files":"$W31","stdlib":"1","titling":"auto"}