diff --git a/CIP-0015/CIP-0015.md b/CIP-0015/CIP-0015.md
index acf6e070e0..282e9d8ca6 100644
--- a/CIP-0015/CIP-0015.md
+++ b/CIP-0015/CIP-0015.md
@@ -33,29 +33,55 @@ A voting key is simply an ED25519 key. How this key is created is up to the wall
 
 ### Associating stake with a voting key
 
+This method has been used since Fund 2.
+For future fund iterations, a new method making use of time-lock scripts may
+be introduced as described [below][future-development].
+
 Recall: Cardano uses the UTXO model so to completely associate a wallet's balance with a voting key (i.e. including enterprise addresses), we would need to associate every payment key to a voting key individually. Although there are attempts at this (see [CIP8](../CIP-0008/CIP-0008.md)), the resulting data structure is a little excessive for on-chain metadata (which we want to keep small)
 
 Given the above, we choose to only associate staking keys with voting keys. Since most Cardano wallets only use base addresses for Shelley wallet types, in most cases this should perfectly match the user's wallet.
 
 ### Registration metadata format
 
-A Catalyst registration transaction are a regular Cardano transaction with a specific transaction metadata associated with it
+A Catalyst registration transaction is a regular Cardano transaction with a specific transaction metadata associated with it.
 
-Notably, there should be three entries inside the metadata map:
+Notably, there should be four entries inside the metadata map:
 
-Voting key registration
+Voting registration example:
 ```
 61284: {
   // voting_key - CBOR byte array
   1: "0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663",
   // stake_pub - CBOR byte array
   2: "0xad4b948699193634a39dd56f779a2951a24779ad52aa7916f6912b8ec4702cee",
-  // address - CBOR byte array
-  3: "0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee47b60edc7772855324c85033c638364214cbfc6627889f81c4"
+  // reward_address - CBOR byte array
+  3: "0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee47b60edc7772855324c85033c638364214cbfc6627889f81c4",
+  // slot_number
+  4: 5479467
 }
 ```
 
-Signing the voting public key with the staking private key
+The entries under keys 1, 2, 3, and 4 represent the Catalyst voting key,
+the staking key on the Cardano network, the address to receive rewards,
+and the current slot number, respectively. A registration with these metadata
+will be considered valid if the following conditions hold:
+
+- The slot number of the block including this transaction is equal to
+  the slot number value under key 4 or its increment by one.
+- The reward address is a Shelley address discriminated for the same network
+  this transaction is submitted to.
+
+To produce the signature field, the CBOR representation of a map containing
+a single entry with key 61284 and the registration metadata map in the
+format above is formed, designated here as `sign_data`.
+This data is signed with the staking key using one of the two methods,
+discriminated by the key number in the signature metadata map:
+
+1: `sign_data` is signed as is using Ed25519.
+
+2: The blake2b-256 hash of `sign_data` is signed using Ed25519.
+
+Signature example:
 ```
 61285: {
   // signature - ED25119 signature CBOR byte array
@@ -63,27 +89,32 @@ Signing the voting public key with the staking private key
 }
 ```
 
-This corresponds to the following CDDL definition
+### Metadata schema
+
+The format above can be described by the following CDDL definition:
 
 ```
 registration_cbor = {
-  61284: key_registration
-, 61285: registration_signature
+  61284: key_registration,
+  61285: registration_signature
 }
 
 $voting_pub_key /= bytes .size 32
 $staking_pub_key /= bytes .size 32
 $ed25519_signature /= bytes .size 64
-$address /= bytes
+$reward_address /= bytes
+$slot_number /= uint
 
 key_registration = {
-  1 : $voting_pub_key
-, 2 : $staking_pub_key
-, 3 : $address
+  1 : $voting_pub_key,
+  2 : $staking_pub_key,
+  3 : $reward_address,
+  4 : $slot_number,
 }
 
 registration_signature = {
-  1 : $ed25519_signature
+  1 : $ed25519_signature //
+  2 : $ed25519_signature
 }
 ```
 
@@ -93,17 +124,30 @@ Here an example using CBOR diagnostic notation
 {
   61284: {
     1: h'8253C95609BC62C0443276FE2A1872B87CB11C06185FFDBB56C7CE8352EEF2A3',
-    2: h'345080C6DDFF7154B4ED4A622558AA0EAABD8CE7E2701C92B6858EA76DCECBCE'
+    2: h'AD4B948699193634A39DD56F779A2951A24779AD52AA7916F6912B8EC4702CEE',
+    3: h'00588E8E1D18CBA576A4D35758069FE94E53F638B6FAF7C07B8ABD2BC5C5CDEE47B60EDC7772855324C85033C638364214CBFC6627889F81C4',
+    4: 5479467
   },
-  61285: {
-    1: h'7D88F34D778B7A4C76AA53FF5D9506DC5B92D25575B43AF75D66DC05082A2BCFF44FCEDDAB15DBA0C23C56A09A15367A9803E24A388AAFB8498EF72190407B0D'
-  }
 }
 ```
 
+### Future development
+
+[future-development]: #future-development
+
+A future change of the Catalyst system may make use of a time-lock script to commit ADA on the mainnet for the duration of a voting period. The voter registration metadata in this method will not need an association
+with the staking key. Therefore, the `staking_pub_key` map entry
+and the `registration_signature` payload with key 61285 will no longer
+be required.
+
 ## Changelog
 
-Fund 3 added the `address` inside the `key_registration` field.
+Fund 3 added the `reward_address` inside the `key_registration` field.
+
+Fund 4 added the `slot_number` field to prevent replay attacks.
+
+It was planned that since Fund 4, `registration_signature` and the `staking_pub_key` entry inside the `key_registration` field will be deprecated.
+This has been deferred to a future revision of the protocol.
 
 ## Copyright