docs: nits

docs/middleware/ics29-fee/fee-distribution.md

@@ -24,7 +24,7 @@ Relayer operators are expected to register a counterparty payee address, in orde
 The counterparty payee address registered on the destination chain is encoded into the packet acknowledgement and communicated as such to the source chain for fee distribution.
 If a counterparty payee is not registered for the forward relayer on the destination chain, the escrowed fees will be refunded upon fee distribution.
 
-A transaction must be submitted to the desintation chain including a `CounterpartyPayee` address of an account on the source chain.
+A transaction must be submitted to the destination chain including a `CounterpartyPayee` address of an account on the source chain.
 The transaction must be signed by the `Relayer`.
 
 ```go

docs/middleware/ics29-fee/msgs.md

@@ -6,7 +6,7 @@ order: 3
 
 The fee middleware module exposes two different ways to pay fees for relaying IBC packets:
 
-1. `MsgPayPacketFee`, which enables the escrowing of fees for a packet at the next sequence send and should be combined into one `MultiMsgTx` with the message that will be paid for. 
+1. `MsgPayPacketFee`, which enables the escrowing of fees for a packet at the next sequence send and should be combined into one `MultiMsgTx` with the message that will be paid for.  
 
     Note that the `Relayers` field has been set up to allow for an optional whitelist of relayers permitted to receive this fee, however, this feature has not yet been enabled at this time.
 
@@ -37,6 +37,8 @@ The fee middleware module exposes two different ways to pay fees for relaying IB
 
 2. `MsgPayPacketFeeAsync`, which enables the asynchronous escrowing of fees for a specified packet:
 
+    Note that a packet can be 'topped up' multiple times with additional fees of any coin denomination by broadcasting multiple `MsgPayPacketFeeAsync` messages.
+
     ```
     type MsgPayPacketFeeAsync struct {
       // unique packet identifier comprised of the channel ID, port ID and sequence