EIPs/EIPS/eip-3156.md

eip	title	author	discussions-to	status	type	category	created
3156	Flash Loans	Alberto Cuesta Cañada (@albertocuestacanada), Fiona Kobayashi (@fifikobayashi), fubuloubu (@fubuloubu)	https://ethereum-magicians.org/t/erc-3156-flash-loans-review-discussion/5077	Draft	Standards Track	ERC	2020-11-15

Simple Summary

This ERC provides standard interfaces and processes for flash lenders and borrowers, allowing for flash loan integration without a need to consider each particular implementation.

Motivation

Flash loans allow smart contracts to lend an amount of tokens without a requirement for collateral, with the condition that they must be returned within the same transaction.

Early adopters of the flash loan pattern, such as Aave, DxDy, Uniswap and the Yield Protocol have produced different interfaces and different use patterns. The diversification is expected to intensify, and with it the technical debt required to integrate with diverse flash lending patterns.

Some of the high level diferences in the approaches across the protocols include:

• Repayment approaches at the end of the transaction, where Aave V2 pulls the flash loaned amount plus the flash fee off the flash smart contract, compared to other protocols where the contract needs to explicitly calculate the debt+fee amount and manually return it to the lending pool.
• Uniswap's Flash Swaps offer the ability to repay the flash transaction using a token that is different to what was originally flash borrowed, which can reduce the overall complexity of the flash transaction and gas fees, depending on the purpose of the flash swap (i.e. the second last step in flash self liquidation to swap back into the repayment token).
• DyDx offering a single entry point into the protocol regardless of whether you're buying, selling, depositing or chaining them together as a flash loan, whereas other protocols offer discrete entry points (e.g. Uniswap V2's swap() and Aave V2's flashLoan() methods).
• The Yield Protocol allows to flash mint any amount of its native token without charging a fee, effectively allowing flash loans bounded by computational constraints instead of asset ownership constraints.

Specification

A flash lending feature integrates two smart contracts using a callback pattern. These are called the LENDER and the RECEIVER in this EIP.

Lender Specification

A lender smart contract implementing a flash lending feature MUST implement a flashSupply function:

function flashSupply(address token) external external returns (uint256);

The flashSupply function MUST return the maximum loan possible for token. If a token is not currently supported flashSupply MUST return 0, instead of reverting.

A lender smart contract implementing a flash lending feature MUST implement a flashFee function:

function flashFee(address token, uint256 amount) external external returns (uint256);

The flashFee function MUST return the fee charged for a loan of amount token. If the loan cannot be executed flashFee MUST revert.

A lender smart contract implementing a flash lending feature MUST implement a flashLoan function:

function flashLoan(address receiver, address token, uint256 amount, bytes calldata data) external {
  ...
  FlashBorrowerLike(receiver).onFlashLoan(msg.sender, token, amount, fee, data);
  ...
}

The flashLoan function MUST execute the equivalent of an ERC20.transfer operation before calling FlashBorrowerLike(receiver).onFlashLoan(...).

The lender contract MAY mint the tokens lended, instead of executing a transfer of tokens it holds.

The flashLoan function MUST verify that the tokens lended were returned, and MUST NOT take them from the receiver.

The receiver MUST take an action to return amount + fee tokens and allow the transaction to resolve.

If the flashLoan used tokens generated by a mint, they SHOULD be the target of a burn before the end of the transaction.

If a fee is charged, the contract implementing flashLoan MAY use it in any desired way (e.g. the fee can be burned or transferred to any other party).

Receiver Specification

A receiver of flash mints MUST implement an onFlashLoan callback:

interface FlashBorrowerLike {
    function onFlashLoan(address sender, address token, uint256 amount, uint256 fee, bytes calldata) external;
}

On the callback execution the receiver MUST have received amount tokens of the token ERC20 contract from the caller. The receiver can trust that sender is the account that initiated the flash loan in the caller. For the transaction to not revert, receiver MUST send amount + fee of token to the caller. Before that, the receiver can implement any logic it desires.

Rationale

The interfaces described in this ERC have been chosen as to cover the known flash lending use cases, while allowing for safe and gas efficient implementations.

flashSupply(address token)

