EIP-3156: Flash Loans Source

Author Alberto Cuesta Cañada, Fiona Kobayashi, fubuloubu, Austin Williams https://ethereum-magicians.org/t/erc-3156-flash-loans-review-discussion/5077 Review 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 MUST implement the IERC3156FlashLender interface.

pragma solidity ^0.7.0 || ^0.8.0;
import "./IERC3156FlashBorrower.sol";

interface IERC3156FlashLender {

/**
* @dev The amount of currency available to be lended.
* @param token The loan currency.
* @return The amount of token that can be borrowed.
*/
function maxFlashAmount(
) external view returns (uint256);

/**
* @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(
uint256 amount
) external view returns (uint256);

/**
* @dev Initiate a flash loan.
* @param receiver The receiver of the tokens in the loan, and the receiver of the callback.
* @param token The loan currency.
* @param amount The amount of tokens lent.
* @param data Arbitrary data structure, intended to contain user-defined parameters.
*/
function flashLoan(
uint256 amount,
bytes calldata data
) external returns (bool);
}


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

The flashFee function MUST return the fee charged for a loan of amount token. If the token is not supported flashFee MUST revert.

The flashLoan function MUST include a callback to the onFlashLoan function in a IERC3156FlashBorrower contract.

function flashLoan(
IERC20 token,
uint256 amount,
bytes calldata data
) external returns (bool) {
...
require(
"IERC3156: Callback failed"
);
...
}


The flashLoan function MUST transfer amount of token to receiver before the callback to the borrower.

The flashLoan function MUST include msg.sender as the sender to onFlashLoan.

The flashLoan function MUST NOT modify the token, amount and data parameter received, and MUST pass them on to onFlashLoan.

The lender MUST verify that the onFlashLoan callback returns true.

After the callback, the flashLoan function MUST take the amount + fee token from the receiver, or revert if this is not successful.

If successful, flashLoan MUST return true.

The batch flash loans extension is OPTIONAL for ERC-3156 smart contracts. This allows flash loans to be composed of several ERC20 tokens.

A lender offering batch flash loans MUST implement the IERC3156BatchFlashLender interface.

interface IERC3156BatchFlashLender is IERC3156FlashLender {
function batchFlashLoan(
uint256[] amounts,
bytes calldata data
) external returns (bool);
}


The batchFlashLoan function MUST include a callback to the onBatchFlashLoan function in a IERC3156BatchFlashBorrower contract.

function batchFlashLoan(
uint256[] calldata amounts,
bytes calldata data
) external returns (bool){
...
require(
"IERC3156: Callback failed"
)
...
}


For each token in tokens, the batchFlashLoan function MUST transfer amounts[i] of tokens[i] to receiver before the callback to the borrower.

The batchFlashLoan function MUST include msg.sender as the sender to onBatchFlashLoan.

The batchFlashLoan function MUST include a fees argument to onBatchFlashLoan with the fee to pay for each individual token and amount lent, ensuring that fees[i] = flashFee(tokens[i], amounts[i]).

The batchFlashLoan function MUST NOT modify the tokens, amounts and data parameters received, and MUST pass them on to onBatchFlashLoan.

The lender MUST verify that the onBatchFlashLoan callback returns true.

After the callback, for each token in tokens, the batchFlashLoan function MUST take the amounts[i] + fees[i] of tokens[i] from the receiver, or revert if this is not successful.

If successful, batchFlashLoan MUST return the keccak256 hash of “ERC3156FlashBorrower.onFlashLoan”.

For all functions above, including both mandatory and optional sections, address(1) is used as a sentinel value for Ether. If the token parameter is address(1) then the function should be processed as defined except using Ether instead of a token.

A receiver of flash loans MUST implement the IERC3156FlashBorrower interface:

pragma solidity ^0.7.0 || ^0.8.0;

interface IERC3156FlashBorrower {

/**
* @dev Receive a flash loan.
* @param sender The initiator of the loan.
* @param token The loan currency.
* @param amount The amount of tokens lent.
* @param fee The additional amount of tokens to repay.
* @param data Arbitrary data structure, intended to contain user-defined parameters.
* @return The keccak256 hash of "ERC3156FlashBorrower.onFlashLoan"
*/
function onFlashLoan(
uint256 amount,
uint256 fee,
bytes calldata data
) external returns (bytes32);
}


