update

Author: daro-maj

non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md

@@ -50,7 +50,7 @@ This acts as a guideline to implement network-based (remote) wallet management a
 
 #### API v1
 
-DEPRECATED: The wallet API v1 is no longer officially supported.
+DEPRECATED: The wallet API v1 is no longer officially supported. The desktop wallet not longer support sending transaction using the API v1. The CLI wallet still expose this API, but updates to the API V2 are not back ported to API V1. Once the browser wallet is officially released, the API v1 will be removed from all wallet software.
 
 - As a user, I can create a new account on the Wallet service (account creation requirement to be implementation details)  (<a name="0022-AUTH-001" href="#0022-AUTH-001">0022-AUTH-001</a>)
 - As a user, I can login to the Wallet service with my wallet name and password (<a name="0022-AUTH-002" href="#0022-AUTH-002">0022-AUTH-002</a>)

protocol/0022-AUTH-auth.md

@@ -43,7 +43,8 @@ The process of sending the first transaction for a user is as follows:
 2. Bob requests to his wallet management application a signature of a transaction by submitting the transaction and the public key of the party to use.
 3. The transaction is checked, signed, and bundled with the signature and the public key by the wallet management application.
 4. The signed transaction is then submitted to the Vega network, which verify the authenticity of the transaction and its content to ensure the transaction was signed on behalf of the correct party.
-5. If correct, the transaction is executed.
+5. The network also verifies the transaction is not an attempt to replay an old transaction.
+6. If correct, the transaction is executed.
 
 There is no prior announcement of the party required for the party to be used. As long as the party has enough resources to execute the transaction, the Vega network welcomes it.