With the recent attack on Euler finance, it makes sense to take a look at the security features of FiRM. Euler, from my own perspective, did everything right as a protocol; They had a large bug bounty and received numerous reviews to ensure that the chance of a hole existing in their contracts was as small as possible. They’re by no means a team that takes security lightly. However, when the attack happened against all odds, it was devastating. This is largely due to the lack of any mitigating security features in their lending protocol, which I’ll discuss below. It also highlights the problem of attempting to make a protocol impenetrable, without having any systems for mitigating an attack, should one happen.
FiRM security features
FiRM has been built with security and exploit mitigation in mind from the start. This means that beyond just testing and working with auditors to ensure that the protocol works correctly, the team has designed multiple `firewalls` to mitigate the severity of any hack that might have slipped through said audits.
No lending of collateral assets
As FiRM lends out the DOLA stablecoin, there is no lending of a depositor’s assets and no cross-collateralization between a user’s different deposits in FiRM. Any collateral in FiRM’s markets is used purely like a security deposit. This means that any future addition of bad collateral to FiRM poses no risk to the collateral of current borrowers. It has the additional effect of preventing any upwards oracle manipulation attacks leading to losses for depositors, as their collateral is kept protected against being lent out to attackers with artificially inflated funds.
No pooling of collateral assets
A large difference between FiRM and other lending protocols is that FiRM keeps users’ collateral in their own personal collateral escrow smart contract. This allows for interesting features such as personalized staking or voting but also increases the security of user deposits. This is due to the fact that the design forces a split of user funds, never allowing an attacker to withdraw more than they should be able to, due to an accounting error.
Only whitelisted contracts
As a precaution against flash loan attacks, FiRM only allows whitelisted contract interactions. This allows regular user wallets to interact while it at the same time limits any automated attacks, forcing any attacker to be extremely well-capitalized. Flashloan attacks require contract interactions and are therefore impossible. This prevents single-transaction attacks like the one Euler suffered, but also makes it more of a hassle for other protocols to integrate with FiRM, as they will need to contact us for a whitelisting. We consider this a worthy trade-off.
Borrow limits: Daily and Global
Every FiRM market has its own daily borrowing limit. It’s calculated as the difference between repayments and borrowings over a 24-hour period. In FiRMs case, it reduces the impact of an attack on DOLA’s price, as funds gained by an attacker will be limited to the daily borrowing limit. To further limit the potential impact of an attack, the FiRM FED contract supplying DOLA to lending markets also has limits on how much liquidity it can supply both to each market individually and the system globally. These parameters are set by governance and are continuously adjusted as needed.
Pessimistic price oracles
The pessimistic price oracle serves as a mitigation for upwards price manipulation. It is an additional layer of security built on top of the price feed providers, of which we only strive to use secure and proven solutions like chainlink. It records the lowest prices registered by the oracle over the past 2 days, and if the current price is higher than the two-day low, it then returns whichever is lowest out of the price feed or the twoDayLow*1/collateralFactor. This ensures that any sudden upwards manipulation of the oracle cannot be used for excessive borrowing.
