Mitigations against flash-loan enabled attacks

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?


  • 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.
  • 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.

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.

What are some preventive measures that could be taken to mitigate governance attacks enabled by flash loans?

There have been some interesting precedents where flash loans were used to borrow governance tokens and momentarily increase one’s voting power.

Notably, in October of 2020, the B Protocol used a flash loan to borrow $7 million worth of MKR tokens in order to influence the governance process. Doing so enabled them to use MakerDAO price oracles for their applications, which required white-listing.

Are there ways to mitigate this kind of flash loan-enabled governance attack? Could time-locks be a feasible option, or would projects have to audit each monetary unit in order to discern votes enabled by flash loans?


@cipherix Thanks for you reply and interest in this post.

There are a couple of ways one could do this. The most natural one seems to use the Breaking logic into two transactions mitigation strategy. For instance, instead of letting the biggest governance token holder get immediate control, impose a time lapse for that control to happen and be granted. Such a time lapse should be set s.t. anyone can question any transaction attempting to gain governance control. The ability to question a transaction attempting to elect a governor contract should be voted by existing governance token holders as a further level of scrutiny.

Things could be partially automated by means of using a monitoring system, which would then trigger alarms for the community to further investigate and vote on to accept/reject suspicious transactions attempting to elect a new governor contract.

What do you think?


Thanks for the summary. It’s such a joy to read your work.

There are two things that I’d like to bring up -

  1. What is the maximum proportion of crypto available for lend? Shouldn’t that be equal to the size of the liquidity pool?
    If so, suppose the pool isn’t large enough to provide enough crypto for governance takeover.
    Will this ensure that we don’t need to worry about attacks enabled by flash loans?
  2. What are the incentives of giving loans without collateral & some lending limits?
    If it’s a small loan, I can understand.
    When it’s a large sum, who will be willing to take the default risk?

Thanks again for the post!


Hi @Twan . Thanks for your question and interest in this post.

To follow-up on your points:

  1. Yes, the amount of money that can be lent is directly proportional to the amount of money currently available in liquidity pools. Whether that is enough or not to cover governance control in a target protocol, depends on the target protocol and how much their governance tokens are valued and the amount minted. For Maker, it would have been a matter of time if they had not mitigated governance control (see discussion at: Research Summary: The decentralized financial crisis)
  2. Apart for bugs in the lending platform, there is no default risk, as everything happens in a single transaction. If the loan is not paid back in the same transaction, the latter reverts entirely. The economic incentives for giving flash-loans are in the form of collected loan fees, which are in turn shared amongst liquidity providers and the platform itself.

Let me know my explanation helps :)


Thanks @lnrdpss. It certainly does help. May I follow up with asking how does a revert works if the borrower converts the coin into another currency and sends it to another address?


@Twan A transaction in Ethereum is atomic. An atomic transaction is a sequence of operations that will either succeed entirely, or, if a single operation within the sequence reverts (e.g., if you do not pay a flash loan back, the associated contract will make sure a revert occurs), the whole sequence of operations reverts. Hence, if you send coins to an address, but as part of the same transaction, something fails, the transfer of the coins made in that same transaction will revert.


@lnrdpss I see. So unless they cash out, it’s not going to default.

1 Like

@Twan One cannot cash-out unless the underlying transaction is mined… if it reverts, it cannot be mined. In other words, a transfer of coins as you described will only succeed if its containing transaction succeeds. This concept of atomic transactions is not new; for reference: Atomicity (database systems) - Wikipedia


Just an update to those interested in this thread: OZ’s Forta Protocol appears to make some contributions towards better runtime monitoring:

1 Like