Hey llama, Sorry for the delay answering here, wanted to get some feedback from the technical team to answer. Forwarding it below:
Added bad debt risk from data feed delays: Even if API3 sequencer does not suffer any issues, the data feeds used for opening and closing positions are delayed by 15-30 seconds. During long tail events where tokens experience significant volatility this could create a bad debt attack vector similar to the one experienced by Compound V2 during the price spike of UNI in February 2024. Arbitrageurs can create bad debt by exploiting the price discrepancy and this is not prevented by API3 OEV auctions as this attack can be atomically exploited. In addition to this, if the API3 sequencer suffers downtime the bad debt risks further increase as liquidations would now too be delayed by 15-30 seconds. To account for this risk, lending protocols should allow a lower LTV than they otherwise would have without the delay. I would like to see data that takes into account long tail events such as this and evaluates the added risks, and proposes changes that should be made to LTV offered by Moonwell protocol.
The compound V2 UNI v2 tweet you’ve listed mentions that this bad debt was the result of the TWAP anchor and not the Chainlink price feed failing to push the price in time. In the case of Uniswap the anchor period is 1800 seconds or 30 mins, which is significantly higher than 30seconds. A 30 minute twap could be problematic which is why we suggest protocols to not rely on TWAP feeds.
In our analysis of on-chain oracle data on Binance chain for BTC, BNB and wBTC since 2021, we couldn’t observe any instances where a 30second delay would have any impact on the performance of any lending markets on those chains. We will share the complete data soon, but just to give some perspective, the maximum deviation in a 60 second window from 2021 to present day has only been 3.6% for btc and this only happened twice. The other high deviations are less than 2%. We would not suggest any changes in LTVs are required. Additionally, if a rapid movement is likely to cause many liquidations, API3’s OEV model allows searchers to trigger extra updates to capture these, leading to more granular feeds, and immediate updates.
Added bad debt risk to the protocol from exclusive access to liquidations: API3 OEV auctions award exclusive access to liquidations for 60 seconds to a single winning bidder. This introduces the risk of a single actor not having the correct strategy or having having bugs that cause them to not capture every single liquidation during their exclusive 60s period, causing some liquidations to be delayed. This is a known risk that has been brought up with the Timeboost MEV auction for Arbitrum. Arbitrum anticipate a PBS style market developing around Timeboost where the winner can resell MEV opportunities to mitigate such risks. Such a re-selling market structure does not necessarily seem possible for API3 OEV auctions, and also requires a very developed MEV ecosystem to develop, potentially leaving the API3 mechanism with this risk.
This is incorrect, OEV auctions are currently divided into two phases, bid phase and award phase. each configurable to the market and feed. At the moment we are targeting a bid and award phase of 15 seconds each, which is why the delay on the base feed is 30 seconds. As you’ve stated arbitrum timeboost is also looking to give the highest bidder 1 minute advantage in the express lane and many suspect that this could create secondary markets where the 1 minutes window is resold in chunks to the searchers thereby maximizing revenue for the Arbtirum DAO, this can also easily happen with OEV. In the OEV award phase, the auction winner can resell the opportunity in a secondary market since the updater address can be tied to a contract that can only allow the winner of the secondary marketplace auction to perform the OEV update. As with timeboost, its a possibility but as you can see its very doable in theory.
Hurdles to onboard liquidators: There are large switching costs for liquidators to onboard to API3 because they must bridge funds to the API3 L2 and develop a bidding strategy based on efficiently using locked collateral.
The collateral only gets locked upon winning a bid and gets released upon executing the price update. This means that with a very small amount of collateral, a user can place very large amount of bids with large bids amount. The collateral is only 5% of the bid amount and gets released upon submitting fulfilment of price update. While we suspect this might lead to initial friction in onboarding, the slashing mechanism disincentivizes searchers from placing bids that they don’t follow through with ensuring that updates arrive on-chain as soon as they are required. The 5% number can be tweaked over time should it be necessary to ensure optimal performance vs searcher QOL .
Poor capital efficiency for liquidators: Liquidators cannot simply use flashloans with API3 liquidations, they have to lock up a portion of their bids on an L2 and suffer opportunity costs for their capital as well as liquidity constraints due to bridging time. Requiring upfront payment of a portion of the bid will lead to lower value capture and lower liquidator adoption especially due to the cyclical nature of liquidation opportunities. It is unlikely liquidators will want to keep significant funds on the API3 L2, and will be underfunded when big liquidation spikes occur. This leads to liquidators not having enough capital to bid up to 80-90% of the value on big opportunities like they could with flash loans alone.
Flashloans to pay winning bids are possible with API3, see here - OEV Searching | Documentation.