diff --git a/02-peer-protocol.md b/02-peer-protocol.md
index 46feb9042..33a363321 100644
--- a/02-peer-protocol.md
+++ b/02-peer-protocol.md
@@ -806,9 +806,22 @@ is destined, is described in [BOLT #4](04-onion-routing.md).
 #### Requirements
 
 A sending node:
-  - MUST NOT offer `amount_msat` it cannot pay for in the
-remote commitment transaction at the current `feerate_per_kw` (see "Updating
-Fees") while maintaining its channel reserve.
+  - if it is _responsible_ for paying the Bitcoin fee:
+    - MUST NOT offer `amount_msat` if, after adding that HTLC to its commitment
+    transaction, it cannot pay the fee for either the local or remote commitment
+    transaction at the current `feerate_per_kw` while maintaining its channel
+    reserve (see [Updating Fees](#updating-fees-update_fee)).
+    - SHOULD NOT offer `amount_msat` if, after adding that HTLC to its commitment
+    transaction, its remaining balance doesn't allow it to pay the commitment
+    transaction fee when receiving or sending a future additional non-dust HTLC
+    while maintaining its channel reserve. It is recommended that this "fee spike
+    buffer" can handle twice the current `feerate_per_kw` to ensure predictability
+    between implementations.
+  - if it is _not responsible_ for paying the Bitcoin fee:
+    - SHOULD NOT offer `amount_msat` if, once the remote node adds that HTLC to
+    its commitment transaction, it cannot pay the fee for the updated local or
+    remote transaction at the current `feerate_per_kw` while maintaining its
+    channel reserve.
   - MUST offer `amount_msat` greater than 0.
   - MUST NOT offer `amount_msat` below the receiving node's `htlc_minimum_msat`
   - MUST set `cltv_expiry` less than 500000000.
@@ -875,6 +888,14 @@ seconds, and the protocol only supports an expiry in blocks.
 specification; larger amounts are not necessary, nor wise, during the
 bootstrap phase of the network.
 
+The node _responsible_ for paying the Bitcoin fee should maintain a "fee
+spike buffer" on top of its reserve to accommodate a future fee increase.
+Without this buffer, the node _responsible_ for paying the Bitcoin fee may
+reach a state where it is unable to send or receive any non-dust HTLC while
+maintaining its channel reserve (because of the increased weight of the
+commitment transaction), resulting in a degraded channel. See [#728](https://github.com/lightningnetwork/lightning-rfc/issues/728)
+for more details.
+
 ### Removing an HTLC: `update_fulfill_htlc`, `update_fail_htlc`, and `update_fail_malformed_htlc`
 
 For simplicity, a node can only remove HTLCs added by the other node.