Docs improvements

docs/developer-guides/modules/btccheckpoint.md

@@ -15,14 +15,14 @@ Learn what the Babylon BTC Checkpoint Module is and how it operates.
 The `btccheckpoint` module is responsible for receiving information about Babylon checkpoints
 submitted to Bitcoin ledger. Each valid submission is composed of two Bitcoin transactions.
 Each of those transactions must contain at least one OP_RETRUN output which contains specific
-Babylon data. To verify that those transactions are part of bitcoin ledger, each submission
+Babylon data. To verify that those transactions are part of Bitcoin ledger, each submission
 must also have merkle proof of inclusions against transaction root hash from Bitcoin
 header which is already known by `btclightclient` module.
 Data included in OP_RETURN outputs must form a valid Babylon checkpoint. As `btccheckpoint`
-does not know all rules which makes checkpoint valid, it communicates with
+does not know all the rules which makes checkpoint valid, it communicates with
 `checkpoint` module to validate it.
 After submission is deemed valid:
-- It stored and tracked by `btcheckpoint` module
+- It is stored and tracked by `btcheckpoint` module
 - `checkpointing` module is informed about the different stages of checkpoint life cycle
 
 ## Problem Statement

docs/developer-guides/modules/btclightclient.md

@@ -53,7 +53,7 @@ Below we outline the key design decisions for the BTC light client module:
 
 ### Base Bitcoin Header
 
-The base bitcoin header is the first Bitcoin header that Babylon maintains.
+The base Bitcoin header is the first Bitcoin header that Babylon maintains.
 This header is specified in Babylon’s genesis block, and
 is a header that is sufficiently deep.
 For example, for our testnet, we will use a Bitcoin header that is 100-deep inside

docs/developer-guides/modules/epoching.md

@@ -12,7 +12,7 @@ Learn what the Babylon Epoching Module is and how it operates.
 
 ## Summary
 
-The epoching module is responsible for reducing and parameterising the frequency of updating the validator set in Babylon.
+The epoching module is responsible for reducing and parameterizing the frequency of updating the validator set in Babylon.
 The Babylon blockchain is divided into epochs, and each epoch contains a fixed number of consecutive blocks.
 All staking-related messages (creating validator, delegating, undelegating, and redelegating) are enqueued to the message queue of the current epoch.
 At the end of each epoch, the epoching module will execute all staking-related messages, then update the validator set w.r.t. the voting power distribution of validators.
@@ -26,8 +26,8 @@ If the validator set changes upon every block, then Babylon has to checkpoint to
 In addition, the Cosmos community also observed that frequent validator set updates make it challenging to implement threshold cryptography, light clients, fair leader election, and staking derivatives, as discussed in [ADR-039](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-039-epoched-staking.md).
 
 In order to reduce the frequency of validator set updates, a natural solution is to implement the epoching mechanism (aka epoched staking), which divides the blockchain into epochs and triggers a validator set update per epoch.
