Automatically merged updates to draft EIP(s) 3156 (#3236)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft, Review, or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

EIPS/eip-3156.md

@@ -11,7 +11,7 @@ created: 2020-11-15
 
 ## Simple Summary
 
-This ERC provides standard interfaces and processes for flash lenders and borrowers, allowing for flash loan integration without a need to consider each particular implementation.
+This ERC provides standard interfaces and processes for single-asset flash loans.
 
 ## Motivation
 
@@ -99,7 +99,7 @@ function flashLoan(
 
 The `flashLoan` function MUST transfer `amount` of `token` to `receiver` before the callback to the borrower.
 
-The `flashLoan` function MUST include `msg.sender` as the `sender` to `onFlashLoan`.
+The `flashLoan` function MUST include `msg.sender` as the `initiator` to `onFlashLoan`.
 
 The `flashLoan` function MUST NOT modify the `token`, `amount` and `data` parameter received, and MUST pass them on to `onFlashLoan`.
 
@@ -125,7 +125,7 @@ interface IERC3156FlashBorrower {
 
     /**
      * @dev Receive a flash loan.
-     * @param sender The initiator of the loan.
+     * @param initiator The initiator of the loan.
      * @param token The loan currency.
      * @param amount The amount of tokens lent.
      * @param fee The additional amount of tokens to repay.
@@ -133,7 +133,7 @@ interface IERC3156FlashBorrower {
      * @return The keccak256 hash of "ERC3156FlashBorrower.onFlashLoan"
      */
     function onFlashLoan(
-        address sender,
+        address initiator,
         address token,
         uint256 amount,
         uint256 fee,
@@ -164,7 +164,7 @@ A `bytes calldata data` parameter is included for the caller to pass arbitrary i
 
 `onFlashLoan` has been chosen as a function name as descriptive enough, unlikely to clash with other functions in the `receiver`, and following the `onAction` naming pattern used as well in EIP-667.
 
-A `sender` will often be required in the `onFlashLoan` function, which the lender knows as `msg.sender`. An alternative implementation which would embed the `sender` in the `data` parameter by the caller would require an additional mechanism for the receiver to verify its accuracy, and is not advisable.
+A `initiator` will often be required in the `onFlashLoan` function, which the lender knows as `msg.sender`. An alternative implementation which would embed the `initiator` in the `data` parameter by the caller would require an additional mechanism for the receiver to verify its accuracy, and is not advisable.
 
 The `amount` will be required in the `onFlashLoan` function, which the lender took as a parameter. An alternative implementation which would embed the `amount` in the `data` parameter by the caller would require an additional mechanism for the receiver to verify its accuracy, and is not advisable.
 
@@ -201,7 +201,7 @@ contract FlashBorrower is IERC3156FlashBorrower {
 
     /// @dev ERC-3156 Flash loan callback
     function onFlashLoan(
-        address sender,
+        address initiator,
         address token,
         uint256 amount,
         uint256 fee,
@@ -212,7 +212,7 @@ contract FlashBorrower is IERC3156FlashBorrower {
             "FlashBorrower: Untrusted lender"
         );
         require(
-            sender == address(this),
+            initiator == address(this),
             "FlashBorrower: Untrusted loan initiator"
         );
         (Action action) = abi.decode(data, (Action));
@@ -465,9 +465,9 @@ contract FlashLender is IERC3156FlashLender {
 
 The arguments of `onFlashLoan` are expected to reflect the conditions of the flash loan, but cannot be trusted unconditionally. They can be divided in two groups, that require different checks before they can be trusted to be genuine.
 
-0. No arguments can be assumed to be genuine without some kind of verification. `sender`, `token` and `amount` refer to a past transaction that might not have happened if the caller of `onFlashLoan` decides to lie. `fee` might be false or calculated incorrectly. `data` might have been manipulated by the caller.
-1. To trust that the value of `sender`, `token`, `amount` and `fee` are genuine a reasonable pattern is to verify that the `onFlashLoan` caller is in a whitelist of verified flash lenders. Since often the caller of `flashLoan` will also be receiving the `onFlashLoan` callback this will be trivial. In all other cases flash lenders will need to be approved if the arguments in `onFlashLoan` are to be trusted.
-2. To trust that the value of `data` is genuine, in addition to the check in point 1, it is recommended to implement the `flashLoan` caller to be also the `onFlashLoan` receiver. With this pattern, checking in `onFlashLoan` that `sender` is the current contract is enough to trust that the contents of `data` are genuine.
+0. No arguments can be assumed to be genuine without some kind of verification. `initiator`, `token` and `amount` refer to a past transaction that might not have happened if the caller of `onFlashLoan` decides to lie. `fee` might be false or calculated incorrectly. `data` might have been manipulated by the caller.
+1. To trust that the value of `initiator`, `token`, `amount` and `fee` are genuine a reasonable pattern is to verify that the `onFlashLoan` caller is in a whitelist of verified flash lenders. Since often the caller of `flashLoan` will also be receiving the `onFlashLoan` callback this will be trivial. In all other cases flash lenders will need to be approved if the arguments in `onFlashLoan` are to be trusted.
+2. To trust that the value of `data` is genuine, in addition to the check in point 1, it is recommended to verify that the `initiator` belongs to a group of trusted addresses. Trusting the `lender` and the `initiator` is enough to trust that the contents of `data` are genuine.
 
 ### Flash lending security considerations