Hi guys, I’m drafting a Flash Loan EIP with fubuloubu, onewayfunction and hexonaut.
It’s my first, so I would appreciate some advice on language, content gaps, and anything that you might see it lacks. I don’t want to make it too big, I would like just a standard so that integrating flash loans is easier, and so that people avoid some of the pitfalls I’ve fallen into 
Also, discussion on flash loans is always fun.
This is great! Here are some comments;
This should be positioned as an “ERC” (but still would go through the EIP process).
“Simple Summary” - After the description of what flash loans are, this section needs more of a summary of the ERC itself.
“Motivation” - Links to documentation of AAVE, DxDy, Yield’s flash loan interfaces would be helpful here. Also, it could start w/ a more general description of the technical reason the interface is needed in order for a flash loan to function.
“Rationale” - This should start w/ a general rationale about why the ERC is needed w/ its general approach, etc. The rationales for each of the methods are still useful though.
Hope this helps!
@fifikobayashi added a good chunk of technical knowledge to the motivation and security consideration sections, and following that lead I filled the remaining gaps and added a couple other exploits I know of.
Does anyone have any advice on polishing the document further? I was advised to not write too much, so maybe the security considerations can be tightened somehow.
Hey guys, I’ve now opened this in the EIP repo:
Thanks!
And it’s been merged! 
Why does the receiver have to be the same person that gets the callback? What if you want to loan ETH to address X but callback to address Y?
Why not allow the caller to decide the callback and provide all of the parameters? They already can query for fee, and the amount being loaned is known to the caller in advance of the call. So you could just do receiver.call(_calldata) which would allow the caller to also decide what method was called.