diff --git a/rfc/0004_ws2p_v1.md b/rfc/0004_ws2p_v1.md
index 425b43705cf0175fdba91ca8f1c77c391afb2f81..49456df203d6075dff932f98f052ad9f38083ab4 100644
--- a/rfc/0004_ws2p_v1.md
+++ b/rfc/0004_ws2p_v1.md
@@ -354,6 +354,13 @@ Real example :
 
 ### HEAD Rebound policy
 
+### HEADCache
+
+The local node has a HEADCache (only in RAM), which represents its network view.  
+This cache is an associative array, the keys correspond to the pair (pubkey+guid) and the values correspond to the complete HEAD in JSON format.
+
+Note : In duniter-ts 1.6, the content of this HEADCache is provided by a BMA url in the form of a JSON array of values (without keys) : /network/ws2p/heads
+
 #### Local HEAD
 
 The local node issues a new HEAD every time the last block of its local branch changes, this change can have two causes:  
@@ -367,13 +374,13 @@ Each time the local node emits a new head, it sends it to all established ws2p c
 When the local node receives a HEAD message, it checks whether all of the following conditions are verified : 
 
 1. The head has a valid format and a valid signature  
-2. The head has a block number equal to or greater than all cached heads for the same ws2pid  
+2. The head has a block number equal to or greater than the head of the same key in the cache (hereafter referred "cached head").
 3. If the block number is equal to the cached head, the head is of a higher or equal version.  
 4. If the block number is equal to the cached head, and the version is identical, the step field is smaller.
 5. If the head pubkey is not a member, make sure there is an active ws2p connection with this pubkey.
 
 If all these conditions are respected, perform the following actions :  
-1. Save this head in the headCache, overwrite the existing head if it exists.  
+1. Save this head in the headCache, overwrite the existing head with same key.  
 2. Increment the step field of this head then send it to all established ws2p connections.
 
 ### Documents rebound policy