Title: ERC7399___Flash_Loans
Category: ERCs

Author: albertocuestacanada
Date: 2023-07-25T16:29:39.361Z

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.

Author: wjmelements
Date: 2023-07-25T17:26:17.667Z

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.

Author: wjmelements
Date: 2023-07-25T20:38:21.296Z

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



 wjmelements:

You’re using the wrong verbs for the identifiers.


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

Author: albertocuestacanada
Date: 2023-07-25T21:41:17.558Z

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.

Author: albertocuestacanada
Date: 2023-07-25T21:48:34.441Z

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.

Author: albertocuestacanada
Date: 2023-07-25T21:49:27.627Z

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

Author: wjmelements
Date: 2023-07-25T21:57:11.336Z

albertocuestacanada:

flashLoan was used in ERC3156, so for continuity I would be keen on keep on using it


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