Fixed grammatical errors in documentation

docs/architecture.md

@@ -31,7 +31,7 @@ whether the inclusion evidence for a Bitcoin transaction is valid.
 ### [BTC Checkpoint](../x/btccheckpoint)
 
 The BTC Checkpoint module verifies Babylon’s BTC checkpoints
-reported by the Vigilante Reporter, and
+reported by the Vigilante Reporter  and
 provides the confirmation status of these checkpoints to the Checkpointing
 module based on their depth according to the BTC Light Client module.
 
@@ -140,7 +140,7 @@ A standalone program that monitors:
   on the Bitcoin ledger to inform Babylon about them.
 - The execution of BTC Staking slashing transactions in the case
   of a finality provider double voting.
-  In the case of non-execution the monitor extracts the finality provider's
+  In the case of non-execution, the monitor extracts the finality provider's
   private key and executes the slashing.
 - The execution of a selective slashing attack launched
   by a finality provider. In this case,
@@ -169,12 +169,12 @@ has been developed to enable these functionalities:
   Daemon program connecting to a Bitcoin wallet and Babylon.
 - [BTC Staker Dashboard](https://github.com/babylonchain/btc-staking-dashboard):
   Web application connecting to a Bitcoin wallet extension and the Babylon API.
-  Should only be used for testing purposes.
+  It should only be used for testing purposes.
 - Wallet Integrations (TBD)
 
 ### [Finality Provider](https://github.com/babylonchain/finality-provider)
 
-A standalone program that allows for the registration and
+A standalone program that allows the registration and
 maintenance of a finality provider.
 It monitors for a finality provider's inclusion in the active set, commits
 [Extractable One Time Signature (EOTS)](https://docs.babylonchain.io/assets/files/btc_staking_litepaper-32bfea0c243773f0bfac63e148387aef.pdf)

docs/run-node.md

@@ -44,7 +44,7 @@ The `gentxs` directory contains the genesis transactions. It contains
 transactions that assign bbn tokens to a single address that is defined for each
 node.
 
-The `node0` directory contains the following,
+The `node0` directory contains the following:
 
 ```console
 $ ls .testnet/node0/babylond

docs/staking-script.md

@@ -9,25 +9,25 @@ The locked Bitcoin contributes to Babylon chain's economic security and generate
 yields for the Bitcoin stakers.
 The protocol has the following important properties:
 
-1. The staking is trustless and self-custodial, meaning it does not require
-   bridging, wrapping, 3rd-party custody/multi-sig, or oracle.
+1. Staking is trustless and self-custodial, meaning it does not require
+   bridging, wrapping, 3rd-party custody/multi-sig, or oracles.
 2. The stake voting power is delegatable, a common feature of Delegated PoS
    (DPoS) protocols.
-3. Stake security: the staked bitcoin is slashed if and only if the BTC staker
-   itself (and in case of delegation, its delegatee) is malicious. This implies
+3. Stake security: the staked Bitcoin is slashed if and only if the BTC staker
+   itself (and in the case of delegation, its delegatee) is malicious. This implies
    that, even if the Babylon chain is compromised and taken over by malicious
    actors, as long as the BTC staker itself (and the validator it delegates to
    in case of delegation) is not malicious, its bitcoin stake is secure.
 4. The protocol supports fractional slashing, meaning the protocol can be
    configured so that when slashing happens, only a fraction of the staked
    bitcoins are slashed, and the rest is returned to the staker.
-5. The protocol allows stakers to on-demand unbond, On-demand unbonding, means
+5. The protocol allows stakers to on-demand unbond. On-demand unbonding, means
    the BTC staker can withdraw from staking with an unbonding delay.
 6. Atomic slashing, meaning that if a delegator is slashed, then all the
    delegators of the same delegatee, including the delegatee's self-delegation,
    will be subject to slashing. In other words, the delegatee cannot
    selectively harm any specific delegator.
-7. (WIP) restakable, meaning that the same bitcoin can be staked to secure
+7. (WIP) Restakable, meaning that the same Bitcoin can be staked to secure
    multiple PoS chains and earn multiple PoS yields
 
 
@@ -39,7 +39,7 @@ in staking scripts. Note that a staking transaction can be funded from
 arbitrary UTXO, including those owned by multisig/MPC/threshold accounts.
 Thus, `<StakerPk>` is not necessarily the address of the source of the fund.
 Rather, it is the controller and beneficiary of the stake after its creation.
-- **Finality Provider**: A Finality Provider is the an entity that votes
+- **Finality Provider**: A Finality Provider is an entity that votes
 in the finality round to provide security assurance to the PoS chain.
 
 The Bitcoin staker can choose a specific Finality Provider to delegate
@@ -58,8 +58,8 @@ that were introduced through the Taproot upgrade.
 
 ## Staking Flow
 
-Following diagram shows how different transactions described in following
-paragraphs create and spend different bitcoin outputs:
+The following diagram shows how different transactions described in following
+paragraphs create and spend different Bitcoin outputs:
 
 ```mermaid
 stateDiagram-v2
@@ -92,7 +92,7 @@ stateDiagram-v2
     change_staking --> [*]: Withdrawal transaction
 ```
 
-Withdrawal transactions are btc transactions which transfer bitcoins to the btc
+Withdrawal transactions are BTC transactions which transfer Bitcoins to the BTC
 staker wallet.
 
 ## Types of special transactions
@@ -105,16 +105,16 @@ There are three special transaction types recognized by the Babylon chain:
 
 ### Staking Transaction
 
-A BTC Staker gains voting power by creating a staking transaction. This is a
-Bitcoin transaction that commits a certain amount of to-be-staked bitcoin to
-Babylon recognized BTC staking scripts. These scripts lock the stake for a
+The BTC staker gains voting power by creating a staking transaction. This is a
+Bitcoin transaction that commits a certain amount of to-be-staked Bitcoin to
+Babylon-recognized BTC staking scripts. These scripts lock the stake for a
 chosen amount of BTC blocks and enable other features such as unbonding and
 slashable safety.
 
 The requirements for a valid staking transaction are:
 
-- it can contain arbitrary number of inputs
-- it can contain arbitrary number of outputs. One of those outputs must be
+- It can contain an arbitrary number of inputs.
+- It can contain an arbitrary number of outputs. One of those outputs must be
   a Taproot output committing to the BTC staking scripts recognized by Babylon.
   Henceforth known as `Staking Output`.
 
@@ -125,9 +125,9 @@ their stake before their originally committed timelock has expired.
 
 The requirements for a valid unbonding transaction are:
 
-- it contains exactly one input which points to staking transaction's `Staking
+- It contains exactly one input which points to the staking transaction's `Staking
 Output`.
-- it contains exactly one output which must be a Taproot output committing to
+- It contains exactly one output which must be a Taproot output committing to
   the BTC unbonding scripts recognized by Babylon. Henceforth known as `Unbonding
 Output`.
 
@@ -138,29 +138,29 @@ finality provider they have delegated to) perform an offense.
 
 The requirements for a valid slashing transaction are:
 
-- it must have exactly one input pointing to either the staking output or the
-  unbonding output
-- it must have exactly two outputs, the first sending the slashed fraction of
-  the funds to a burn address specified in the Babylon chain's parameters and the
-  second sending the remaining funds to output which can be unlocked by staker
-  after the timelock
-- the fee for the slashing transactions must be larger than or equal to the
+- It must have exactly one input pointing to either the staking output or the
+  unbonding output.
+- It must have exactly two outputs, the first sending the slashed fraction of
+  the funds to a burn address specified in the Babylon chain's parameters, and the
+  second sending the remaining funds to an output which can be unlocked by the staker
+  after the timelock.
+- The fee for the slashing transactions must be larger than or equal to the
   minimal fee specified in Babylon's parameters
 
 ## Staking and Unbonding output scripts
 
-In the below scripts, there are three entities, each represented by BTC public
+In the scripts below, there are three entities, each represented by a BTC public
 key:
 
-- `StakerPK` - BTC staker public key
-- `FinalityProviderPk` - finality provider public key
+- `StakerPK` - BTC staker public key.
+- `FinalityProviderPk` - finality provider public key.
 - `CovenantPk1..CovenantPkN` - public keys of covenant committee members
 There must be no duplicated public keys in created scripts.
-For example, `StakerPK` must never be equal to `FinalityProviderPk`
+For example, `StakerPK` must never be equal to `FinalityProviderPk`.
 
 ### Staking output
 
-The staking output is a taproot output which can only be spent through a script
+The staking output is a Taproot output which can only be spent through a script
 spending path.
 The key spending path is disabled by using the "Nothing Up My Sleeve"
 (NUMS) point as internal key. Chosen point is the one described in
@@ -214,7 +214,7 @@ where:
 
 Signatures from a quorum of the covenant committee are required to ensure that
 this script is not used for on-demand unlocking without the stake going through
-an unbonding period. reward all covenant members for their work.
+an unbonding period. Reward all covenant members for their work.
 
 #### 3. Slashing path
 
@@ -230,21 +230,21 @@ delegators in the case of double signing. It commits to a script:
 
 where:
 
-- `StakerPK` is the BTC staker's public key
+- `StakerPK` is the BTC staker's public key.
 - `FinalityProviderPk` is the BTC public key of the finality provider to which
   the staker delegates their stake
 - `CovenantPk1..CovenantPkN` are the lexicographically sorted public keys of the
-  current covenant committee members recognized by the Babylon chain
+  current covenant committee members recognized by the Babylon chain.
 - `CovenantThreshold` is a Babylon parameter denoting how many covenant
   committee member signatures are required.
 
 This path can only be executed with the collaboration of the BTC staker,
 finality provider, and covenant committee.
 It is used in following way:
 
-- for stake to become active, staker must publish pre signed slashing transaction
-- covenant committee validates such transaction, and publish its own signatures.
-- the only signature missing to send slashing transaction is finality provider
+- For stake to become active, staker must publish pre-signed slashing transaction.
+- The covenant committee validates such transaction, and publish its own signatures.
+- The only signature missing to send the slashing transaction is finality provider
   signature. If finality provider private key leaks due to infractions, anyone can
   sign slashing transaction and send slashing transaction to Bitcoin network.
 
@@ -255,21 +255,21 @@ The main difference between the unbonding and slashing paths is the existence of
 
 This leads to following system wide repercussions:
 
-- for staking request to become active, btc staker needs to provide valid
+- For staking request to become active, btc staker needs to provide valid
   unbonding transaction in this staking request. This staking request will become
-  active only when `CovenantThreshold` signatures will be received by Babylon
-  chain. Lack of `FinalityProviderPk` in unbonding path, means that after
-  delegation becomes active, staker can send unbonding transaction any time
-  without asking finality provider for permission.
-- existence of `FinalityProviderPk` in slashing path, coupled with the fact that
-  btc staker needs to provide pre-signed slashing transaction which needs to be
+  active only when the `CovenantThreshold` signatures are received by the Babylon
+  chain. The lack of `FinalityProviderPk` in the unbonding path, means that after
+  delegation becomes active, staker can send an unbonding transaction at any time
+  without asking the finality provider for permission.
+- The existence of `FinalityProviderPk` in the slashing path, coupled with the fact that
+  BTC staker needs to provide pre-signed slashing transaction which needs to be
   signed by covenant committee for delegation request to become active, leads to
   situation in which the only signature missing to send slashing transaction to
-  btc is signature of finality provider.
+  BTC is signature of finality provider.
 
 ### Unbonding output
 
-Unbonding output is a taproot output which can be only spent through script
+Unbonding output is a Taproot output which can be only spent through script
 spending path. The key spending path is disabled by using "Nothing Up My Sleeve"
 (NUMS) point as internal key. Chosen point is the one described in BIP341 i.e H
 = lift_x(0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0)
@@ -289,7 +289,7 @@ Bitcoin blocks. It commits to a script of the form:
 
 where:
 
-- `<StakerPK>` is btc staker public key
+- `<StakerPK>` is BTC staker public key.
 - `<TimelockBlocks>` is unbonding time. It must be lower or equal 65535, but larger
   than `max(MinUnbondingTime, CheckpointFinalizationTimeout)`. `MinUnbondingTime`
   and `CheckpointFinalizationTimeout` are Babylon parameters.
@@ -308,16 +308,16 @@ delegators in the case of double signing. It commits to a script:
 
 where:
 
-- `StakerPK` is the BTC staker's public key
+- `StakerPK` is the BTC staker's public key.
 - `FinalityProviderPk` is the BTC public key of the finality provider to which
-  the staker delegates their stake
+  the staker delegates their stake.
 - `CovenantPk1..CovenantPkN` are the lexicographically sorted public keys of the
-  current covenant committee members recognized by the Babylon chain
+  current covenant committee members recognized by the Babylon chain.
 - `CovenantThreshold` is a Babylon parameter denoting how many covenant
   committee member signatures are required.
 
 #### Existence of Slashing path in Unbonding output
 
 The fact that slashing path exists in unbonding output means that even if staker
-is unbonding he can be slashed if finality provider commits infraction during
+is unbonding, he can be slashed if the finality provider commits an infraction during
 unbonding time.