Clarify specification

ERCS/erc-5564.md

@@ -1,14 +1,15 @@
 ---
 eip: 5564
 title: Stealth Addresses
-description: Private, non-interactive transfers and interactions
+description: Private, non-interactive transfers and engagements
 author: Toni Wahrstätter (@nerolation), Matt Solomon (@mds1), Ben DiFrancesco (@apbendi), Vitalik Buterin (@vbuterin)
 discussions-to: https://ethereum-magicians.org/t/eip-5566-stealth-addresses-for-smart-contract-wallets/10614
 status: Last Call
-last-call-deadline: 2024-03-31
+last-call-deadline: 2024-04-23
 type: Standards Track
 category: ERC
 created: 2022-08-13
+requires: 6538
 ---
 
 ## Abstract
@@ -88,17 +89,15 @@ function computeStealthKey(
 
 The implementation of these methods is scheme-specific. The specification of a new stealth address scheme MUST specify the implementation for each of these methods. Additionally, although these function interfaces are specified in Solidity, they do not necessarily ever need to be implemented in Solidity, but any library or SDK conforming to this specification MUST implement these methods with compatible function interfaces.
 
-A 256 bit integer (`schemeId`) is used to identify stealth address schemes. A mapping from the schemeId to its specification MUST be declared in the ERC that proposes to standardize a new stealth address scheme. It is RECOMMENDED  that `schemeId`s are chosen to be monotonically incrementing integers for simplicity, but arbitrary or meaningful `schemeId`s  may be chosen. Furthermore, the schemeId MUST be added to [this overview](../assets/eip-5564/scheme_ids.md). These extensions MUST specify:
+A 256 bit integer (`schemeId`) is used to identify stealth address schemes. A mapping from the schemeId to its specification MUST be declared in the ERC that proposes to standardize a new stealth address scheme. It is RECOMMENDED  that `schemeId`s are chosen to be monotonically incrementing integers for simplicity, but arbitrary or meaningful `schemeId`s  may be chosen. This ERC introduces schemeId `1` with the following extensions:
 
-- The integer identifier for the scheme.
+- `1` is the integer identifier for the scheme, 
+
+- `viewTags` MUST be included in the announcement event and is used to reduce the parsing time for the recipients. 
 
-- The algorithm for encoding a stealth meta-address (i.e. the spending public key and viewing public key) into a `bytes` array, and decoding it from `bytes` to the native key types of that scheme.
-
-- The algorithm for the `generateStealthAddress` method.
-
-- The algorithm for the `checkStealthAddress` method.
-
-- The algorithm for the `computeStealthKey` method.
+- SECP256k1 is the algorithm for encoding a stealth meta-address (i.e. the spending public key and viewing public key) into a `bytes` array, and decoding it from `bytes` to the native key types of that scheme. 
+- 
+- SECP256k1 with view tags will be used in `generateStealthAddress`, `checkStealthAddress`, and `computeStealthKey` methods.
 
 This specification additionally defines a singleton `ERC5564Announcer` contract that emits events to announce when something is sent to a stealth address. This MUST be a singleton contract, with one instance per chain. The contract is specified as follows:
 
@@ -253,7 +252,7 @@ The stealth address specification standardizes a protocol for generating and loc
 
 The authors recognize the trade-off between on- and off-chain efficiency. Although incorporating a Monero-like view tags mechanism enables recipients to parse announcements more efficiently, it adds complexity to the announcement event.
 
-The recipient's address and the `viewTag` MUST be included in the announcement event, allowing users to quickly verify ownership without querying the chain for positive account balances.
+The recipient's address and the `viewTag` must be included in the announcement event, allowing users to quickly verify ownership without querying the chain for positive account balances.
 
 ## Backwards Compatibility