Should we implement the new EIP-7400 flashloan standard

[MerlinEgalite]

It would allow easy integration for Blue's flashloan by contracts aggregating flashloans

ethereum/EIPs#7400

[Rubilmax]

I personally think this EIP is way too early stage to have been properly challenged ; especially regarding their "push over pull architecture"

As a reminder and because everyone may not have seen this: the "push architecture" is not sound for all setups of flash loans and specifically unsound for Blue if we rely on balanceOf.

However, I'm ok with the feature of bubbling up arbitrary bytes of return data! #190

[MathisGD]

It would allow easy integration for Blue's flashloan by contracts aggregating flashloans

as of today no, because this EIP is just being written, and even its predecessor (EIP-3156) had a very limited adoption. So this benefits only realizes if this EIP is widely adopted, which we can't be sure of.

---

The EIP has behaviors that I think could really be challenged:
1.

The flashFee function MUST return the fee charged for a loan of amount asset. If the asset is not supported flashFee MUST revert. If the lender doesn't have enough liquidity to loan amount the fee returned must be type(uint256).max.

What is the difference between an unsupported asset and an asset with 0 liquidity ? For an architecture like Blue, it's unclear (I might ask on the EIP).

flash has been chosen as a function name as a verb which is descriptive enough, unlikely to clash with other functions in the lender, and including both the use cases in which the assets lent are held or minted by the lender.

I agree that flashBorrow seems better than flashLoan, but flash..

function(address, address, IERC20, uint256, uint256, bytes memory) external returns (bytes memory) callback

I'm not a fan of the functions as argument

---

And more importantly, these flashloans have a push architecture instead of a pull architecture:

Before the end of the callback, the asset balance of payment receiver MUST have increased by amount + fee from the amount at the beginning of the callback, or revert if this is not true.

As highlighted by @Rubilmax here, this is not compatible with Blue. I'm even wondering if this is compatible with a lot of protocols actually (I might ask on the EIP).

---

TL;DR I'm against!

P.S: it is EIP-7399, not 7400

[MerlinEgalite]

I agree that the pull architecture discard this EIP, I'm closing this issue but I think we should send a message on the PR

[MathisGD]

I already did it. My only question left is the flashLoan naming. Do we keep it like that ?

[MerlinEgalite]

I agree that flashBorrow seems better than flashLoan, but flash..

I don't get this sentence though @MathisGD

[MathisGD]

In 7399 they changed flashLoan for flash, because flashLoan is not really consistent with like borrow. So I'm wondering if we should change or name for flashBorrow for example or not.

[MerlinEgalite]

Ok I agree that flash alone is weird...

[MathisGD]

Discussion: https://morpholabs.slack.com/archives/C02N7CSP91C/p1691575318280149

[MathisGD]

Let's keep flashLoan