docs(x/gov): fix typos

x/gov/README.md

@@ -63,7 +63,7 @@ staking token of the chain.
 
 ## Concepts
 
-The governance process is divided in a few steps that are outlined below:
+The governance process is divided into a few steps that are outlined below:
 
 * **Proposal submission:** Proposal is submitted to the blockchain with a
   deposit.
@@ -92,7 +92,7 @@ and have a respective path to execute on but do not perform a full validity chec
 
 :::warning
 Ultimately, governance is able to execute any proposal, even if they weren't meant to be executed by governance (ie. no authority present).
-Messages without authority are message meant to be executed by users. Using the `MsgSudoExec` message in a proposal, let governance can execute any message, effectively acting as super user.
+Messages without authority are messages meant to be executed by users. Using the `MsgSudoExec` message in a proposal, let governance be able to execute any message, effectively acting as super user.
 :::
 
 ### Deposit
@@ -216,7 +216,7 @@ A proposal can be expedited, making the proposal use shorter voting duration and
 
 #### Optimistic Proposal
 
-An optimistic proposal is a proposal that passes unless a threshold a NO votes is reached.
+An optimistic proposal is a proposal that passes unless a threshold of NO votes is reached.
 Voter can only vote NO on the proposal. If the NO threshold is reached, the optimistic proposal is converted to a standard proposal.
 
 That threshold is defined by the `optimistic_rejected_threshold` governance parameter.
@@ -273,7 +273,7 @@ Later, we may add permissioned keys that could only sign txs from certain module
 There are three parameters that define if the deposit of a proposal should be burned or returned to the depositors.
 
 * `BurnVoteVeto` burns the proposal deposit if the proposal gets vetoed.
-* `BurnVoteQuorum` burns the proposal deposit if the proposal deposit if the vote does not reach quorum.
+* `BurnVoteQuorum` burns the proposal deposit if the vote does not reach quorum.
 * `BurnProposalDepositPrevote` burns the proposal deposit if it does not enter the voting phase.
 
 > Note: These parameters are modifiable via governance.
@@ -282,7 +282,7 @@ There are three parameters that define if the deposit of a proposal should be bu
 
 Execution is the process of executing the messages contained in a proposal. The execution phase will commence after the proposal has been accepted by the network. The messages contained in the proposal will be executed in the order they were submitted.
 
-Execution has a upper limit on how much gas can be consumed in a single block. This limit is defined by the `ProposalExecutionGas` parameter.
+Execution has an upper limit on how much gas can be consumed in a single block. This limit is defined by the `ProposalExecutionGas` parameter.
 
 ## State
 
@@ -305,9 +305,9 @@ Since this is more of a social feature than a technical feature, we'll now get i
 * What is the purpose of the chain, specifically?
     * best example of this is the Cosmos hub, where different founding groups, have different interpretations of the purpose of the network.
 
-This genesis entry, "constitution" hasn't been designed for existing chains, who should likely just ratify a constitution using their governance system.  Instead, this is for new chains.  It will allow for validators to have a much clearer idea of purpose and the expectations placed on them while operating their nodes.  Likewise, for community members, the constitution will give them some idea of what to expect from both the "chain team" and the validators, respectively.
+This genesis entry, "constitution" hasn't been designed for existing chains, who should likely just ratify a constitution using their governance system.  Instead, this is for new chains. It will allow for validators to have a much clearer idea of purpose and the expectations placed on them while operating their nodes. Likewise, for community members, the constitution will give them some idea of what to expect from both the "chain team" and the validators, respectively.
 
-This constitution is designed to be immutable, and placed only in genesis, though that could change over time by a pull request to the cosmos-sdk that allows for the constitution to be changed by governance.  Communities wishing to make amendments to their original constitution should use the governance mechanism and a "signaling proposal" to do exactly that.
+This constitution is designed to be immutable, and placed only in genesis, though that could change over time by a pull request to the cosmos-sdk that allows for the constitution to be changed by governance. Communities wishing to make amendments to their original constitution should use the governance mechanism and a "signaling proposal" to do exactly that.
 
 **Ideal use scenario for a cosmos chain constitution**
 
@@ -445,7 +445,7 @@ We will use one KVStore `Governance` to store four mappings:
 * A mapping from `ParamsKey|'Params'` to `Params`. This map allows to query all
   x/gov params.
 
-For pseudocode purposes, here are the two function we will use to read or write in stores:
+For pseudocode purposes, here are the two functions we will use to read or write in stores:
 
 * `load(StoreKey, Key)`: Retrieve item stored at key `Key` in store found at key `StoreKey` in the multistore
 * `store(StoreKey, Key, value)`: Write value `Value` at key `Key` in store found at key `StoreKey` in the multistore
@@ -472,7 +472,7 @@ A legacy proposal is the old implementation of governance proposal.
 Contrary to proposal that can contain any messages, a legacy proposal allows to submit a set of pre-defined proposals.
 These proposals are defined by their types and handled by handlers that are registered in the gov v1beta1 router.
 
-More information on how to submit proposals in the [client section](#client).
+More information on how to submit proposals is in the [client section](#client).
 
 ## Messages