Fix typos (#1182)

* fix typos

* fix typos

* fix typo

* fix typo

* fix typos

* fix typo

bor/README.md

@@ -33,7 +33,7 @@ type Span struct {
 	ChainID           string       `json:"bor_chain_id" yaml:"bor_chain_id"`
 }
 ```
-where ,
+where,
 
 * `ID` means the id of the span, calculated by monotonically incrementing the ID of the previous span.
 * `StartBlock` corresponds to the block in bor from which the given span would commence.

bridge/README.md

@@ -11,7 +11,7 @@
 
 ## Overview
 
-Bridge module is responsible for listening to multiple chains and processing the events emitted by them.It converts the emitted data into heimdall messages and send them to the heimdall chain. There are `listener` and `processor` components in the bridge module which are responsible for listening and processing the events respectively as per their module. For example `listener/rootchain.go` is responsible for listening to events coming from rootchain OR L1 i.e Ethereum chain in our case and `listener/maticchain.go` is responsible for listening to events coming from maticchain or L2 i.e Bor chain in our case.
+Bridge module is responsible for listening to multiple chains and processing the events emitted by them. It converts the emitted data into heimdall messages and sends them to the heimdall chain. There are `listener` and `processor` components in the bridge module which are responsible for listening and processing the events respectively as per their module. For example `listener/rootchain.go` is responsible for listening to events coming from rootchain OR L1 i.e Ethereum chain in our case and `listener/maticchain.go` is responsible for listening to events coming from maticchain or L2 i.e Bor chain in our case.
 
 In order to process the events emitted by the chains, bridge module uses `processor` component, which is responsible for processing the events emitted by the chains. For example `processor/clerk.go` is responsible for processing the events related to clerk module, `processor/staking.go` is responsible for processing the events related to staking module and so on.
 
@@ -25,13 +25,13 @@ There is no change to the circulating supply of your token when it crosses the b
 
 ## Listener
 
-The bridge module has a `BaseListener` which is extended by `RootChainListener`, `MaticChainListener` and `HeimdallListener`. It has all the methods required to start polling, listening to incoming headers(blocks) and stopping the process if required. All the 3 listneres uses these properties with their individual implementations on how to handle the incoming header once received.
+The bridge module has a `BaseListener` which is extended by `RootChainListener`, `MaticChainListener` and `HeimdallListener`. It has all the methods required to start polling, listening to incoming headers(blocks) and stopping the process if required. All the 3 listeners use these properties with their individual implementations on how to handle the incoming header once received.
 
 For example in `RootChainListener` the incoming header is used to determine the current height of root chain and calculate the `from` and `to` block numbers using which the events are fetched from the root chain. These events are then sent to `handleLog` where based on their event signature they are added to queue as tasks for further processing by their respective processors.
 
 ## Processor
 
-There is a `BaseProcessor` which is extended by every processor in the processor package. It has all the methods required to start processing the events, registering for the tasks which are there in the queue and stopping the process if required. All the processors uses these properties with their individual implementations on how to handle the incoming events once received.
+There is a `BaseProcessor` which is extended by every processor in the processor package. It has all the methods required to start processing the events, registering for the tasks which are there in the queue and stopping the process if required. All the processors use these properties with their individual implementations on how to handle the incoming events once received.
 
 Once the event is added to the queue by the `Listener`, the `Processor` takes over and processes the events which are added into the queue based on their event signature. Each processor has `RegisterTasks` method using which they register to process specific tasks added to the queue based on the module they serve. For example `StakingProcessor` registers for `Staking` related tasks, `ClerkProcessor` registers for `Clerk` related tasks and so on. You can look into each processor to check which tasks they are registered for.
 

gov/README.md

@@ -13,7 +13,7 @@
 
 Heimdall governance works exactly the same as Cosmos-sdk's gov module. In this system, holders of the native staking token of the chain can vote on proposals on a 1 token = 1 vote basis. Here is a list of features the module currently supports:
 
-- Proposal submission: Validators can submit proposals with a deposit. Once the minimum deposit is reached, proposal enters voting period. Valdiators that deposited on proposals can recover their deposits once the proposal is rejected or accepted.
+- Proposal submission: Validators can submit proposals with a deposit. Once the minimum deposit is reached, proposal enters voting period. Validators that deposited on proposals can recover their deposits once the proposal is rejected or accepted.
 - Vote: Validators can vote on proposals that reached MinDeposit.
 
 There are deposit period and voting period as params in gov module. Minimum deposit has to be achieved before deposit period ends, otherwise proposal will be automatically rejected.

staking/README.md

@@ -23,7 +23,7 @@
 The `staking` module in Heimdall is responsible for a validator's stake related operations. It primarily aids in
 
 * A node joining the protocol as a validator.
-* An node leaving the protocol as a validator.
+* A node leaving the protocol as a validator.
 * Updating an existing validator's stake in the network.
 * Updating the signer address of an existing validator.
 
@@ -75,7 +75,7 @@ where
 * `TxHash` is the hash of the staking transaction on L1.
 * `LogIndex` is the index of the `Staked` log in the staking transaction receipt.
 * `BlockNumber` is the L1 block number in which the staking transaction was included.
-* `Nonce` is the the count representing all the staking related transactions performed from the new validator's account. This is meant to keep Heimdall and L1 in sync.
+* `Nonce` is the count representing all the staking related transactions performed from the new validator's account. This is meant to keep Heimdall and L1 in sync.
 
 Upon broadcasting the message, it goes through `HandleMsgValidatorJoin` handler which checks the basic sanity of the transaction (verifying the validator isn't already existing, voting power, etc.).
 
@@ -199,7 +199,7 @@ where
 * `TxHash` is the hash of the unstake transaction on L1.
 * `LogIndex` is the index of the `UnstakeInit` log in the unstake transaction receipt.
 * `BlockNumber` is the L1 block number in which the unstake transaction was included.
-* `Nonce` is the the count representing all the staking related transactions performed from the validator's account.
+* `Nonce` is the count representing all the staking related transactions performed from the validator's account.
 
 Upon broadcasting the message, it goes through `HandleMsgValidatorExit` handler which checks the basic sanity of the data in the transaction.
 
@@ -282,7 +282,7 @@ where
 * `TxHash` is the hash of the stake update transaction on L1.
 * `LogIndex` is the index of the `StakeUpdate` log in the stake update transaction receipt.
 * `BlockNumber` is the L1 block number in which the stake update transaction was included.
-* `Nonce` is the the count representing all the staking related transactions performed from the validator's account.
+* `Nonce` is the count representing all the staking related transactions performed from the validator's account.
 
 Upon broadcasting the message, it goes through `HandleMsgStakeUpdate` handler which checks the basic sanity of the data in the transaction.
 
@@ -325,7 +325,7 @@ curl -X POST "localhost:1317/staking/stake-update?proposer=<PROPOSER_ADDRESS>&id
 
 ## How does a validator update its signer address
 
-A validator can update its signer address in the network by invoking the the `updateSigner` function on the `StakeManager` contract on L1, which emits an `SignerChange` event:
+A validator can update its signer address in the network by invoking the `updateSigner` function on the `StakeManager` contract on L1, which emits an `SignerChange` event:
 
 ```
 /// @param validatorId unique integer to identify a validator.
@@ -363,7 +363,7 @@ where
 * `TxHash` is the hash of the signer update transaction on L1.
 * `LogIndex` is the index of the `SignerChange` log in the signer update transaction receipt.
 * `BlockNumber` is the L1 block number in which the signer update transaction was included.
-* `Nonce` is the the count representing all the staking related transactions performed from the validator's account.
+* `Nonce` is the count representing all the staking related transactions performed from the validator's account.
 
 Upon broadcasting the message, it goes through `HandleMsgSignerUpdate` handler which checks the basic sanity of the data in the transaction.
 

supply/types/account.go

@@ -75,7 +75,7 @@ func (ma *ModuleAccount) AddPermissions(permissions ...string) {
 }
 
 // RemovePermission removes the permission from the list of granted permissions
-// or returns an error if the permission is has not been granted.
+// or returns an error if the permission has not been granted.
 func (ma *ModuleAccount) RemovePermission(permission string) error {
 	for i, perm := range ma.Permissions {
 		if perm == permission {
@@ -98,7 +98,7 @@ func (ma ModuleAccount) HasPermission(permission string) bool {
 	return false
 }
 
-// GetName returns the the name of the holder's module
+// GetName returns the name of the holder's module
 func (ma ModuleAccount) GetName() string {
 	return ma.Name
 }