-The idea of epoching was proposed and formalised in [ADR-039](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-039-epoched-staking.md), and there have been multiple efforts (https://github.com/cosmos/cosmos-sdk/pull/8829, https://github.com/cosmos/cosmos-sdk/pull/10132, https://github.com/cosmos/cosmos-sdk/pull/10173) of implementing it.
-Since Babylon has some extra design goals (e.g., checkpointing epochs) and these efforts have discontinued, Babylon implements its own epoching module.
+The idea of epoching was proposed and formalized in [ADR-039](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-039-epoched-staking.md), and there have been multiple efforts (https://github.com/cosmos/cosmos-sdk/pull/8829, https://github.com/cosmos/cosmos-sdk/pull/10132, https://github.com/cosmos/cosmos-sdk/pull/10173) of implementing it.
+Since Babylon has some extra design goals (e.g., checkpointing epochs) and these efforts have been discontinued, Babylon implements its own epoching module.
 
 In addition, in order to achieve slashable safety, Babylon has to implement Bitcoin-assisted unbonding, where an unbonding request is finished only when the corresponding block has been checkpointed on Bitcoin.
 With the epoching mechanism, all unbonding requests in an epoch will be finished upon this epoch has been checkpointed on Bitcoin.
@@ -80,7 +80,7 @@ In the staking module, these messages include
 - `MsgDelegate` for delegating coins from a delegator to a validator
 - `MsgBeginRedelegate` for redelegating coins from a delegator and source validator to a destination validator.
 - `MsgUndelegate` for undelegating from a delegator and a validator.
-- `MsgCancelUnbondingDelegation` for cancelling unbonding delegation for a delegator
+- `MsgCancelUnbondingDelegation` for canceling unbonding delegation for a delegator
 
 Within these messages, `MsgCreateValidator`, `MsgDelegate`, `MsgBeginRedelegate`, and `MsgUndelegate` affect the validator set.
 Since Babylon requires the validator set to be unchanged within an epoch, it has to avoid processing these messages in the middle of epochs.

docs/developer-guides/modules/reporter.md

@@ -19,7 +19,7 @@ We need to ensure that at least one reporter is working in the Babylon network.
 
 ## Problem Statement
 
-The vigilante reporter needs to continuously processes BTC blocks from the BTC height at which the Babylon checkpointing starts.
+The vigilante reporter needs to continuously process BTC blocks from the BTC height at which the Babylon checkpointing starts.
 It needs to forward all the BTC headers on the canonical chain to feed the BTC header chain of Babylon.
 The reporter also needs to check every transaction in a BTC block and tries to match raw checkpoints since a raw checkpoint is decoded into two different BTC transactions.
 
@@ -34,11 +34,11 @@ The vigilante reporter program makes the following design decisions:
 
 When a vigilant reporter is started, it needs to go through the bootstrapping process, which makes the following design decisions:
 
-- **BTC header synchronisation**: Babylon’s BTC header chain is synchronised with the BTC full node that connects to vigilante.
+- **BTC header synchronization**: Babylon’s BTC header chain is synchronized with the BTC full node that connects to vigilante.
 If the BTC header chain of Babylon falls behind the BTC full node, the bootstrapping helps the header chain catch up.
 On the other hand, if the header chain is ahead of the BTC full node, the reporter will wait until the BTC full node to catch up.
 - **Header consistency**: Babylon’s `k-deep` BTC headers are consistent with the BTC full node
-- **Checkpoint synchronisation**: historical checkpoints on BTC are reported to Babylon.
+- **Checkpoint synchronization**: historical checkpoints on BTC are reported to Babylon.
 The reporter sends checkpoints that are not `w-deep` yet in BTC to Babylon.
 The reporter also buffers all the checkpoint parts that have not been matched with a checkpoint.
 

docs/developer-guides/modules/zoneconcierge.md

@@ -13,7 +13,7 @@ Learn what the Babylon Zone Concierge Module is and how it operates.
 ## Summary
 
 The zone concierge module is responsible for providing BTC timestamps to headers from other Cosmos zones.
-These BTC timestamps allow Cosmos zones integrating with Babylon to achieve Bitcoin security, i.e., forking a Cosmos zone is as hard as forking Bitcoin.
+These BTC timestamps allow Cosmos zones to integrate with Babylon to achieve Bitcoin security, i.e., forking a Cosmos zone is as hard as forking Bitcoin.
 To receive Cosmos zones' headers, the zone concierge module leverages the light clients in the IBC protocol.
 Specifically, on top of the original [IBC-Go](https://github.com/cosmos/ibc-go) implementation, Babylon adds a hook that forwards headers with a valid quorum certificate to the zone concierge module.
 Upon a header from IBC, zone concierge then stores the header's metadata in the KV store.
@@ -32,9 +32,9 @@ Checkpointing canonical headers allows Babylon to act as a canonical chain oracl
 Checkpointing fork headers allows Babylon to identify dishonest majority attacks and slash equivocating validators.
 Zone concierge will not checkpoint any header that does not have a quorum certificate.
 
-Specifically, the zone concierge module aims at providing the following guarantees
+Specifically, the zone concierge module aims to provide the following guarantees
 
-- **Timestamping headers:** Babylon timestamps all Cosmos zones' headers with a valid quorum certificate from the IBC relayer, regardless whether they are on CZ canonical chains or not.
+- **Timestamping headers:** Babylon timestamps all Cosmos zones' headers with a valid quorum certificate from the IBC relayer, regardless of whether they are on CZ canonical chains or not.
 - **Verifiability of timestamps:** For any CZ header, Babylon can provide a proof that the CZ header is checkpointed by {Babylon, BTC}, where the proof is verifiable assuming access to Babylon/BTC light clients.
 
 under the following assumptions:
@@ -67,7 +67,7 @@ The light client allows a Cosmos zone to maintain a subset of headers from the c
 - **Liveness:** The IBC light client keeps growing
 when the counterparty zone has > 2/3 honest voting power and there exists > 1 honest relayer.
 
-Verifying a header is done by a special [quorum intersection mechanism](https://arxiv.org/abs/2010.07031): upon a header from the relayer, the light client checks whether the intersected voting power bewteen the quorum certificates of the current tip and the header is more than 1/3 of the voting power in the current tip.
+Verifying a header is done by a special [quorum intersection mechanism](https://arxiv.org/abs/2010.07031): upon a header from the relayer, the light client checks whether the intersected voting power between the quorum certificates of the current tip and the header is more than 1/3 of the voting power in the current tip.
 If yes, then this ensures that there exists at least one honest validator in the header's quorum certificate, and this header is agreed by all honest validators.
 Each header of a Cosmos zone carries `AppHash`, which is the root of the Merkle IAVL tree for the Cosmos zone's database.
 The `AppHash` allows a light client to verify whether an IBC packet is included in the Cosmos zone's blockchain.

docs/developer-guides/vigilantes/reporter.md

@@ -34,11 +34,11 @@ The vigilante reporter program makes the following design decisions:
 
 When a vigilant reporter is started, it needs to go through the bootstrapping process, which makes the following design decisions:
 
-- **BTC header synchronisation**: Babylon’s BTC header chain is synchronised with the BTC full node that connects to vigilante.
+- **BTC header synchronization**: Babylon’s BTC header chain is synchronized with the BTC full node that connects to vigilante.
 If the BTC header chain of Babylon falls behind the BTC full node, the bootstrapping helps the header chain catch up.
 On the other hand, if the header chain is ahead of the BTC full node, the reporter will wait until the BTC full node to catch up.
 - **Header consistency**: Babylon’s `k-deep` BTC headers are consistent with the BTC full node
-- **Checkpoint synchronisation**: historical checkpoints on BTC are reported to Babylon.
+- **Checkpoint synchronization**: historical checkpoints on BTC are reported to Babylon.
 The reporter sends checkpoints that are not `w-deep` yet in BTC to Babylon.
 The reporter also buffers all the checkpoint parts that have not been matched with a checkpoint.
 

docs/faq/overview.md

@@ -20,19 +20,19 @@ custom_edit_url: null
 ### Will my bitcoins be bridged to other blockchains?
 
 No.
-Babylon allows bitcoin holders to stake their
+Babylon allows Bitcoin holders to stake their
 bitcoins without bridging them to other blockchains,
 while providing the chain with full slashable security guarantees.
 
-### As a bitcoin staker, do I have to run a validator by myself?
+### As a Bitcoin staker, do I have to run a validator by myself?
 
 No.
 Like most PoS systems,
 with the Bitcoin staking protocol,
 you can delegate your voting power to a validator that you trust.
 The validator will usually charge a commission of your staking reward.
 If the delegated validator acts maliciously, your stake will also be slashed.
-Running validator by yourself will avoid this trust and commission,
+Running a validator by yourself will avoid this trust and commission,
 putting both the stake and reward fully under your control.
 
 ### When slashing happens, will all my staked bitcoins be burned?

docs/introduction/architecture.md

@@ -114,7 +114,7 @@ an alarm will be raised by the monitor program.
 A standalone program that submits
 Babylon checkpoints to Bitcoin as
 Bitcoin transactions embedding data
-utilising the `OP_RETURN` Bitcoin script code.
+utilizing the `OP_RETURN` Bitcoin script code.
 
 ### [Vigilante Reporter](../developer-guides/modules/reporter)
 
@@ -192,7 +192,7 @@ finality provider's private keys.
 
 ### [Covenant Emulator](https://github.com/babylonchain/covenant-emulator)
 
-A standalone program utilised by the covenant emulation committee members.
+A standalone program utilized by the covenant emulation committee members.
 It emulates [covenant](https://covenants.info) functionality by monitoring
 for pending staking requests,
 verifying their contents, and

docs/introduction/btc-staking.md

@@ -8,7 +8,7 @@ import Paperclip from "/img/paperclip.svg";
 
 # Bitcoin Staking
 
-Babylon's Bitcoin staking protocol allows bitcoin holders to stake their bitcoin for PoS blockchains, without needing any third-party custody/bridge/wrapping.
+Babylon's Bitcoin staking protocol allows Bitcoin holders to stake their Bitcoin for PoS blockchains, without needing any third-party custody/bridge/wrapping.
 It provides slashable economic security guarantees to the PoS chains while ensuring efficient stake unbonding to enhance liquidity for Bitcoin holders.
 This protocol is designed as a modular plug-in compatible with various PoS consensus protocols and serves as a foundational component for building restaking protocols.
 
@@ -47,10 +47,10 @@ Babylon's Bitcoin staking protocol achieves the following security properties:
 
 From a Bitcoin staker's perspective, the Bitcoin staking protocol works as follows:
 
-1. **Staking bitcoin:** the staker initiates the process by sending a staking transaction to the Bitcoin chain, locking her bitcoin in a self-custodian vault. More specifically, it creates a UTXO with two spending conditions: 1) timelock after which the staker can use her secret key to withdraw, and 2) burning this UTXO through a special extractable one-time signature (EOTS). In case of delegation, this EOTS belongs to the validator the stake delegates to.
+1. **Staking Bitcoin:** the staker initiates the process by sending a staking transaction to the Bitcoin chain, locking her Bitcoin in a self-custodian vault. More specifically, it creates a UTXO with two spending conditions: 1) timelock after which the staker can use her secret key to withdraw, and 2) burning this UTXO through a special extractable one-time signature (EOTS). In case of delegation, this EOTS belongs to the validator the stake delegates to.
 2. **Validation on PoS Chain:** Once the staking transaction is confirmed on the Bitcoin chain, the staker (or the validator the staker delegates to) can start validating the PoS chain and signing votes valid blocks using the EOTS secret key. During her validation duty, there are two possible paths:
-   - **Happy Path:** In the honest scenario, the staker follows the protocol and earns yield. The staker can then unbond via two approaches: 1) wait for the existing timeclock to expire and then withdraw; or 2) submit an unbonding transaction to Bitcoin, which will unlock the bitcoin and return it to her after a parameterized unbonding period.
-   - **Unhappy Path:** If the staker behaves maliciously, e.g., participates in double-spending attacks on the PoS chain, the staking protocol ensures her EOTS secret key is exposed to the public. Consequently, anyone can impersonate the staker to submit a slashing transaction on the Bitcoin chain and burn her bitcoin. This unhappy path ensures that safety violations are penalized, maintaining the overall integrity of the system.
+   - **Happy Path:** In the honest scenario, the staker follows the protocol and earns yield. The staker can then unbond via two approaches: 1) wait for the existing timeclock to expire and then withdraw; or 2) submit an unbonding transaction to Bitcoin, which will unlock the Bitcoin and return it to her after a parameterized unbonding period.
+   - **Unhappy Path:** If the staker behaves maliciously, e.g., participates in double-spending attacks on the PoS chain, the staking protocol ensures her EOTS secret key is exposed to the public. Consequently, anyone can impersonate the staker to submit a slashing transaction on the Bitcoin chain and burn her Bitcoin. This unhappy path ensures that safety violations are penalized, maintaining the overall integrity of the system.
 
 ## Bitcoin staking core design
 
