CTA: In these threads, we attempt to further the discussion of a key problem in this category and evolve our understanding of the domain space where research work has not yet answered the specific problem or question being considered. These posts are living documents, and it is our hope that the community will continue to contribute to their structure and content.
Key Problem
This post discusses some strategies for mitigating flash-loan enabled attacks
Problem Statement
- How can mechanism design choices mitigate flash-loan enabled attacks?
Background
- Flash loans are crypto loans that do not require collateral. They are smart contracts, programs which force borrowers to repay the entire loan in the same transaction as the loan was granted; otherwise, if the loan is not paid in full, the transaction reverts.
- Flash loans rely on funds from a liquidity pool (which is also a smart contract).
- Lending platforms make a profit by charging a lending fee on each flash loan. The lending fee must also be paid in the same transaction as the loan grant.
- Flash loans enable borrowers to act as whales, borrowing large sums of money that they would not have otherwise. Among other uses, flash loans allow profiting from arbitrage, exploiting price differences across exchanges. Example:
- Say token X is traded at 2 cents in one exchange, while traded at 3 cents in another. One could buy X at a cheaper price, selling it at a higher price elsewhere.
- A borrower wishes to take advantage of the given price difference, but only has 1,000 dollars in his wallet. If he were to use all his funds, the borrower would make a profit of less than 500 dollars.
- If the same borrower takes a flash loan of 1,000,000 dollars, the net profit reaches a value close to half a million dollars, after deducting the loan fee and associated gas costs.
- While this example builds on an honest use case, flash loans can be harmful. For instance, they can be used to distort the market value of a given coin, allowing an attacker to profit from an artificially induced price difference.
- Examples of attacks enabled by flash loans include pump and arbitrage (artificially inflating the price of an asset, and then taking advantage of the resulting price difference), oracle price manipulation (lowering the price of an asset and then buying it at a discount), wash trading (artificially inflating the trading volume of a coin, giving the false impression that the coin is being sought out by buyers; such sentiment can lead to more traders buying the coin, increasing its price), governance takeover (an attacker uses a flash loan to buy out the governance of a target protocol), etc.
- Flash loans have amplified economic attacks as they require little up-front investment by attackers and are almost risk free; all an attacker has to lose are the associated gas costs. The returns, in contrast, could be in the millions.
Approach / Methodology
- Mitigation strategies can be used to attempt to prevent (but not fully eliminate) flash loan enabled attacks.
- Mitigation strategies are preventive in nature, i.e, they are reusable solutions attempting to prevent flash-loans from occuring in the first place. Example strategies include:
- Breaking logic into two transactions
- Description: the premise of a flash loan is that users borrow and pay back their loans in a single transaction. If this premise is broken, by design one cannot use funds that they do not already own.
- Example implementation: in a first transaction, have users call a deposit function that would take funds needed to execute a target function; the latter would then be called in a second transaction and would use funds deposited by the callee.
- Pros:
- Technically, this mitigation strategy is agnostic of the underlying application and largely general.
- Cons:
- Requires an extra transaction to occur, adding further complexity and increasing overall gas costs.
- Turns the target smart contract into a custodian (if it isn’t one already).
- Rely on robust oracles
- Description: Decentralized exchanges do not communicate with one another; hence, prices may differ. Attackers have successfully used flash loans to manipulate the price of a coin in one exchange to distort the market in their favor. The latter can be mitigated if one relies on the price of a coin as aggregated by many exchanges, instead of a single or relatively few exchanges.
- Example implementation: use Chainlink’s oracle price feed, while checking for price staleness.
- Pros:
- Mitigates the risk of having an incorrect view of a coin’s real price.
- Cons:
- Transaction cost increases.
- Keep slippage to a certain limit
- Description: Slippage refers to the situation where the price of a crypto asset fluctuates between the moment a user submits a transaction and the time it is actually mined. Slippage can be induced on purpose as a means for an attacker to profit (e.g., bZx hack).
- Example implementation: restrict slippage to a certain limit, for instance 3%.
- Pros:
- Restricts the margin of fluctuation to a maximum.
- Cons:
- Attackers can still cause slippage to occur up to the maximum defined. At best, it keeps damage within a certain margin.
- Limits, if set incorrectly, may either be too restrictive, or too loose.
- Breaking logic into two transactions
- A second mitigation strategy class comprises reactive measures, i.e., steps on how to react to an attack after it occurs.
- Blacklisting ability
- Description: Suspicious actors (addresses) should be blacklisted; if so, they are not able to perform any operation on the target platform until removed from that list.
- Example implementation: keep a record of suspicious addresses that can be either added or removed. Prior to each transaction, make sure the current callee is not blacklisted. If so, revert the transaction altogether.
- Pros:
- Prevents an address from performing a suspicious activity without pausing the contract altogether.
- Cons:
- Unless a governance setup is in place, this strategy introduces some level of centralization, as privileged actors would be able to blacklist whoever they want.
- In Ethereum, one can circumvent the blacklist mechanism by simply generating a new address (which is free of cost). Hence, depending on the given blockchain, this strategy may not help much on its own.
- Pausing ability
- Description: in case a contract does get hacked, one should be able to pull a safety trigger, pausing the contract. This gives time to the team to understand the issue at hand and prevent further hacks from happening until a fix is in place.
- Example implementation: for Ethereum smart contracts, make the target contract inherit from OpenZeppelin’s Pause Contract. For other platforms, replicate the same logic as given in OpenZepplin.
- Pros:
- Stops further attacks from happening until the issue at hand is understood and a fix is devised.
- Cons:
- Introduces some level of centralization; only privileged actors are able to use the safety feature.
- Stops the contract altogether, bringing down-time.
- Alone, this strategy only works after the fact, i.e., after an initial hack has taken place.
- Runtime monitoring
- Description: to be able to identify suspicious transactions, one must constantly watch transactions as they appear in the mempool. Upon seeing those, react accordingly. Examples of the latter include front-running the suspicious transaction and putting the given sender’s address in a blacklist or pausing the contract (as discussed above).
- Example implementation: some runtime monitoring solutions exist out of the box (e.g. Quantstamp’s monitoring tool and OpenZeppelin’s Defender), but as far as I am aware, none of them provide the means to front-run suspicious transactions and prevent a potential attack. They generally rely on alerting mechanisms (e.g., sending an email, sms, etc). Front-running, in turn, requires a custom solution, which cannot lead to a high-rate of false positives; otherwise, honest players would be unfairly blacklisted or, in the case of a full pause, the contract would often go down.
- Pros:
- In theory, this allows one to react to an attack as it happens. It can be used as a failsafe mechanism in addition to the preventive measures previously discussed.
- Cons:
- Hard to implement; existing solutions generally work after-the-fact (i.e., after a hack has happened).
- Coverage protection
- Description: different from the other strategies, which are technical in nature, this aims to protect users in case the smart contracts they lock funds in get hacked.
- Example implementations: Nexus mutual and Quantstamp Chainproof protocol.
- Pros:
- Provides users with financial coverage.
- Cons:
- Since smart contracts do interface with external components (libraries, other contracts, etc), users may not be fully covered for components other than the smart contract they locked their funds in. Depending on how contracts interplay, coverage may only be partial.
- Blacklisting ability
Key Takeaways
In the crypto world, flash loans differentiate themselves from other loans in the sense that they do not require any collateral, so long as they are paid back within the same transaction as the loan was granted. Although legitimate use cases exist for flash-loans, they have been used to exploit many different protocols. In this post, I discussed different strategies to mitigate flash-loan enabled attacks, both preventive and reactive. In essence, there is no silver bullet; each solution has pros and cons that must be considered by each project.
Future Work
- Monitoring tools are in their early days—we need to be able to detect suspicious transactions and front-run them successfully in order to prevent flash-loan enabled hacks. This is largely unexplored as of now.
- We need to catalogue mitigation strategies against flash-loan enabled attacks. This is certainly a first step, but community involvement is a must.
