diff --git a/CHANGELOG.md b/CHANGELOG.md
index 8cf90183a..20089cb99 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,3 +1,63 @@
+2023-02-16 v23.2.0
+==================
+
+Nimbus `v23.2.0` is a `low-urgency` upgrade providing full support for the upcoming
+Capella hard-fork. So far, the fork epoch is specified only for the Sepolia testnet
+which will execute the transition on 28th of February.
+
+### Improvements
+
+* The `deposits import` command now provides the option `--method=single-salt` which
+  will significantly improve the keystore loading speed on start-up on beacon nodes
+  and validator clients running with a very large number of validators. Please see
+  the documentation provided in the Nimbus guide in order to understand the security
+  implications of using the option:
+  https://nimbus.guide/keys.html#optimised-import-for-a-large-number-of-validators
+  https://github.com/status-im/nimbus-eth2/pull/4372
+
+* More efficient sync committee caching strategies bring 20-30% of syncing
+  speed improvement post Altair:
+  https://github.com/status-im/nimbus-eth2/pull/4592
+
+* Nimbus performs fewer interactions with the EL node during optimistic syncing
+  which further improves the syncing speed:
+  https://github.com/status-im/nimbus-eth2/pull/4591
+
+* The Keymanager API now supports all `gas_limit` end-points:
+  https://ethereum.github.io/keymanager-APIs/#/Gas%20Limit  
+  https://github.com/status-im/nimbus-eth2/pull/4612
+
+* Nimbus serves light client updates up to the retention period mandated by
+  the spec even when pruning is enabled:
+  https://github.com/status-im/nimbus-eth2/pull/4499
+
+* The Linux packages of Nimbus no longer depend on `lsb-release`:
+  https://github.com/status-im/nimbus-eth2/pull/4597
+
+* The list of bootstrap nodes for the Gnosis network has been expanded:
+  https://github.com/status-im/nimbus-eth2/pull/4603
+
+* Nimbus now performs fewer `forkchoiceUpdated` Engine API calls with lower risk
+  of reporting conflicting data to the EL node:
+  https://github.com/status-im/nimbus-eth2/pull/4609
+  https://github.com/status-im/nimbus-eth2/pull/4614
+  https://github.com/status-im/nimbus-eth2/pull/4623
+
+### Fixes
+
+* Nimbus will no longer suffer from performance issues when a large number of
+  non-active validators are imported in the beacon node or the validator client:
+  https://github.com/status-im/nimbus-eth2/pull/4590
+
+* Nimbus will no longer crash when it fails to resolve the hostname of a remote
+  validator imported through the Keymanager API:
+  https://github.com/status-im/nimbus-eth2/pull/4590
+
+* The Nimbus validator client won't attempt to perform sync committee duties when
+  the attached beacon node is only optimistically synced:
+  https://github.com/status-im/nimbus-eth2/pull/4622
+
+
 2023-01-25 v23.1.1
 ==================
 
diff --git a/beacon_chain/version.nim b/beacon_chain/version.nim
index 233f1a09c..5928f2261 100644
--- a/beacon_chain/version.nim
+++ b/beacon_chain/version.nim
@@ -17,8 +17,8 @@ when not defined(nimscript):
 
 const
   versionMajor* = 23
-  versionMinor* = 1
-  versionBuild* = 1
+  versionMinor* = 2
+  versionBuild* = 0
 
   versionBlob* = "stateofus" # Single word - ends up in the default graffiti
 
diff --git a/docs/the_nimbus_book/src/keys.md b/docs/the_nimbus_book/src/keys.md
index 947b51180..15e4a0036 100644
--- a/docs/the_nimbus_book/src/keys.md
+++ b/docs/the_nimbus_book/src/keys.md
@@ -53,6 +53,10 @@ If your `validator_keys` folder is stored elsewhere, you can pass its location t
 
 Replacing `/path/to/keys` with the full pathname of where the `validator_keys` directory is found.
 
+## Optimised import for a large number of validators
+
+If you plan to use a large number of validators (e.g. more than 100) on a single beacon node or a validator client, you might benefit from running the `deposits import` command with the option `--method=single-salt`. This will force Nimbus to use the same password and random salt value when encrypting all of the imported keystores which will later enable it to load the large number of validator keys almost instantly. The theoretical downside of using this approach is that it makes the brute-force cracking of all imported keystores computationally equivalent to cracking just one of them. Nevertheless, the security parameters used by Ethereum are such that cracking even a single keystore is considered computationally infeasible with current hardware.
+
 ## Troubleshooting
 
 If you come across an error, make sure that: