nit changes

docs/docs/adrs/adr-018-permissionless-ics.md

@@ -24,14 +24,14 @@ ICS without needing a governance proposal but by simply issuing a transaction.
 ## Decision
 
 ### The Phases of a Consumer Chain
-In Permissionless ICS, launching an Opt In chain is **only** possible through a transaction and not through a [`MsgConsumerAddition`](https://github.com/cosmos/interchain-security/blob/v5.1.0/proto/interchain_security/ccv/provider/v1/tx.proto#L111).
-Nevertheless, ICS does not eliminate the `MsgConsumerAddition` governance proposal, as proposals are still necessary
+In Permissionless ICS, launching an Opt In chain is **only** possible through a transaction and not through a [`MsgConsumerAddition`](https://github.com/cosmos/interchain-security/blob/v5.1.0/proto/interchain_security/ccv/provider/v1/tx.proto#L111)
+proposal. Nevertheless, ICS does not eliminate the `MsgConsumerAddition` governance proposal, as proposals are still necessary
 for Top N chains. Because of this, this ADR outlines a solution that attempts to preserve as much of the governance proposal code
 as possible.
 Additionally, to make the distinction between governance-proposed versus transaction-launched chains clearer, in Permissionless ICS,
 we can only add, modify, or remove Top N chains with governance proposals (i.e., `MsgConsumerAddition`, `MsgConsumerModification`,
 and `MsgConsumerRemoval`) and we can only add, modify, or remove Opt In chains with transactions.
-Note however that a Top N chain can transform to an Opt In Chain through a `MsgConsumerModification` that sets `top_N == 0` but not vice versa.
+Note however that a Top N chain can transform to an Opt In Chain through a `MsgConsumerModification` proposal that sets `top_N == 0` but not vice versa.
 
 A consumer chain can reside in four phases: i) _registered_, ii) _initialized_, iii) _launched_, and iv) _stopped_ phase as seen
 in the diagram below:
@@ -42,8 +42,8 @@ in the diagram below:
 the consumer chain resides in the _registered_ phase. A consumer chain in the registered phase might end up not launching, i.e., the `MsgConsumerAddition` proposal does not pass or the registered Opt In chain is never initialized (see below).
 At this phase, as well as in the initialized and launched phases, validators can choose to opt in on the consumer chain.
 
-**Initialized phase.** If the `MsgConsumerAddition` of a Top N chain passes or a registered Opt In chain is set to launch with the `MsgInitializeConsumerChain` transaction, then the chain moves to the _initialized_ phase.
-In the initialized phase, an Opt In chain can choose to change the consumer chain parameters, such as `spawnTime`, etc. by issuing a new `MsgInitializeConsumerChain`.
+**Initialized phase.** If the `MsgConsumerAddition` proposal of a Top N chain passes or a registered Opt In chain is set to launch with the `MsgConsumerInitialization` transaction, then the chain moves to the _initialized_ phase.
+In the initialized phase, an Opt In chain can choose to change the consumer chain parameters, such as `spawnTime`, etc. by issuing a new `MsgConsumerInitialization`.
 This is not the case for Top N chains, where a `MsgConsumerModification` can only be issued after a consumer
 chain [has started](https://github.com/cosmos/interchain-security/blob/v5.1.0/x/ccv/provider/keeper/legacy_proposal.go#L89).
 
@@ -87,7 +87,7 @@ As a result of using `consumerId`, we have to migrate a substantial chunk of sta
 Currently, in ICS we have state that is indexed by a multitude of [keys](https://github.com/cosmos/interchain-security/blob/v5.1.0/x/ccv/provider/types/keys.go#L40).
 In the table below, we see the ones that are associated with a `chainId` and how often state under those keys gets updated.
 Additionally, for each key, the table shows whose action can lead to the setting or deletion of the state associated with that key.
-An action can stem either from: i) a consumer chain (e.g., through a `MsgUpdateChain` message, an IBC packet sent over to the provider, etc.),
+An action can stem either from: i) a consumer chain (e.g., through a `MsgConsumerModification` message, an IBC packet sent over to the provider, etc.),
 ii) a provider chain (e.g., at the end of a block some action is taken), or by iii) a validator (e.g., through a `MsgAssignConsumerKey` message)
 or a combination of them.
 
@@ -120,8 +120,9 @@ or a combination of them.
 Everything stored under one of the above keys is associated with a `chainId` and has to be migrated to new state under a `consumerId`.
 
 ### New Messages
-In what follows, we describe the new messages (i.e., `MsgRegisterConsumerChain`, `MsgInitializeConsumerChain`, and `MsgUpdateConsumerChain`)
-that Permissionless ICS introduces, and on how those can be used.
+In this section, we describe the new messages (i.e., `MsgConsumerRegistration` and `MsgConsumerInitialization`)
+that Permissionless ICS introduces, and the reused ones (i.e., `MsgConsumerModification` and `MsgConsumerRemoval`) and
+on how they can be used.
 Then, we describe how to utilize these messages with our existing codebase.
 
 #### Register a Consumer Chain
@@ -155,7 +156,7 @@ in joining ICS even though, they might not yet know the specific ICS parameters
 
 `ConsumerRegistrationConfig` contains the `owner_address` that corresponds to the address that would be able to initialize or later update this consumer chain.
 We store the owner address of each Opt In consumer chain by creating an association between `consumerId`s and `owner_address`es.
-Top N chains do not have an `onwer_address` because they can only be modified through governance proposals. 
+Top N chains have as the `onwer_address` the address of the governance account, because they can only be modified through governance proposals. 
 
 To prevent an attacker spamming the system by creating bogus consumer chains, we set a fixed cost for sending a `MsgRegisterConsumerChain` (configurable via a parameter).
 
@@ -288,10 +289,10 @@ We reuse the `MsgConsumerRemoval` we can stop any Opt In chain at any point in t
 remains on the provider's state before getting removed after one unbonding period (of the provider). This is to enable
 potential slashing for any infraction that might have been caused until now.
 Note however that we never recycle previously-used `consumerId`s. Naturally, this message can only be issued by the owner
-of the consumer chain. Also, note that, any remaining IBC rewards that were to be sent to the provider chain are lost.
+of the consumer chain.
 
 ```protobuf
-message MsgStopConsumerChain {
+message MsgConsumerRemoval {
   // the consumerId as returned by `MsgLaunchConsumerChain`
   string consumer_id;
   // the time on the provider chain at which all validators are responsible to