flashSupply returns zero on unsupported contracts to allow for borrowers to discover the lending services offered by an ERC-3156 compliant lender.

flashFee(address token, uint256 amount)

flashFee reverts on unsupported contracts, because returning a numerical value would be incorrect.

flashLoan(address receiver, uint256 amount, bytes calldata data)

flashLoan has been chosen as descriptive enough, unlikely to clash with other functions in the lender, and including both the use cases in which the tokens lended are held or minted by the lender.

receiver is taken as a parameter to allow flashLoan to be called by EOAs, as opposed to the pattern in which onFlashLoan is called on msg.sender. This allows the lender to inform the receiver which address called flashLoan. This particular setup allows the receiver to implement an account based platform.

Existing flash lenders (Aave, dYdX and Uniswap) all provide flash loans of several token types from the same contract (LendingPool, SoloMargin and UniswapV2Pair). Providing a token parameter in both the flashLoan and onFlashLoan functions matches closely the observed functionality.

A bytes calldata data parameter is included for the caller to pass arbitrary information to the receiver, without impacting the utility of the flashMint standard.

onFlashLoan(msg.sender, amount, fee, data)

onFlashLoan has been chosen as descriptive enough, unlikely to clash with other functions in the receiver, and following the onAction naming pattern used as well in EIP-667.

A sender will often be required in the onFlashLoan function, which the lender knows as msg.sender. An alternative implementation which would embed the sender in the data parameter by the caller would require an additional mechanism for the receiver to verify its accuracy, and is not advisable.

The amount will be required in the onFlashLoan function, which the lender took as a parameter. An alternative implementation which would embed the amount in the data parameter by the caller would require an additional mechanism for the receiver to verify its accuracy, and is not advisable.

A fee will often be calculated in the flashMint function, which the receiver must be aware of for repayment. Passing the fee as a parameter instead of appended to data is simple and effective.

Backwards Compatibility

No backwards compatibility issues identified.

Test Cases

The test cases of the reference implementation are available from the ERC20Flash repository.

Implementation

The reference implementations included inline can also be found at the ERC20Flash repository.

Of note are the ERC-3156 wrappers for existing flash lenders, also be found at the ERC20Flash repository.

Other implementations include WETH10 and MakerDAO MIP-25.

Flash Borrower Reference Implementation

// SPDX-License-Identifier: GPL-3.0-or-later
pragma solidity ^0.7.5;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/math/SafeMath.sol";

contract FlashBorrower {

  function onFlashLoan(address sender, address token, uint256 value, uint256 fee, bytes calldata) external {
    // do something with the tokens received

    IERC20(token).transfer(msg.sender, value.add(fee));
  }
}

Flash Mint Reference Implementation

// SPDX-License-Identifier: GPL-3.0-or-later
pragma solidity ^0.7.5;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/math/SafeMath.sol";
import { IERC3156FlashBorrower, IERC3156FlashLender } from "../interfaces/IERC3156.sol";


/**
 * @author Alberto Cuesta Cañada
 * @dev Extension of {ERC20} that allows flash minting.
 */
contract ERC20FlashMinter is ERC20, IERC3156FlashLender {
    using SafeMath for uint256;

    uint256 public fee;

    /**
     * @param fee_ The divisor that will be applied to the `amount` of a `loan`, with the result charged as a `fee`.
     */
    constructor (string memory name, string memory symbol, uint256 fee_) ERC20(name, symbol) {
        fee = fee_;
    }

    /**
     * @dev The amount of currency available to be lended.
     * @param token The loan currency.
     * @return The amount of `token` that can be borrowed.
     */
    function flashSupply(address token) external view override returns (uint256) {
        return type(uint256).max;
    }

    /**
     * @dev The fee to be charged for a given loan.
     * @param token The loan currency. Must match the address of this contract.
     * @param amount The amount of tokens lent.
     * @return The amount of `token` to be charged for the loan, on top of the returned principal.
     */
    function flashFee(address token, uint256 amount) external view override returns (uint256) {
        require(token == address(this), "FlashMinter: unsupported loan currency");
        return _flashFee(token, amount);
    }

    /**
     * @dev Loan `amount` tokens to `receiver`, which needs to return them plus a 0.1% fee to this contract within the same transaction.
     * @param receiver The contract receiving the tokens, needs to implement the `onFlashLoan(address sender, uint256 amount, uint256 fee, bytes calldata)` interface.
     * @param token The loan currency. Must match the address of this contract.
     * @param amount The amount of tokens lent.
     * @param data A data parameter to be passed on to the `receiver` for any custom use.
     */
    function flashLoan(address receiver, address token, uint256 amount, bytes calldata data) external override {
        require(token == address(this), "FlashMinter: unsupported loan currency");
        uint256 _fee = _flashFee(token, amount);
        _mint(receiver, amount);
        IERC3156FlashBorrower(receiver).onFlashLoan(msg.sender, token, amount, _fee, data);
        _burn(address(this), amount.add(_fee));
    }

    /**
     * @dev The fee to be charged for a given loan. Internal function with no checks.
     * @param token The loan currency.
     * @param amount The amount of tokens lent.
     * @return The amount of `token` to be charged for the loan, on top of the returned principal.
     */
    function _flashFee(address token, uint256 amount) internal view returns (uint256) {
        return fee == type(uint256).max ? 0 : amount.div(fee);
    }
}