For the transaction to not revert, receiver MUST approve amount + fee of token to be taken by msg.sender before the end of onFlashLoan.

If successful, onFlashLoan MUST return the keccak256 hash of “ERC3156BatchFlashBorrower.onBatchFlashLoan”.

The batch flash loans extension is OPTIONAL for ERC-3156 smart contracts. This allows flash loans to be composed of several ERC20 tokens.


interface IERC3156BatchFlashBorrower {
/**
* @dev Receive a batch flash loan.
* @param sender The initiator of the loan.
* @param tokens The loan currencies.
* @param amounts The amounts of tokens lent.
* @param fees The additional amount of tokens to repay.
* @param data Arbitrary data structure, intended to contain user-defined parameters.
* @return The keccak256 hash of "ERC3156BatchFlashBorrower.onBatchFlashLoan"
*/
function onBatchFlashLoan(
IERC3156BatchFlashLender sender,
uint256[] calldata amounts,
uint256[] calldata fees,
bytes calldata data
) external returns (bytes32);
}


For the transaction to not revert, for each token in tokens, receiver MUST approve amounts[i] + fees[i] of tokens[i] to be taken by msg.sender before the end of onBatchFlashLoan.

If successful, onBatchFlashLoan MUST return true.

For all functions above, including both mandatory and optional sections, address(1) is used as a sentinel value for Ether. If the token parameter is address(1) then the function should be processed as defined except using Ether instead of a token.

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.

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

flashLoan has been chosen as a function name 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 flexibility on the implementation of separate loan initiators and receivers.

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 flashLoan standard.

onFlashLoan has been chosen as a function name 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 flashLoan 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.

The amount + fee are pulled from the receiver to allow the lender to implement other features that depend on using transferFrom, without having to lock them for the duration of a flash loan. An alternative implementation where the repayment is transferred to the lender is also possible, but would need all other features in the lender to be also based in using transfer instead of transferFrom. Given the lower complexity and prevalence of a “pull” architecture over a “push” architecture, “pull” was chosen.

Backwards Compatibility

No backwards compatibility issues identified.

Implementation

Flash Borrower Reference Implementation

pragma solidity ^0.8.0;

import "./interfaces/IERC20.sol";
import "./interfaces/IERC3156FlashBorrower.sol";
import "./interfaces/IERC3156FlashLender.sol";

contract FlashBorrower is IERC3156FlashBorrower {
enum Action {NORMAL, OTHER}

IERC3156FlashLender lender;

constructor (
IERC3156FlashLender lender_
) {
lender = lender_;
}

/// @dev ERC-3156 Flash loan callback
function onFlashLoan(
uint256 amount,
uint256 fee,
bytes calldata data
) external override returns(bool) {
require(
"FlashBorrower: Untrusted lender"
);
require(
"FlashBorrower: Untrusted loan initiator"
);
(Action action) = abi.decode(data, (Action));
if (action == Action.NORMAL) {
// do one thing
} else if (action == Action.OTHER) {
// do another
}
return keccak256("ERC3156FlashBorrower.onFlashLoan");
}

/// @dev Initiate a flash loan
function flashBorrow(
uint256 amount
) public {
bytes memory data = abi.encode(Action.NORMAL);
uint256 _fee = lender.flashFee(token, amount);
uint256 _repayment = amount + _fee;
lender.flashLoan(this, token, amount, data);
}
}


Flash Mint Reference Implementation

pragma solidity ^0.8.0;

import "../ERC20.sol";
import "../interfaces/IERC20.sol";
import "../interfaces/IERC3156FlashBorrower.sol";
import "../interfaces/IERC3156FlashLender.sol";

