Securing The Frontier
Lately we’ve done a lot of ideating and deep thinking in regards to security at Inverse. It’s clear that something has to change, and we’ve identified ways in which we can improve our security both technically and in regards to our internal product development processes.This post will focus specifically on how we propose to make Frontier more secure, with a later post explaining how we’ll plan to improve our product development processes.
Our current security architecture for Frontier is based largely on single points of defense. In other words, as long as our oracles are safe, the system can be considered safe as a whole. What we’re moving towards is instead having multiple points of defense where every single point must fail, for an attack to be fully successful.
Think of it like a castle. If all you have is a single wall, then all the barbarians have to do is break through it, or climb over it. However, if you have a moat, a wall and an inner castle, it suddenly takes a much more determined enemy to break through. The guiding philosophy of our new approach is to ensure multiple layers are in place and that all layers must fail in order for an attack to fully succeed.
We can use the example of a price oracle manipulation attack where multiple points of defense offer multiple layers of defense, even if the oracle fails.
With multiple points of defense, attacks penetrating the outer perimeter are mitigated by defenses further inside of the protocol.
Both a price ceiling in the price feeds and a protocol wide borrow cap, would have prevented the incidents on 4/2 and 6/16 from being profitable for the perpetrator.
Moving Price Ceiling for Collateral-only Asset Oracles
An asset in a lending market can be both a borrowable asset and a collateral asset. The first can be lent to borrowers, while the latter can only be used as collateral. For collateral assets, it’s possible to have a ceiling for the oracle price, as there’s no risk of an attacker borrowing them at an artificially low price, should there be a sudden increase in value.
By adding a price ceiling to the price feed of collateral assets, it’s possible to limit the damage that can be done with oracle manipulations. For example, if the collateral factor for an asset is 50%, a price ceiling 100% above current price, will prevent extracting more value than was deposited, making for a very limited amount of potential bad debt. A higher collateral factor will require a lower moving price ceiling.
Price ceiling mitigates short term oracle manipulations, where an attacker would quickly raise the price of a collateral asset, borrow against it, and then reduce the price again. They may still be vulnerable to someone walking up the price over a longer period of time, but that’s a much harder attack to pull off.
It’s important to keep note of the weaknesses additional features can introduce. Moving price ceilings can result in bad debt for assets, if borrowing is enabled for an asset with a price ceiling. This would occur if the real price of a borrowable asset increased faster than the ceiling could keep pace. For that reason, we do not plan to use oracle ceilings for any borrowable assets.
Daily Borrow Cap:
By adding a moving daily borrow cap to borrowable assets, we can limit the potential funds an attacker may steal. The borrow cap will be set by governance, and will replenish over time as it sits unused.
To avoid denial of service attacks, the borrowed amount will be calculated as the difference between what has been borrowed, and what has been repaid in a 24 hour window.
As an example: Someone borrows 750,000 DOLA and the borrow cap is 1 million DOLA. This would mean that there’s now only 250,000 available for borrowing. Another user then repays 250,000 DOLA, making 500,000 DOLA available for borrowing.
This feature reduces the potential amount stolen in case of a successful attack. If the price of the attack is higher than the borrow cap, then the attack is no longer viable, as would have been the case with the 6/16 incident.
It’s important to note that a capital-rich attacker could still build up a debt position over multiple days, and then execute an attack, to get around the borrow limit. However, this is something that can be detected by our DAO analytics capabilities, and reacted on before an attack is successfully executed.
Adding a daily borrow cap also imposes some usability challenges on the margins. A large whale wanting to deposit more than the borrow cap, would have to stagger their deposit over multiple days. This is why we are planning to let a guardian role reset the borrow cap, making it possible to accommodate any very large users. The borrow cap can also be controlled by governance, in case it ever needs to be adjusted upwards.
This is the first of multiple posts I will be sharing on our improved security posture at Inverse. The Product Working Group at Inverse is actively seeking contributors with a background in security who are interested in getting involved in reviewing new code and working with the engineering team on an ongoing basis. If you are interested, ping me @0xMT and/or any of our Risk Working Group team members like @edo or find us in the project discord. LGTM!