Flash Loan Reference Implementation

// SPDX-License-Identifier: GPL-3.0-or-later
pragma solidity ^0.7.5;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/math/SafeMath.sol";
import { IERC3156FlashBorrower, IERC3156FlashLender } from "../interfaces/IERC3156.sol";


/**
 * @author Alberto Cuesta Cañada
 * @dev Extension of {ERC20} that allows flash lending.
 */
contract FlashLender is IERC3156FlashLender {
    using SafeMath for uint256;

    mapping(address => bool) public supportedTokens;
    uint256 public fee;


    /**
     * @param supportedTokens_ Token contracts supported for flash lending.
     * @param fee_ The divisor that will be applied to the `amount` of a `loan`, with the result charged as a `fee`.
     */
    constructor(address[] memory supportedTokens_, uint256 fee_) {
        for (uint256 i = 0; i < supportedTokens_.length; i++) {
            supportedTokens[supportedTokens_[i]] = true;
        }
        fee = fee_;
    }

    /**
     * @dev The amount of currency available to be lended.
     * @param token The loan currency.
     * @return The amount of `token` that can be borrowed.
     */
    function flashSupply(address token) external view override returns (uint256) {
        return supportedTokens[token] ? IERC20(token).balanceOf(address(this)) : 0;
    }

    /**
     * @dev The fee to be charged for a given loan.
     * @param token The loan currency.
     * @param amount The amount of tokens lent.
     * @return The amount of `token` to be charged for the loan, on top of the returned principal.
     */
    function flashFee(address token, uint256 amount) external view override returns (uint256) {
        require(supportedTokens[token], "FlashLender: Unsupported currency");
        return _flashFee(token, amount);
    }

    /**
     * @dev Loan `amount` tokens to `receiver`, which needs to return them plus a 0.1% fee to this contract within the same transaction.
     * @param receiver The contract receiving the tokens, needs to implement the `onFlashLoan(address sender, uint256 amount, uint256 fee, bytes calldata)` interface.
     * @param token The loan currency.
     * @param amount The amount of tokens lent.
     * @param data A data parameter to be passed on to the `receiver` for any custom use.
     */
    function flashLoan(address receiver, address token, uint256 amount, bytes calldata data) external override {
        require(supportedTokens[token], "FlashLender: Unsupported currency");
        IERC20 currency = IERC20(token);
        uint256 _fee = _flashFee(token, amount);
        uint256 balanceTarget = currency.balanceOf(address(this)).add(_fee);
        currency.transfer(receiver, amount);
        IERC3156FlashBorrower(receiver).onFlashLoan(msg.sender, token, amount, _fee, data);
        require(currency.balanceOf(address(this)) >= balanceTarget, "FlashLender: unpaid loan");
    }

    /**
     * @dev The fee to be charged for a given loan. Internal function with no checks.
     * @param token The loan currency.
     * @param amount The amount of tokens lent.
     * @return The amount of `token` to be charged for the loan, on top of the returned principal.
     */
    function _flashFee(address token, uint256 amount) internal view returns (uint256) {
        return fee == type(uint256).max ? 0 : amount.div(fee);
    }
}

