Update ERC-7540: Update ERC7540

Merged by EIP-Bot.

ERCS/erc-7540.md

@@ -189,11 +189,11 @@ Assumes control of `shares` from `owner` and submits a Request for asynchronous
 
 The output `requestId` is used to partially discriminate the request along with the `controller`. See [Request Ids](#request-ids) section for more info.
 
-MAY support either a locking or a burning mechanism for `shares` depending on the Vault implementation. 
+`shares` MAY be temporarily locked in the Vault until the Claimable or Claimed state for accounting purposes, or they MAY be burned immediately upon `requestRedeem`. 
 
-If a Vault uses a locking mechanism for `shares`, those `shares` MUST be burned from the Vault balance before or upon claiming the Request.
+In either case, the `shares` MUST be removed from the custody of `owner` upon `requestRedeem` and burned by the time the request is Claimed.
 
-MUST support a redeem Request flow where the control of `shares` is taken from `owner` directly where `msg.sender` has ERC-20 approval over the `shares` of `owner`, or the `owner` has approved the `msg.sender` as an operator.
+Redeem Request approval of `shares` for a `msg.sender` NOT equal to `owner` may come either from ERC-20 approval over the `shares` of `owner` or if the `owner` has approved the `msg.sender` as an operator.
 
 When the Request is Claimable, `claimableRedeemRequest` will be increased for the `controller`. `redeem` or `withdraw` can subsequently be called by `controller` to receive `assets`. A Request MAY transition straight to Claimable state but MUST NOT skip the Claimable state.
 
@@ -325,10 +325,10 @@ Implementations MUST support an additional overloaded `deposit` and `mint` metho
 - `deposit(uint256 assets, address receiver, address controller)`
 - `mint(uint256 shares, address receiver, address controller)`
 
-The `controller` field is used to look up the Request for which the `assets` should be claimed.
-
 Calls MUST revert unless `msg.sender` is either equal to `controller` or an operator approved by `controller`.
 
+The `controller` field is used to discriminate the Request for which the `assets` should be claimed in the case where `msg.sender` is NOT `controller`.
+
 When the `Deposit` event is emitted, the first parameter MUST be the `controller`, and the second parameter MUST be the `receiver`.
 
 ### Events
@@ -556,6 +556,12 @@ In general, asynchronicity concerns make state transitions in the Vault much mor
 * The view methods for viewing Pending and Claimable request states (e.g. pendingDepositRequest) are estimates useful for display purposes but can be outdated. The inability to know the final exchange rate on any Request requires users to trust the implementation of the asynchronous Vault in the computation of the exchange rate and fulfillment of their Request.
 * Shares or assets locked for Requests can be stuck in the Pending state. Vaults may elect to allow for the fungibility of pending claims or implement some cancellation functionality to protect users.
 
+### Operators
+
+An operator has the ability to transfer the `asset` of the vault from the approver to any address, and simultaneously grants control over the `share` of the vault. 
+
+Any user approving an operator must trust that operator with both the `asset` and `share` of the Vault.
+
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).