Update ERC-7540: Fix event names (#670)

* Update ERC-7540: Fix event names

* undo lint

* fixes

* fixes

ERCS/erc-7540.md

@@ -52,7 +52,7 @@ All ERC-7540 asynchronous tokenized Vaults MUST implement ERC-4626 with override
 
 Asynchronous deposit Vaults MUST override the ERC-4626 specification as follows:
 
-1. The `deposit` and `mint` methods do not transfer  `assets` to the Vault, because this already happened on `requestDeposit`.
+1. The `deposit` and `mint` methods do not transfer `assets` to the Vault, because this already happened on `requestDeposit`.
 2. `previewDeposit` and `previewMint` MUST revert for all callers and inputs.
 
 Asynchronous redeem Vaults MUST override the ERC-4626 specification as follows:
@@ -69,11 +69,11 @@ After submission, Requests go through Pending, Claimable, and Claimed stages. An
 |-------------|---------------------------------|-----------|
 | Pending     | `requestDeposit(assets, controller, owner)` | `asset.transferFrom(owner, vault, assets)`; `pendingDepositRequest[controller] += assets` |
 | Claimable   |                                 | *Internal Request fulfillment*:  `pendingDepositRequest[controller] -= assets`; `claimableDepositRequest[controller] += assets` |
-| Claimed     | `deposit(assets, receiver)`      | `claimableDepositRequest[controller] -= assets`; `vault.balanceOf[receiver] += shares` |
+| Claimed     | `deposit(assets, receiver, controller)` | `claimableDepositRequest[controller] -= assets`; `vault.balanceOf[receiver] += shares` |
 
 Note that `maxDeposit` increases and decreases in sync with `claimableDepositRequest`.
 
-Requests MUST NOT skip or otherwise short-circuit the Claim state. In other words, to initiate and claim a Request, a user MUST call both request* and the corresponding claim* function separately, even in the same block. Vaults MUST NOT "push" tokens onto the user after a Request, users MUST "pull" the tokens via the Claim function.
+Requests MUST NOT skip or otherwise short-circuit the Claim state. In other words, to initiate and claim a Request, a user MUST call both request* and the corresponding Claim function separately, even in the same block. Vaults MUST NOT "push" tokens onto the user after a Request, users MUST "pull" the tokens via the Claim function.
 
 For asynchronous Vaults, the exchange rate between `shares` and `assets` including fees and yield is up to the Vault implementation. In other words, pending redemption Requests MAY NOT be yield-bearing and MAY NOT have a fixed exchange rate.
 
@@ -108,7 +108,7 @@ MUST revert if all of `assets` cannot be requested for `deposit`/`mint` (due to
 
 Note that most implementations will require pre-approval of the Vault with the Vault's underlying `asset` token.
 
-MUST emit the `RequestDeposit` event.
+MUST emit the `DepositRequest` event.
 
 ```yaml
 - name: requestDeposit
@@ -197,7 +197,7 @@ The `assets` that will be received on `redeem` or `withdraw` MAY NOT be equivale
 
 MUST revert if all of `shares` cannot be requested for `redeem` / `withdraw` (due to withdrawal limit being reached, slippage, the owner not having enough shares, etc).
 
-MUST emit the `RequestRedeem` event.
+MUST emit the `RedeemRequest` event.
 
 ```yaml
 - name: requestRedeem
@@ -562,4 +562,4 @@ Any user approving an operator must trust that operator with both the `asset` an
 
 ## Copyright
 
-Copyright and related rights waived via [CC0](../LICENSE.md).
+Copyright and related rights waived via [CC0](../LICENSE.md).