Security Considerations

Verification of callback arguments

The arguments on the onFlashLoan callback can be divided in two groups, that require different checks before they can be trusted to be genuine.

0. No arguments can be assumed to be genuine without some kind of verification. sender, token and value refer to a past transaction that might not have happened if the caller of onFlashLoan decides to lie. fee might be false or calculated incorrectly. calldata is not expected to have been verified or manipulated by the caller.
1. To trust that the value of sender, token, value and fee are genuine a reasonable pattern is to verify that the onFlashLoan caller is in a whitelist of verified flash lenders. Since often the caller of flashLoan will also be receiving the onFlashLoan callback this will be trivial. In all other cases flash lenders will need to be approved if the arguments in onFlashLoan are to be trusted.
2. To trust that the value of data is genuine, in addition to the check in point 1, it is recommended to implement the flashLoan caller to be also the onFlashLoan receiver. With this pattern, checking in onFlashLoan that sender is the current contract is enough to trust that the contents of data are genuine.

Flash lending security considerations

Example - Transfer from receiver

An implementation that allows flash lending to an arbitrary target, and that also takes the flash loaned amount from such target at the end of the transaction can be used to drain assets of a smart contract that trades a pair of assets based on internal balances.

1. The attacker triggers a flash loan of 1 million DAI to an AMM trading DAI/ETH.
2. The attacker sells 1000 ETH to the AMM trading pair, obtaining a larger amount of DAI than the pre-transaction price would have returned.
3. The flash lender burns the 1 million DAI (plus possibly a fee) from the receiver (AMM trading pair), which bears the loss of having sold DAI to the attacker at an artificially depressed price.

The key takeaway being that smart contracts trading on balances should not give blanket transfer approvals to smart contracts with flash loan features, unless they can be certain of their implementation.

Flash minting external security considerations

The typical quantum of tokens involved in flash mint transactions will give rise to new innovative attack vectors.

Example 1 - interest rate attack

If there exists a lending protocol that offers stable interests rates, but it does not have floor/ceiling rate limits and it does not rebalance the fixed rate based on flash-induced liquidity changes, then it could be susceptible to the following scenario:

FreeLoanAttack.sol

1. Flash mint 1 quintillion DAI
2. Deposit the 1 quintillion DAI + $1.5 million worth of ETH collateral
3. The quantum of your total deposit now pushes the stable interest rate down to 0.00001% stable interest rate
4. Borrow 1 million DAI on 0.00001% stable interest rate based on the 1.5M ETH collateral
5. Withdraw and burn the 1 quint DAI to close the original flash mint
6. You now have a 1 million DAI loan that is practically interest free for perpetuity ($0.10 / year in interest)

The key takeaway being the obvious need to implement a flat floor/ceiling rate limit and to rebalance the rate based on short term liquidity changes.

Example 2 - arithmetic overflow and underflow

If the flash mint provider does not place any limits on the amount of flash mintable tokens in a transaction, then anyone can flash mint 2^256-1 amount of tokens.

The protocols on the receiving end of the flash mints will need to ensure their contracts can handle this. One obvious way is to leverage OpenZeppelin's SafeMath libraries as a catch-all safety net, however consideration should be given to when it is or isn't used given the gas tradeoffs.

If you recall there was a series of incidents in 2018 where exchanges such as OKEx, Poloniex, HitBTC and Huobi had to shutdown deposits and withdrawls of ERC20 tokens due to integer overflows within the ERC20 token contracts.

Flash minting internal security considerations

The coupling of flash minting with business specific features in the same platform can easily lead to unintended consequences.

Example - Treasury draining

In early implementations of the Yield Protocol flash loaned fyDai could be redeemed for Dai, which could be used to liquidate the Yield Protocol CDP vault in MakerDAO:

1. Flash mint a very large amount of fyDai.
2. Redeem for Dai as much fyDai as the Yield Protocol collateral would allow.
3. Trigger a stability rate increase with a call to jug.drip which would make the Yield Protocol uncollateralized.
4. Liquidate the Yield Protocol CDP vault in MakerDAO.

Copyright

Copyright and related rights waived via CC0.