Update ERC7575

ERCS/erc-7575.md

@@ -14,13 +14,13 @@ requires: 20, 165, 2771, 4626
 
 ## Abstract
 
-The following standard adapts [ERC-4626](./eip-4626.md) to support multiple assets or entry points for the same share token.
+The following standard adapts [ERC-4626](./eip-4626.md) to support multiple assets or entry points for the same share token. This also enables Vaults which don't have a true share token but rather convert between two arbitrary external tokens.
 
-It adds a new `share` method to allow the [ERC-20](./eip-20.md) dependency to be externalized.
+It adds a new `share` method to the Vault, to allow the [ERC-20](./eip-20.md) dependency to be externalized.
 
-This also enables Vaults which don't have a true share token but rather convert between two arbitrary external tokens.
+It also adds Vault-to-Share lookup to the share token.
 
-Lastly, it enforces [ERC-165](./eip-165.md) support for Vaults.
+Lastly, it enforces [ERC-165](./eip-165.md) support for Vaults and the share token.
 
 ## Motivation
 
@@ -74,16 +74,12 @@ A Pipe MAY be either unidirectional or bidirectional.
 
 A unidirectional Pipe SHOULD implement only the entry function(s) `deposit` and/or `mint`.
 
-### [ERC-165](./eip-165.md) support
-
-Smart contracts implementing [ERC-7575](./eip-7575.md) MUST implement the [ERC-165](./eip-165.md) `supportsInterface` function.
-
-It MUST return the constant value `true` if `0x2f0a18c5` is passed through the `interfaceID` argument.
-
 ### Share-to-Vault lookup
 
 The [ERC-20](./eip-20.md) implementation of `share` SHOULD implement a `vault` method, that returns the address of the Vault for a specific `asset`.
 
+SHOULD emit the `VaultUpdate` event when a Vault linked to the share changes.
+
 ```yaml
 - name: vault
   type: function
@@ -98,19 +94,45 @@ The [ERC-20](./eip-20.md) implementation of `share` SHOULD implement a `vault` m
       type: address
 ```
 
+### [ERC-165](./eip-165.md) support
+
+Vaults implementing [ERC-7575](./eip-7575.md) MUST implement the [ERC-165](./eip-165.md) `supportsInterface` function. The Vault contract MUST return the constant value `true` if `0x2f0a18c5` is passed through the `interfaceID` argument.
+
+The share contract SHOULD implement the [ERC-165](./eip-165.md) `supportsInterface` function. The share token MUST return the constant value `true` if `0xf815c03d` is passed through the `interfaceID` argument.
+
+### Events
+
+#### VaultUpdate
+
+The Vault linked to the share has been updated.
+
+```yaml
+- name: VaultUpdate
+  type: event
+
+  inputs:
+    - name: asset
+      indexed: true
+      type: address
+    - name: vault
+      indexed: false
+      type: address
+```
+
 
 ## Rationale
 
 This standard is intentionally flexible to support both existing [ERC-4626](./eip-4626.md) Vaults easily by the introduction of a single new method, but also flexible to support new use cases by allowing separate share tokens.
 
 ### Ability to externalize [ERC-20](./eip-20.md) Dependency
+
 By allowing `share != address(this)`, the Vault can have an external contract managing the [ERC-20](./eip-20.md) functionality of the Share. In the case of Multi-Asset, this avoids the confusion that might arise if each Vault itself were required to be an [ERC-20](./eip-20.md), which could confuse integrators and front-ends.
 
 This approach also enables the creation of new types of Vaults, such as Pipes, which facilitate the conversion between two external [ERC-20](./eip-20.md) tokens. These Pipes could be unidirectional (i.e. only for assets to shares via deposit/mint, or shares to assets via redeem/withdraw) or bidirectional for both entry and exit flows.
 
 ### Including Share-to-Vault lookup optionally
 
-The `vault` method is included to look up a Vault for a `share` by its `asset`. This enables integrations to easily query Multi-Asset Vaults.
+The `vault` method is included to look up a Vault for a `share` by its `asset`, combined with the `VaultUpdate` event and [ERC-165](./eip-165.md) support. This enables integrations to easily query Multi-Asset Vaults.
 
 This is optional, to maintain backward compatibility with use cases where the `share` is an existing deployed contract.