ERC-3156: Flash Loans

ERCs
22

Hey @albertocuestacanada, great work with EIP-3156.

I was reading the standard, and I stopped at the “Flash lending security considerations” section. I wonder why does it mention an EOA in this context?

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 …

It is true that the EVM does not revert on calls made to EOAs, but high-level Solidity does. In particular, your reference implementation FlashLender.sol does:

receiver.onFlashLoan(msg.sender, token, amount, _fee, data) == CALLBACK_SUCCESS,

Where receiver is a function param of type IERC3156FlashBorrower.

Therefore, the approval vulnerability only applies to an EOA if the lender contracts uses a vanilla address type, and performs a low-level call to receiver. But this should not be the case in the vast majority of EIP-3156 implementations.

Do you think that it would be worth it to add a note about this in the standard?

23

Hi while reading through EIP ERC3156 flash loan implementation.
is it advisable to use reentrance guard for the flash loan function within the contract implementing the “flash lender” interface?? since the flash loan function is pulling the funds as suggested to use this logic “IERC20(token).safeTransferFrom(address(receiver), address(this), amount + fee);”.
even if the “receiver” contract callback within the “onFlashloan.” to take more loan though the transaction should revert if the “REENTER” amount was not repaid but the first initial loan was repaid. since there are two race window “flash loan” that must be repaid. or is it possible this could still be bypassed??
A blog suggested using “noonReentrant” for security purposes. but i see no reason for that

1 Like