This ERC provides standard interfaces and processes for multiple-asset flash loans.
Flash loans of multiple assets, or batch flash loans, are a common offering of flash lenders, and have a strong use case in the simultaneous refinance of several positions between platforms. At the same time, batch flash loans are more complicated to use than single asset flash loans (ER3156). This divergence of use cases and user profiles calls for independent, but consistent, standards for single asset flash loans and batch flash loans.
A batch 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 IERC3234BatchFlashLender interface.
The maxFlashLoan function MUST return the maximum loan possible for each token. If a token is not currently supported maxFlashLoan MUST return 0, instead of reverting.
The flashFee function MUST return the fees charged for each loan of amount token. If a token is not supported flashFee MUST revert.
The batchFlashLoan function MUST include a callback to the onBatchFlashLoan function in a IERC3234BatchFlashBorrower contract.
The batchFlashLoan function MUST transfer amounts[i] of each tokens[i] to receiver before the callback to the borrower.
The batchFlashLoan function MUST include msg.sender as the initiator to onBatchFlashLoan.
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 the keccak256 hash of "ERC3234BatchFlashBorrower.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]).
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 true.
A receiver of flash loans MUST implement the IERC3234BatchFlashBorrower interface:
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 the keccak256 hash of "ERC3156BatchFlashBorrower.onBatchFlashLoan".
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.
batchFlashLoan 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 batchFlashLoan and onBatchFlashLoan 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 batchFlashLoan standard.
onBatchFlashLoan 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.
An initiator will often be required in the onBatchFlashLoan 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 amounts will be required in the onBatchFlashLoan function, which the lender took as a parameter. An alternative implementation which would embed the amounts in the data parameter by the caller would require an additional mechanism for the receiver to verify its accuracy, and is not advisable.
The fees will often be calculated in the batchFlashLoan function, which the receiver must be aware of for repayment. Passing the fees 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.
The arguments of onBatchFlashLoan 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, tokens and amounts refer to a past transaction that might not have happened if the caller of onBatchFlashLoan decides to lie. fees might be false or calculated incorrectly. data might have been manipulated by the caller.initiator, tokens, amounts and fees are genuine a reasonable pattern is to verify that the onBatchFlashLoan caller is in a whitelist of verified flash lenders. Since often the caller of batchFlashLoan will also be receiving the onBatchFlashLoan callback this will be trivial. In all other cases flash lenders will need to be approved if the arguments in onBatchFlashLoan are to be trusted.data is genuine, in addition to the check in point 1, it is recommended that the receiver verifies that the initiator is in some list 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 batchFlashLoan is executed.
Including in onBatchFlashLoan 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 onBatchFlashLoan, 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 batchFlashLoan 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 onBatchFlashLoan doesn't return the keccak256 hash for "ERC3156FlashBorrower.onBatchFlashLoan".
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. 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.
The coupling of flash minting with business specific features in the same platform can easily lead to unintended consequences.
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:
jug.drip which would make the Yield Protocol uncollateralized.Copyright and related rights waived via CC0.