ERC3156 - Flash Loans

[alcueca]

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.

The aim of this ERC is to provide a standard interfaces and processes for flash lenders and borrowers, allowing for flash loan integration without a need to consider each particular implementation.

[lightclient]

The simple summary should generally one sentence with no motivation.

[alcueca]

Please check again, thanks.

[lightclient]

The abstract should be a technical overview of the EIP. I don't recommend it for an ERC.

[alcueca]

Please check again, thanks.

[MickdeGraaf]

Standardizing flashloans would be great! One thing this proposal does not take into accounts is contracts which hold multiple assets like PieDAO pies. I propose to add an extra param to the flashloan function to signal which asset the receiver is expecting like this:

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

Flash minting an asset could be done by passing the address of the contract itself to the asset param.

I've did a POC implementation a while back and the interface looks pretty much the same:

https://github.com/pie-dao/ExperiPie/blob/feature/flash-loans/contracts/facets/FlashLoan/FlashLoanFacet.sol
https://github.com/pie-dao/ExperiPie/blob/feature/flash-loans/contracts/facets/FlashLoan/FlashLoanMint.sol

[fubuloubu]

Standardizing flashloans would be great! One thing this proposal does not take into accounts is contracts which hold multiple assets like PieDAO pies.

@MickdeGraaf would it be possible to use the data parameter for this type of interaction? Why would adding an asset field be generally useful, or avoid an extra security assumption?

[MickdeGraaf]

Standardizing flashloans would be great! One thing this proposal does not take into accounts is contracts which hold multiple assets like PieDAO pies.

@MickdeGraaf would it be possible to use the data parameter for this type of interaction? Why would adding an asset field be generally useful, or avoid an extra security assumption?

Not using the data parameter would avoid some confusion for implementers because they don't have to make an distinction between multi and single asset contracts but I guess it would work.

In most circumstances I would expect the data to only be actually used by flashLoanBorrower and not the lender itself.

Additionally it would be nice to have some getters allowing me to get a quote from a contract on how much fee I would have to pay and if there is sufficient liquidity for my flashloan.

[fubuloubu]

Not using the data parameter would avoid some confusion for implementers because they don't have to make an distinction between multi and single asset contracts but I guess it would work.

In most circumstances I would expect the data to only be actually used by flashLoanBorrower and not the lender itself.

So, the intent of the data field was the facilitate more complex interactions with flash loan borrowing, and be flexible enough to support innovative use cases like yours where the intention is not generic enough to be useful for others.

---

Additionally it would be nice to have some getters allowing me to get a quote from a contract on how much fee I would have to pay and if there is sufficient liquidity for my flashloan.

This is a great idea!

[MickdeGraaf]

So, the intent of the data field was the facilitate more complex interactions with flash loan borrowing, and be flexible enough to support innovative use cases like yours where the intention is not generic enough to be useful for others.

Makes sense. I do think however that a very large portion of contracts is a token itself which holds one or more other tokens. In these cases the asset param would be a welcome addition imo.

[alcueca]

Hi @MickdeGraaf, thanks a lot for your suggestion.

I think that for projects that hold and lend multiple assets an architecture like Uniswap would work with proposed standard. In Uniswap you go to a given Pair to exchange two tokens. Using this standard you would go to a given FlashLender (possibly built with a factory) to obtain a flash loan of a given token. You could have multiple receivers, or use the data parameter.

I don't dislike your suggestion, but I think there is value in simpler interfaces as long as we are not significantly limited by them.

[fubuloubu]

@albertocuestacanada @MickdeGraaf please migrate your conversation to https://ethereum-magicians.org/t/flash-loan-eip-erc-3156-early-draft/4993