update fee mw docs, add formating, fix typos, increase readability

docs/middleware/ics29-fee/end-users.md

@@ -8,7 +8,7 @@ Learn how to incentivize IBC packets using the ICS29 Fee Middleware module. {syn
 
 ## Pre-requisite readings
 
-* [Fee Middleware](overview.md) {prereq}
+- [Fee Middleware](overview.md) {prereq}
 
 ## Summary
 
@@ -17,7 +17,6 @@ Different types of end users:
 - CLI users who want to manually incentivize IBC packets
 - Client developers
 
-
 The Fee Middleware module allows end users to add a 'tip' to each IBC packet which will incentivize relayer operators to relay packets between chains. gRPC endpoints are exposed for client developers as well as a simple CLI for manually incentivizing IBC packets.
 
 ## CLI Users
@@ -26,6 +25,6 @@ For an in depth guide on how to use the ICS29 Fee Middleware module using the CL
 
 ## Client developers
 
-Client developers can read more about the relevant ICS29 message types in the [Escrowing and paying out fees section](../ics29-fee/msgs.md).
+Client developers can read more about the relevant ICS29 message types in the [Fee messages section](../ics29-fee/msgs.md).
 
 [CosmJS](https://github.com/cosmos/cosmjs) is a useful client library for signing and broadcasting Cosmos SDK messages.

docs/middleware/ics29-fee/events.md

@@ -4,10 +4,12 @@ order: 5
 
 # Events
 
+An overview of all events related to ICS-29 {synopsis}
+
 ## `MsgPayPacketFee`, `MsgPayPacketFeeAsync`
 
 | Type                    | Attribute Key   | Attribute Value |
-|-------------------------|-----------------|-----------------|
+| ----------------------- | --------------- | --------------- |
 | incentivized_ibc_packet | port_id         | {portID}        |
 | incentivized_ibc_packet | channel_id      | {channelID}     |
 | incentivized_ibc_packet | packet_sequence | {sequence}      |
@@ -19,16 +21,16 @@ order: 5
 ## `RegisterPayee`
 
 | Type           | Attribute Key | Attribute Value |
-|----------------|------------|--------------------|
-| register_payee | relayer    | {relayer}          |
-| register_payee | payee      | {payee}            |
-| register_payee | channel_id | {channelID}        |
-| message        | module     | fee-ibc            |
+| -------------- | ------------- | --------------- |
+| register_payee | relayer       | {relayer}       |
+| register_payee | payee         | {payee}         |
+| register_payee | channel_id    | {channelID}     |
+| message        | module        | fee-ibc         |
 
 ## `RegisterCounterpartyPayee`
 
 | Type                        | Attribute Key      | Attribute Value     |
-|-----------------------------|--------------------|---------------------|
+| --------------------------- | ------------------ | ------------------- |
 | register_counterparty_payee | relayer            | {relayer}           |
 | register_counterparty_payee | counterparty_payee | {counterpartyPayee} |
 | register_counterparty_payee | channel_id         | {channelID}         |

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

@@ -8,26 +8,30 @@ Learn about payee registration for the distribution of packet fees. The followin
 
 ## Pre-requisite readings
 
-* [Fee Middleware](overview.md) {prereq}
+- [Fee Middleware](overview.md) {prereq}
 
 Packet fees are divided into 3 distinct amounts in order to compensate relayer operators for packet relaying on fee enabled IBC channels.
 
 - `RecvFee`: The sum of all packet receive fees distributed to a payee for successful execution of `MsgRecvPacket`.
 - `AckFee`: The sum of all packet acknowledgement fees distributed to a payee for successful execution of `MsgAcknowledgement`.
 - `TimeoutFee`: The sum of all packet timeout fees distributed to a payee for successful execution of `MsgTimeout`.
 
-## Register a payee address for forward relaying
+## Register a counterparty payee address for forward relaying
+
+As mentioned in [ICS29 Concepts](../ics29-fee/overview.md#concepts), the forward relayer describes the actor who performs the submission of `MsgRecvPacket` on the destination chain.
+Fee distribution for incentivized packet relays takes place on the packet source chain.
+
+> Relayer operators are expected to register a counterparty payee address, in order to be compensated accordingly with `RecvFee`s upon completion of a packet lifecycle.
 
-As mentioned in [ICS29 Concepts](../ics29-fee/overview.md#concepts), the forward relayer describes the actor who performs the submission of `MsgRecvPacket` on the destination chain. 
-Fee distribution for incentivized packet relays takes place on the packet source chain. 
-Relayer operators are expected to register a counterparty payee address, in order to be compensated accordingly with `RecvFee`s upon completion of a packet lifecycle. 
 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.
+**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 destination chain including a `CounterpartyPayee` address of an account on the source chain.
+### Relayer Operator Actions?
+
+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`.
 
-Note: If a module account address is used as the `CounterpartyPayee` it is recommended to [turn off invariant checks](https://github.com/cosmos/ibc-go/blob/71d7480c923f4227453e8a80f51be01ae7ee845e/testing/simapp/app.go#L659) for that module. 
+Note: If a module account address is used as the `CounterpartyPayee` it is recommended to [turn off invariant checks](https://github.com/cosmos/ibc-go/blob/71d7480c923f4227453e8a80f51be01ae7ee845e/testing/simapp/app.go#L659) for that module.
 
 ```go
 type MsgRegisterCounterpartyPayee struct {
@@ -42,27 +46,31 @@ type MsgRegisterCounterpartyPayee struct {
 }
 ```
 
-This message is expected to fail if:
-
-- `PortId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators).
-- `ChannelId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators)).
-- `Relayer` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/basics/accounts.md#Addresses)).
-- `CounterpartyPayee` is empty.
+> This message is expected to fail if:
+>
+> - `PortId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators).
+> - `ChannelId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators)).
+> - `Relayer` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/basics/accounts.md#Addresses)).
+> - `CounterpartyPayee` is empty.
 
 See below for an example CLI command:
 
 ```
 simd tx ibc-fee register-counterparty-payee transfer channel-0 cosmos1rsp837a4kvtgp2m4uqzdge0zzu6efqgucm0qdh osmo1v5y0tz01llxzf4c2afml8s3awue0ymju22wxx2 --from cosmos1rsp837a4kvtgp2m4uqzdge0zzu6efqgucm0qdh
 ```
 
-## Register a payee address for reverse and timeout relaying
+## Register an alternative payee address for reverse and timeout relaying
 
-As mentioned in [ICS29 Concepts](../ics29-fee/overview.md#concepts), the reverse relayer describes the actor who performs the submission of `MsgAcknowledgement` on the source chain. 
+As mentioned in [ICS29 Concepts](../ics29-fee/overview.md#concepts), the reverse relayer describes the actor who performs the submission of `MsgAcknowledgement` on the source chain.
 Similarly the timeout relayer describes the actor who performs the submission of `MsgTimeout` (or `MsgTimeoutOnClose`) on the source chain.
-Relayer operators may choose to register an optional payee address, in order to be compensated accordingly with `AckFee`s and `TimeoutFee`s upon completion of a packet life cycle.
+
+> Relayer operators **may choose** to register an optional payee address, in order to be compensated accordingly with `AckFee`s and `TimeoutFee`s upon completion of a packet life cycle.
+
 If a payee is not registered for the reverse or timeout relayer on the source chain, then fee distribution assumes the default behaviour, where fees are paid out to the relayer account which delivers `MsgAcknowledgement` or `MsgTimeout`/`MsgTimeoutOnClose`.
 
-A transaction must be submitted to the source chain including a `Payee` address of an account on the source chain.
+### Relayer operator actions
+
+A transaction must be submitted **to the source chain** including a `Payee` address of an account on the source chain.
 The transaction must be signed by the `Relayer`.
 
 Note: If a module account address is used as the `Payee` it is recommended to [turn off invariant checks](https://github.com/cosmos/ibc-go/blob/71d7480c923f4227453e8a80f51be01ae7ee845e/testing/simapp/app.go#L659) for that module.
@@ -80,12 +88,12 @@ type MsgRegisterPayee struct {
 }
 ```
 
-This message is expected to fail if:
-
-- `PortId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators).
-- `ChannelId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators)).
-- `Relayer` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/basics/accounts.md#Addresses)).
-- `Payee` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/basics/accounts.md#Addresses)).
+> This message is expected to fail if:
+>
+> - `PortId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators).
+> - `ChannelId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators)).
+> - `Relayer` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/basics/accounts.md#Addresses)).
+> - `Payee` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/basics/accounts.md#Addresses)).
 
 See below for an example CLI command:
 

