diff --git a/docs/building-a-node-with-ldk/setting-up-a-channel-manager.md b/docs/building-a-node-with-ldk/setting-up-a-channel-manager.md
index 0a5580093..e2b9e34eb 100644
--- a/docs/building-a-node-with-ldk/setting-up-a-channel-manager.md
+++ b/docs/building-a-node-with-ldk/setting-up-a-channel-manager.md
@@ -937,6 +937,8 @@ There are 2 main options for synchronizing to chain on startup:
 
 #### Full Blocks or BIP 157/158 (Compact Block Filters)
 
+You can use LDK's [lightning-block-sync](https://docs.rs/lightning-block-sync/*/lightning_block_sync/) crate. This provides utilities for syncing LDK via a block-based interface.
+
 **Example:**
 
 <CodeSwitcher :languages="{rust:'Rust'}">
@@ -1014,18 +1016,13 @@ chain_tip = Some(
 
 </CodeSwitcher>
 
-**Implementation notes:**
+::: tip Full block syncing in mobile environments
 
-If you are connecting full blocks or using BIP 157/158, then it is recommended to use
-LDK's [`lightning_block_sync`](https://docs.rs/lightning-block-sync/*/lightning_block_sync/) crate as in the example above: the high-level steps that must be done for both `ChannelManager` and each `ChannelMonitor` are as follows:
+Block syncing for mobile clients tends to present several challenges due to resource contraints and network limitiations typically associated with mobile devices. It requires a full node and usually fetches blocks over RPC.
 
-1. Get the last blockhash that each object saw.
-   - Receive the latest block hash when through [deserializtion](https://docs.rs/lightning/*/lightning/ln/channelmanager/struct.ChannelManagerReadArgs.html) of the `ChannelManager` via `read()`
-   - Each `ChannelMonitor`'s is in `channel_manager.channel_monitors`, as the 2nd element in each tuple
-2. For each object, if its latest known blockhash has been reorged out of the chain, then disconnect blocks using `channel_manager.as_Listen().block_disconnected(..)` or `channel_monitor.block_disconnected(..)` until you reach the last common ancestor with the main chain.
-3. For each object, reconnect blocks starting from the common ancestor until it gets to your best known chain tip using `channel_manager.as_Listen().block_connected(..)` and/or `channel_monitor.block_connected(..)`.
-4. Call `channel_manager.chain_sync_completed(..)` to complete the initial sync process.
+Compact block filters (CBFs) are an alternative approach to syncing the blockchain that addresses some of the challenges associated with mobile clients. Please start a [discussion](https://github.com/orgs/lightningdevkit/discussions) if you would like us to expose `lightning-block-sync` in our bindings. 
 
+:::
 
 #### Electrum or Esplora
 
@@ -1076,6 +1073,9 @@ tx_sync.sync(confirmables).unwrap();
 <template v-slot:kotlin>
 
 ```java
+// Note: This example calls the Confirm interface directly. The lightning-transaction-sync crate will 
+// be available in the next bindings release.
+
 // Retrieve transaction IDs to check the chain for un-confirmation.
 val relevantTxIdsFromChannelManager: Array<ByteArray> = channelManager .as_Confirm().get_relevant_txids()
 val relevantTxIdsFromChannelManager: Array<ByteArray> = chainMonitor.as_Confirm().get_relevant_txids()
@@ -1121,6 +1121,9 @@ channelManagerConstructor.chain_sync_completed(customEventHandler);
   <template v-slot:swift>
 
 ```Swift
+// Note: This example calls the Confirm interface directly. The lightning-transaction-sync crate will 
+// be available in the next bindings release.
+
 // Retrieve transaction IDs to check the chain for un-confirmation.
 let relevantTxIds1 = channelManager?.asConfirm().getRelevantTxids() ?? []
 let relevantTxIds2 = chainMonitor?.asConfirm().getRelevantTxids() ?? []