diff --git a/04.md b/04.md
index 133fbf5..6a362ad 100644
--- a/04.md
+++ b/04.md
@@ -32,7 +32,7 @@ Later, once `LN SERVICE` receives a call at the specified `LNURL-auth` handler,
     - `k1` (hex encoded 32 bytes of challenge) which is going to be signed by user's `linkingPrivKey`.
     - optional `action` enum which can be one of four strings: `register | login | link | auth`.
 2. `LN WALLET` displays a "Login" dialog which must include a domain name extracted from `LNURL` query string and `action` enum translated into human readable text if `action` query parameter was present.
-3. Once accepted by user, `LN WALLET` signs `k1` on `secp256k1` using `linkingPrivKey` and DER-encodes the signature. `LN WALLET` Then issues a GET to `LN SERVICE` using `<LNURL_hostname_and_path>?<LNURL_existing_query_parameters>&sig=<hex(sign(hexToBytes(k1), linkingPrivKey))>&key=<hex(linkingKey)>`
+3. Once accepted by user, `LN WALLET` signs `k1` on `secp256k1` using `linkingPrivKey` and DER-encodes the signature. `LN WALLET` Then issues a GET to `LN SERVICE` using `<LNURL_hostname_and_path>?<LNURL_existing_query_parameters>&sig=<hex(sign(hexToBytes(k1), linkingPrivKey))>&key=<hex(linkingKey)>`. Optionally, `LN_WALLET` can append `&wallet=<LN_WALLET>` to inform `LN_SERVICE` of the wallet used to authenticate. This may be used by `LN_SERVICE` to show the user which wallets they have connected to it.
 4. `LN SERVICE` responds with the following JSON once client signature is verified:
     ```JSON
     {"status": "OK"}