diff --git a/lightningd/chaintopology.c b/lightningd/chaintopology.c
index 1449e7a0f..6e14e9048 100644
--- a/lightningd/chaintopology.c
+++ b/lightningd/chaintopology.c
@@ -1137,7 +1137,19 @@ u32 feerate_min(struct lightningd *ld, bool *unknown)
 	if (unknown)
 		*unknown = false;
 
-	/* We can't allow less than feerate_floor, since that won't relay */
+        /* We allow the user to ignore the fee limits,
+	 * although this comes with inherent risks.
+	 *
+	 * By enabling this option, users are explicitly
+	 * made aware of the potential dangers.
+	 * There are situations, such as the one described in [1],
+	 * where it becomes necessary to bypass the fee limits to resolve
+	 * issues like a stuck channel.
+	 *
+	 * BTW experimental-anchors feature provides a solution to this problem.
+	 *
+	 * [1] https://github.com/ElementsProject/lightning/issues/6362
+	 * */
 	if (ld->config.ignore_fee_limits)
 		min = 1;
 	else {
@@ -1156,10 +1168,12 @@ u32 feerate_min(struct lightningd *ld, bool *unknown)
 
 		/* FIXME: This is what bcli used to do: halve the slow feerate! */
 		min /= 2;
+
+		/* We can't allow less than feerate_floor, since that won't relay */
+		if (min < get_feerate_floor(topo))
+			return get_feerate_floor(topo);
 	}
 
-	if (min < get_feerate_floor(topo))
-		return get_feerate_floor(topo);
 	return min;
 }