docs/middleware/ics29-fee/msgs.md

@@ -2,71 +2,89 @@
 order: 3
 -->
 
-# Escrowing fees
+# Fee messages
+
+Learn about the different ways to pay for fees, how the fees are paid out and what happens when not enough escrowed fees are available for payout {synopsis}
+
+## Escrowing fees
 
 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.  
-
-    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.
-
-    ```
-    type MsgPayPacketFee struct{
-      // fee encapsulates the recv, ack and timeout fees associated with an IBC packet
-      Fee                 Fee
-      // the source port unique identifier
-      SourcePortId        string
-      // the source channel unique identifer
-      SourceChannelId     string
-      // account address to refund fee if necessary
-      Signer              string
-      // optional list of relayers permitted to the receive packet fee
-      Relayers            []string
-    }
-    ```
-
-    The `Fee` message contained in this synchronous fee payment method configures different fees which will be paid out for `MsgRecvPacket`, `MsgAcknowledgement`, and `MsgTimeout`/`MsgTimeoutOnClose`. 
-
-    ```
-    type Fee struct {
-	    RecvFee             types.Coins
-	    AckFee              types.Coins
-	    TimeoutFee          types.Coin`
-    }
-    ```
+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.
+
+   ```go
+   type MsgPayPacketFee struct{
+     // fee encapsulates the recv, ack and timeout fees associated with an IBC packet
+     Fee                 Fee
+     // the source port unique identifier
+     SourcePortId        string
+     // the source channel unique identifer
+     SourceChannelId     string
+     // account address to refund fee if necessary
+     Signer              string
+     // optional list of relayers permitted to the receive packet fee
+     Relayers            []string
+   }
+   ```
+
+   The `Fee` message contained in this synchronous fee payment method configures different fees which will be paid out for `MsgRecvPacket`, `MsgAcknowledgement`, and `MsgTimeout`/`MsgTimeoutOnClose`.
+
+   ```go
+   type Fee struct {
+       RecvFee             types.Coins
+       AckFee              types.Coins
+       TimeoutFee          types.Coins
+   }
+   ```
+
+The diagram below shows the `MultiMsgTx` with the `MsgTransfer` coming from a token transfer message, along with `MsgPayPacketFee`.
+
+![MsgPayPacketFee](../../assets/fee-mw/msgpaypacket.png)
 
 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
-      PacketId            channeltypes.PacketId
-      // the packet fee associated with a particular IBC packet
-      PacketFee           PacketFee
-    }
-    ```
-
-    where the `PacketFee` also specifies the `Fee` to be paid as well as the refund address for fees which are not paid out
-    ```
-    type PacketFee struct {
-	    Fee                    Fee
-	    RefundAddress          string
-	    Relayers               []]string
-    }
-    ```
+   Note that a packet can be 'topped up' multiple times with additional fees of any coin denomination by broadcasting multiple `MsgPayPacketFeeAsync` messages.
+
+   ```go
+   type MsgPayPacketFeeAsync struct {
+     // unique packet identifier comprised of the channel ID, port ID and sequence
+     PacketId            channeltypes.PacketId
+     // the packet fee associated with a particular IBC packet
+     PacketFee           PacketFee
+   }
+   ```
+
+   where the `PacketFee` also specifies the `Fee` to be paid as well as the refund address for fees which are not paid out
+
+   ```go
+   type PacketFee struct {
+       Fee                    Fee
+       RefundAddress          string
+       Relayers               []string
+   }
+   ```
+
+The diagram below shows how multiple `MsgPayPacketFeeAsync` can be broadcasted asynchronously. Escrowing of the fee associated with a packet can be carried out by any party because ICS-29 does not dictate a particular fee payer. In fact, chains can choose to simply not expose this fee payment to end users at all and rely on a different module account or even the community pool as the source of relayer incentives.
+
+![MsgPayPacketFeeAsync](../../assets/fee-mw/paypacketfeeasync.png)
 
 Please see our [wiki](https://github.com/cosmos/ibc-go/wiki/Fee-enabled-fungible-token-transfers) for example flows on how to use these messages to incentivise a token transfer channel using a CLI.
 
-# Paying out the escrowed fees
-
-In the case of a successful transaction, `RecvFee` will be paid out to the designated counterparty payee address which has been registered on the receiver chain and sent back with the `MsgAcknowledgement`, `AckFee` will be paid out to the relayer address which has submitted the `MsgAcknowledgement` on the sending chain (or the registered payee in case one has been registered for the relayer address), and `TimeoutFee` will be reimbursed to the account which escrowed the fee. In cases of timeout transactions, `RecvFee` and `AckFee` will be reimbursed. 
+## Paying out the escrowed fees
+
+Following diagram takes a look at the packet flow for an incentivized token transfer and investigates the several scenario's for paying out the escrowed fees. We assume that the relayers have registered their counterparty address, detailed in the [Fee distribution section](../ics29-fee/fee-distribution.md).
+
+![packet-flow-fee](../../assets/fee-mw/feeflow.png)
+
+- In the case of a successful transaction, `RecvFee` will be paid out to the designated counterparty payee address which has been registered on the receiver chain and sent back with the `MsgAcknowledgement`, `AckFee` will be paid out to the relayer address which has submitted the `MsgAcknowledgement` on the sending chain (or the registered payee in case one has been registered for the relayer address), and `TimeoutFee` will be reimbursed to the account which escrowed the fee.
+- In case of a timeout transaction, `RecvFee` and `AckFee` will be reimbursed. The `TimeoutFee` will be paid to the `Timeout Relayer` (who submits the timeout message to the source chain).
 
-Please note that fee payments are built on the assumption that sender chains are the source of incentives — the chain that sends the packets is the same chain where fee payments will occur -- please see the [relayer operator section](../ics29-fee/fee-distribution.md) to understand the flow for registering payee and counterparty payee (fee receiving) addresses.
+> Please note that fee payments are built on the assumption that sender chains are the source of incentives — the chain that sends the packets is the same chain where fee payments will occur -- please see the [Fee distribution section](../ics29-fee/fee-distribution.md) to understand the flow for registering payee and counterparty payee (fee receiving) addresses.
 
-# A locked fee middleware module
+## A locked fee middleware module
 
-The fee middleware module can become locked if the situation arises that the escrow account for the fees does not have sufficient funds to pay out the fees which have been escrowed for each packet. This situation indicates a severe bug. In this case, the fee module will be locked until manual intervention fixes the issue. 
+The fee middleware module can become locked if the situation arises that the escrow account for the fees does not have sufficient funds to pay out the fees which have been escrowed for each packet. _This situation indicates a severe bug._ In this case, the fee module will be locked until manual intervention fixes the issue.
 
-A locked fee module will simply skip fee logic and continue on to the underlying packet flow. A channel with a locked fee module will temporarily function as a fee disabled channel, and the locking of a fee module will not affect the continued flow of packets over the channel.
+> A locked fee module will simply skip fee logic and continue on to the underlying packet flow. A channel with a locked fee module will temporarily function as a fee disabled channel, and the locking of a fee module will not affect the continued flow of packets over the channel.