ERC7399 - Flash Loans

ERCs
,
1

After a long while with ERC-3156 in the open, and given the lacklustre adoption, @ultrasecr.eth and I decided to replace it with a more flexible approach: ERC-7399.

ERC-7399 segregates the control and asset flows to allow more efficient flash loan wrappers and more efficient flash loans for those using a push architecture.

ERC-7399 also allows for multiple callbacks to be defined, cutting on some complexity present on all borrowers.

2

function flashLoan

You’re using the wrong verbs for the identifiers. To “loan” is to lend to someone else. The top-level call should be “borrow” not “loan”, and the callback should be “loan”. If you insist on having “loan” in the initiating call, you should change the verb to “initiate” or “begin” or something grammatically correct.

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

I don’t like that you parameterize the callback function into the ABI. It doesn’t make sense; instead the callback function should be standardized.

3

(I’m still sharing my thoughts on the grammar.)

I have used “flash” as a verb in the past to describe this exact behavior, but if flash is the operative verb we don’t need an object.

ERC20 grammer is like token.transfer(to, amount) in which

  • CALLER aka msg.sender is the subject
  • transfer is the verb
  • token is the object
4

flashLoan was used in ERC3156, so for continuity I would be keen on keep on using it. Although I agree with you on the grammar, to “flash borrow” is not a common use of the concept. “beginFlashLoan” or anything that prepends a verb is grammatically correct, but also more verbose.

5

I don’t like that you parameterize the callback function into the ABI. It doesn’t make sense; instead the callback function should be standardized.

That was my initial thought as well, but parameterizing the callback function works pretty well. It allows to have several callback flows without encoding a callback type in data, which then would need to be decoded in the callback before the flow gets routed to the appropriate function. No parameterized callbacks / Parameterized callbacks on the lender / Parameterized callbacks on the borrower.

Also, this EIP intends to segregate the control and asset flows. The callback receiver can be different from the loan receiver. The callback parameter includes both, which helps with conciseness.

1 Like
6

I don’t mind using flash, tbh. There is no other “flash” in ethereum that would lead to confusion.

1 Like
7

If you aren’t also preserving all of the parameter types, there is no compatibility benefit to preserving the function name identifier. In fact, using the same identifier can cause confusion. An example of avoiding confusion in Compound V3:

function approveThis(address manager, address asset, uint amount) override external