diff --git a/04.md b/04.md
index 9b7ffd2..eb9da39 100644
--- a/04.md
+++ b/04.md
@@ -55,6 +55,10 @@ Later, once `LN SERVICE` receives a call at the specified `LNURL-auth` handler,
 
 However, the second goal is not reachable in practice because there exist different formats of seeds which can't be transferred across all existing wallets. As such, a practical approach is to have recommended ways to derive `linkingKey` for different wallet types.
 
+Please refer to the following LUDs for more details:  
+[LUD-05](05.md): BIP32-based seed generation for auth protocol.  
+[LUD-13](13.md): signMessage-based seed generation for auth protocol. 
+
 
 ## Signature check examples
 
diff --git a/13.md b/13.md
index 86b0993..8a2bd58 100644
--- a/13.md
+++ b/13.md
@@ -16,8 +16,31 @@ Here we define a canonical phrase to be signed, and from that we will derive the
 In this case neither `hashingKey` nor domain-specific `linkingKey`s can be derived by the path. To overcome this limitation a different scheme is used for this class of wallets:
 
 1. The following canonical phrase is defined: `DO NOT EVER SIGN THIS TEXT WITH YOUR PRIVATE KEYS! IT IS ONLY USED FOR DERIVATION OF LNURL-AUTH HASHING-KEY, DISCLOSING ITS SIGNATURE WILL COMPROMISE YOUR LNURL-AUTH IDENTITY AND MAY LEAD TO LOSS OF FUNDS!`.
-2. `LN WALLET` obtains an `RFC6979` deterministic signature of `sha256(utf8ToBytes(canonical phrase))` using `secp256k1` with node private key.
-3. `LN WALLET` defines `hashingKey` as `PrivateKey(sha256(obtained signature))`.
-4. `SERVICE` domain name is extracted from auth `LNURL` and then service-specific `linkingPrivKey` is defined as `PrivateKey(hmacSha256(hashingKey, service domain name))`.
+2. `LN WALLET` obtains an `RFC6979` deterministic signature of `sha256(sha256(utf8ToBytes(canonical phrase)))` using `secp256k1` with node private key.
+3. `LN WALLET` defines `hashingKey` as `sha256(obtained signature)`.
+4. `SERVICE` domain name is extracted from auth `LNURL` and then service-specific `linkingPrivKey` is defined as `hmacSha256(hashingKey, utf8ToBytes(service domain name))`.
 
 `LN WALLET` must make sure it is not possible to accidentally or automatically sign and hand out a signature of canonical phrase.
+
+### Example
+To simplify the implementation, here is an example with all relevant intermediate steps, starting with the signed canonical phrase (Step 3 of this document):
+
+**k1:**  
+a7830ce0d70e447ff888a72253cb3b564d52362a0aba25c9bd74c36f54d5431e  
+**domain:**  
+lightninglogin.live  
+**obtained signature (of canonical phrase):**  
+d99tpq15iyafmpsi5s4a43dmbwknprjb9i378xj4acki7akefzwk6ygoefjqqy7xck6njam5shcrgzh697wjhsaxjko7b9wkto4juezw
+
+**hashingKey:**  
+0bdf5689da0db751c3f93366093f55a007c814f352e1f8f2a128c864e6f7fa41  
+**linkingPrivKey:**  
+9628eaef95f5c72fc4bcbfc1d3fe46805484aa1ee0d9cc219d342ef1ee926b47
+
+And further steps described in Lud 4:  
+**linkingKey:**  
+026c29c00976a94dc59f8ee33b12709d549e9d6ddc58744cdfcf7eda5af18da853  
+**signed_K1:**  
+bf7eda76a3d2028a377f9f39197f715052053c17262d8f58cb1617aeacf414e603934d6e89937a82bf93ad20d3d16d94555ff87fae07ef5dbac2da3d6eaf3375  
+**signed_K1_DER_encoded:**  
+3045022100bf7eda76a3d2028a377f9f39197f715052053c17262d8f58cb1617aeacf414e6022003934d6e89937a82bf93ad20d3d16d94555ff87fae07ef5dbac2da3d6eaf3375