nit changes

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

@@ -38,7 +38,7 @@ in the diagram below:
 ![Phases of a consumer chain](./adr18_phases_of_a_consumer_chain.png)
 
 
-**Registered phase.** When a Top N chain is first proposed through a `MsgConsumerAddition` proposal or an Opt In chain is registered (more on this later) using the `MsgRegisterConsumerChain` transaction,
+**Registered phase.** When a Top N chain is first proposed through a `MsgConsumerAddition` proposal or an Opt In chain is registered (more on this later) using the `MsgConsumerRegistration` transaction,
 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.
 
@@ -50,7 +50,7 @@ chain [has started](https://github.com/cosmos/interchain-security/blob/v5.1.0/x/
 **Launched phase.** When the [`spawnTime`](https://github.com/cosmos/interchain-security/blob/v5.1.0/proto/interchain_security/ccv/provider/v1/provider.proto#L57)
 passes and [at least one validator has opted in](https://github.com/cosmos/interchain-security/blob/v5.1.0/x/ccv/provider/keeper/proposal.go#L430)
 the chain can launch and moves to the _launched_ phase. While in launched phase, a Top N consumer chain can choose to modify
-its parameters through a `MsgConsumerModification` and an Opt In chain can change its parameters by issuing the `MsgUpdateConsumerChain` transaction.
+its parameters through a `MsgConsumerModification` and an Opt In chain can change its parameters by issuing the `MsgConsumerModification` transaction.
 
 **Stopped phase.** Lastly, a Top N chain can choose to exit ICS by issuing a `MsgConsumerRemoval` and an Opt In chain can issue a transaction to stop the chain.
 After some period of time (e.g., provider's unbonding period), all state related to the stopped consumer chain can be removed. We
@@ -158,7 +158,7 @@ in joining ICS even though, they might not yet know the specific ICS parameters
 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 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).
+To prevent an attacker spamming the system by creating bogus consumer chains, we set a fixed cost for sending a `MsgConsumerRegistration` (configurable via a parameter).
 
 #### Initialize a Consumer Chain
 To move a consumer chain to its initialized phase, we issue a `MsgConsumerInitialization` message that is as follows:
@@ -231,9 +231,8 @@ message ConsumerInitializationConfig {
 }
 ```
 
-`ConsumerInitializationConfig` contains _almost_ everything that is contained in [`ConsumerAdditionProposal`](https://github.com/cosmos/interchain-security/blob/v5.1.0/proto/interchain_security/ccv/provider/v1/provider.proto#L30)
-but we create it to be able to use it across both Top N chains (where we used `ConsumerAdditionProposal`s before), as
-well as in Opt In chains. As a result, we deprecate `ConsumerAdditionProposal`.
+`ConsumerInitializationConfig` contains _almost_ everything that is contained in [`MsgConsumerAddition`](https://github.com/cosmos/interchain-security/blob/v5.1.0/proto/interchain_security/ccv/provider/v1/tx.proto#L111).
+Note that as part of this work, we deprecate [`ConsumerAdditionProposal`](https://github.com/cosmos/interchain-security/blob/v5.1.0/proto/interchain_security/ccv/provider/v1/provider.proto#L30).
 
 For each `consumerId`, we store its corresponding `ConsumerInitializationConfig`. For Top N chains, we can perform this
 store by using the [`AfterProposalVotingPeriodEnded`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.8/x/gov/types/hooks.go#L52).
@@ -243,7 +242,7 @@ We need to extensively check the fields of the provided `ConsumerInitializationC
 chain launches with problematic parameters (e.g., we need to have maximum length for the `chainId`, etc.).
 As a starter we look into the [usual validity conditions](https://github.com/cosmos/interchain-security/blob/v5.1.0/x/ccv/provider/types/msg.go#L244).
 
-For all chains in the initialized phase, we keep a mapping between `consumerId` and the underlying `InitializationRecord`.
+For all chains in the initialized phase, we keep a mapping between `consumerId` and the underlying `ConsumerInitializationConfig`.
 This way, we can respond to queries that ask for all the consumer chain's parameters. For example, retrieving the
 `spawn_time` of consumer chain with a given `consumerId`.
 
@@ -279,13 +278,13 @@ message ConsumerModificationConfig {
 }
 ```
 
-Note, that even though a consumer chain is initialized with all the arguments in `InitializationRecord`,
+Note, that even though a consumer chain is initialized with all the arguments in `ConsumerInitializationConfig`,
 the `MsgConsumerModification` updates only the `owner_address` and the `consumer_modification_config`. This is because 
 all the other arguments are either useless (e.g., `spawnTime`) after a chain has started, or can be updated directly
 by the consumer chain params (e.g., `consumer_redistribution_fraction`).
 
 #### Remove (Stop) a Consumer Chain
-We reuse the `MsgConsumerRemoval` we can stop any Opt In chain at any point in time. Note that all relevant state for this consumer chain
+We reuse the `MsgConsumerRemoval` so we can stop any Opt In chain at any point in time. Note that all relevant state for this consumer chain
 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
@@ -318,8 +317,6 @@ Because we only have two consumer chains at the moment, this is not going to be
 consumer chains that are being voted upon. Similarly, all the messages, queries, etc. would need to be changed to operate on a `consumerId`
 instead of a `chainId`.
 
-Note that we also need to modify `MsgConsumerModification` to contain `owner_address` if and only if `top_N` is set to 0.
-
 ## Consequences
 
 ### Positive