/**
* @dev Extension of {ERC20} that allows flash minting.
*/
contract FlashMinter is ERC20, IERC3156FlashLender {

bytes32 public constant CALLBACK_SUCCESS = keccak256("ERC3156FlashBorrower.onFlashLoan");
uint256 public fee; //  1 == 0.0001 %.

/**
* @param fee_ The percentage of the loan amount that needs to be repaid, in addition to amount.
*/
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 maxFlashAmount(
) external view override returns (uint256) {
return type(uint256).max - totalSupply();
}

/**
* @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(
uint256 amount
) external view override returns (uint256) {
require(
"FlashMinter: Unsupported currency"
);
return _flashFee(token, amount);
}

/**
* @dev Loan amount tokens to receiver, and takes it back plus a flashFee after the ERC3156 callback.
* @param receiver The contract receiving the tokens, needs to implement the onFlashLoan(address user, 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(
uint256 amount,
bytes calldata data
) external override returns (bool){
require(
"FlashMinter: Unsupported currency"
);
uint256 fee = _flashFee(token, amount);
require(
receiver.onFlashLoan(msg.sender, token, amount, fee, data) == CALLBACK_SUCCESS,
"FlashMinter: Callback failed"
);
require(
_allowance >= (amount + fee),
"FlashMinter: Repay not approved"
);
return true;
}

/**
* @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(
uint256 amount
) internal view returns (uint256) {
return amount * fee / 10000;
}
}


Flash Loan Reference Implementation

pragma solidity ^0.8.0;

import "../interfaces/IERC20.sol";
import "../interfaces/IERC3156FlashBorrower.sol";
import "../interfaces/IERC3156FlashLender.sol";

/**
* @dev Extension of {ERC20} that allows flash lending.
*/
contract FlashLender is IERC3156FlashLender {

bytes32 public constant CALLBACK_SUCCESS = keccak256("ERC3156FlashBorrower.onFlashLoan");
uint256 public fee; //  1 == 0.0001 %.

/**
* @param supportedTokens_ Token contracts supported for flash lending.
* @param fee_ The percentage of the loan amount that needs to be repaid, in addition to amount.
*/
constructor(
uint256 fee_
) {
for (uint256 i = 0; i < supportedTokens_.length; i++) {
supportedTokens[supportedTokens_[i]] = true;
}
fee = fee_;
}

/**
* @dev Loan amount tokens to receiver, and takes it back plus a flashFee after the callback.
* @param receiver The contract receiving the tokens, needs to implement the onFlashLoan(address user, 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(
uint256 amount,
bytes calldata data
) external override returns(bool) {
require(
supportedTokens[token],
"FlashLender: Unsupported currency"
);
uint256 fee = _flashFee(token, amount);
require(
"FlashLender: Transfer failed"
);
require(
receiver.onFlashLoan(msg.sender, token, amount, fee, data) == CALLBACK_SUCCESS,
"FlashLender: Callback failed")
;
require(
"FlashLender: Repay failed"
);
return true;
}

/**
* @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(
uint256 amount
) external view override returns (uint256) {
require(
supportedTokens[token],
"FlashLender: Unsupported currency"
);
return _flashFee(token, amount);
}

/**
* @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(
uint256 amount
) internal view returns (uint256) {
return amount * fee / 10000;
}

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



Security Considerations

Verification of callback arguments

The arguments of onFlashLoan are expected to reflect the conditions of the flash loan, but cannot be trusted unconditionally. They can be divided in two groups, that require different checks before they can be trusted to be genuine.

1. No arguments can be assumed to be genuine without some kind of verification. sender, token and amount 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. data might have been manipulated by the caller.
2. To trust that the value of sender, token, amount 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.
3. 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

Automatic approvals for untrusted borrowers

The safest approach is to implement an approval for amount+fee before the flashLoan is executed.

Including in onFlashLoan the approval for the lender to take the amount + fee needs to be combined with a mechanism to verify that the borrower is trusted, such as those described above.

If an unsuspecting contract with a non-reverting fallback function, or an EOA, would approve a lender implementing ERC3156, and not immediately use the approval, and if the lender would not verify the return value of onFlashLoan, then the unsuspecting contract or EOA could be drained of funds up to their allowance or balance limit. This would be executed by a borrower calling flashLoan on the victim. The flash loan would be executed and repaid, plus any fees, which would be accumulated by the lender. For this reason, it is important that the lender implements the specification in full and reverts if onFlashLoan doesn’t return the keccak256 hash for “ERC3156FlashBorrower.onFlashLoan”.

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 and related rights waived via CC0.