@@ -63,9 +63,9 @@ We combine two concepts to achieve this:
 - Finality gadgets from blockchain consensus
 
 We employ extractable one-time signatures (EOTS) to realize accountable assertions, where using the same secret key to sign different blocks at the same height results in secret key leakage.
-We introduce an additional signing round after the base consensus protocol, called the finality round. A block is considered finalized only if it receives EOTS signatures from over 2/3 of the bitcoin stake.
+We introduce an additional signing round after the base consensus protocol, called the finality round. A block is considered finalized only if it receives EOTS signatures from over 2/3 of the Bitcoin stake.
 All safety violations of the consensus can be reduced to double signing in this round.
-If there is a safety violation in this modified protocol, then more than 1/3 of the bitcoin stake has signed two blocks at the same height using EOTS.
+If there is a safety violation in this modified protocol, then more than 1/3 of the Bitcoin stake has signed two blocks at the same height using EOTS.
 This leads to the extraction of the secret keys of those stakers.
 The EOTS signature scheme can be implemented by Schnorr signatures, which is natively supported by Bitcoin.
 Hence these extracted secret keys can be used to slash the staked bitcoin.

docs/introduction/btc-timestamping.md

@@ -59,7 +59,7 @@ In the following, we explore the BTC Timestamping Protocol's use case in
 detail.
 
 ## Long-Range Attack: A Fundamental Threat to PoS Chains <a id="long"></a>
-By PoS chains, we refer to BFT (Byzantine-fault-tolerent) PoS chains that
+By PoS chains, we refer to BFT (Byzantine-fault-tolerant) PoS chains that
 require a 2/3 majority vote from their validators to confirm a block.
 PoS chains are not supposed to fork, and when forking happens,
 the chain is attacked: