This ERC provides standard interfaces and processes for single-asset flash loans.
A flash loan is a smart contract transaction in which a lender smart contract lends assets to a borrower smart contract with the condition that the assets are returned, plus an optional fee, before the end of the transaction. This ERC specifies interfaces for lenders to accept flash loan requests, and for borrowers to take temporary control of the transaction within the lender execution. The process for the safe execution of flash loans is also specified.
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 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 differences in the approaches across the protocols include:
A flash lending feature integrates two smart contracts using a callback pattern. These are called the LENDER and the RECEIVER in this EIP.
A lender MUST implement the IERC3156FlashLender interface.
The maxFlashLoan function MUST return the maximum loan possible for token. If a token is not currently supported maxFlashLoan 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.
The flashLoan function MUST transfer amount of token to receiver before the callback to the receiver.
The flashLoan function MUST include msg.sender as the initiator to onFlashLoan.
The flashLoan function MUST NOT modify the token, amount and data parameter received, and MUST pass them on to onFlashLoan.
The flashLoan function MUST include a fee argument to onFlashLoan with the fee to pay for the loan on top of the principal, ensuring that fee == flashFee(token, amount).
The lender MUST verify that the onFlashLoan callback returns the keccak256 hash of "ERC3156FlashBorrower.onFlashLoan".
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.
A receiver of flash loans MUST implement the IERC3156FlashBorrower interface:
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 "ERC3156FlashBorrower.onFlashLoan".
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 lent 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 all provide flash loans of several token types from the same contract. 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 initiator will often be required in the onFlashLoan function, which the lender knows as msg.sender. An alternative implementation which would embed the initiator 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.
No backwards compatibility issues identified.
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.
initiator, 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.initiator, 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.data is genuine, in addition to the check in point 1, it is recommended to verify that the initiator belongs to a group of trusted addresses. Trusting the lender and the initiator is enough to trust that the contents of data are genuine.The safest approach is to implement an approval for amount+fee before the flashLoan is executed.
Any receiver that keeps an approval for a given lender needs to include in onFlashLoan a mechanism to verify that the initiator is trusted.
Any receiver that includes in onFlashLoan the approval for the lender to take the amount + fee needs to be combined with a mechanism to verify that the initiator is trusted.
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 an initiator 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".
The typical quantum of tokens involved in flash mint transactions will give rise to new innovative attack vectors.
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
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.
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, either by using a compiler that embeds overflow protection in the smart contract bytecode, or by setting explicit checks.
The coupling of flash minting with business specific features in the same platform can easily lead to unintended consequences.
Assume a smart contract that flash lends its native token. The same smart contract borrows from a third party when users burn the native token. This pattern would be used to aggregate in the smart contract the collateralized debt of several users into a single account in the third party. The flash mint could be used to cause the lender to borrow to its limit, and then pushing interest rates in the underlying lender, liquidate the flash lender:
lender a very large amount of FOO.lender to borrow from underwriter all the way to its borrowing limit.underwriter, making lender undercollateralized.lender for profit.Copyright and related rights waived via CC0.