fix: typos

contracts/test/invariants/handlers/SubnetRegistryHandler.sol

@@ -56,11 +56,11 @@ contract SubnetRegistryHandler is CommonBase, StdCheats, StdUtils {
 
     /// getRandomOldAddressOrNewOne returns a new random address
     function getRandomOldAddressOrNewOne(uint256 seed) internal view returns (address) {
-        uint256 lenght = ghost_owners.length();
-        if (lenght == 0 || seed % 4 == 0) {
+        uint256 length = ghost_owners.length();
+        if (length == 0 || seed % 4 == 0) {
             return msg.sender;
         } else {
-            return ghost_owners.values()[seed % lenght];
+            return ghost_owners.values()[seed % length];
         }
     }
 

docs/fendermint/activity_rollups.md

@@ -160,7 +160,7 @@ library Consensus {
         ValidatorData[] data;
     }
 
-    // The compresed representation of the activity summary for consensus-level activity suitable for embedding in a checkpoint.
+    // The compressed representation of the activity summary for consensus-level activity suitable for embedding in a checkpoint.
     struct CompressedSummary {
         AggregatedStats stats;
         /// The commitment for the validator details, so that we don't have to transmit them in full.
@@ -268,7 +268,7 @@ This command takes:
 - the block ranges in the subnet we want to scan for eligible claims.
 - the address of the validator we want to claim rewards for.
 
-The command will when scan the subnet for eligible claims within the specified block ranges, and will then submit the
+The command will then scan the subnet for eligible claims within the specified block ranges, and will then submit the
 claim to the ancestor subnet using the batch claim method to amortize the gas cost.
 
 ```bash

docs/fendermint/architecture.md

@@ -17,10 +17,10 @@ The components in a nutshell:
 
 ## ABCI++
 
-We want make use of the ABCI++ interface to get more control over the voting process by implementing the new `PrepareProposal` and `ProcessProposal` methods. These are close to be [released](https://github.com/tendermint/tendermint/issues/9053) in the upcoming `v0.37` of Tendermint Core.
+We want to make use of the ABCI++ interface to get more control over the voting process by implementing the new `PrepareProposal` and `ProcessProposal` methods. These are close to be [released](https://github.com/tendermint/tendermint/issues/9053) in the upcoming `v0.37` of Tendermint Core.
 
 The best place to look up the details of the ABCI++ spec is currently at https://github.com/tendermint/tendermint/tree/v0.37.0-rc2/spec/abci
 
 Note that the spec has previously been under the `main` branch but not any more, and that it changed recently to only contain the above two extra methods, but not _vote extensions_ for the new `FinalizeBlock` method, which was supposed to replace `BeginBlock`, `DeliverTx`, `EndBlock` and I think `Commit`.
 
-The reason we want to be able to control voting is to evaludate the CIDs contained in blocks for data availability, before they are committed for execution. We can do this by simply not voting on any proposal that contains CIDs _for execution_ that are unavailable on the node of the validator. To make them available, we'll use a solution similar to [NC-Max](https://eprint.iacr.org/2020/1101) to propose CIDs _for resolution_ and inclusion in future blocks, thus moving data dissemination out of the critical path of consensus.
+The reason we want to be able to control voting is to evaluate the CIDs contained in blocks for data availability, before they are committed for execution. We can do this by simply not voting on any proposal that contains CIDs _for execution_ that are unavailable on the node of the validator. To make them available, we'll use a solution similar to [NC-Max](https://eprint.iacr.org/2020/1101) to propose CIDs _for resolution_ and inclusion in future blocks, thus moving data dissemination out of the critical path of consensus.

docs/fendermint/checkpointing.md

@@ -2,7 +2,7 @@
 
 Bottom-up checkpoints are periodically submitted to the parent subnet, carrying:
 * bottom-up messages
-* the next highest configuration number adopted form the validator changesets observed on the parent
+* the next highest configuration number adopted from the validator changesets observed on the parent
 * a multi-sig from the current validator set
 * the identity of the checkpointed block height
 

docs/fendermint/tendermint.md

@@ -4,7 +4,7 @@ To implement the [architecture](./architecture.md) we intend to make use of the
 
 * [CometBFT](https://github.com/cometbft/cometbft): One of the successors of the generic blockchain SMR system [Tendermint Core](https://github.com/tendermint/tendermint) (others might be listed [here](https://github.com/tendermint/ecosystem)). Originally we used the upcoming [v0.37](https://github.com/tendermint/tendermint/tree/v0.37.0-rc2), but it was eventually released as part of CometBFT. This version has the required [extensions](./architecture.md#abci) to [ABCI++](https://github.com/cometbft/cometbft/tree/v0.37.1/spec/abci).
 * [tendermint-rs](https://github.com/informalsystems/tendermint-rs/) is a Rust library that contains Tendermint [datatypes](https://github.com/informalsystems/tendermint-rs/tree/main/tendermint); the [proto](https://github.com/informalsystems/tendermint-rs/tree/main/proto) code [generated](https://github.com/informalsystems/tendermint-rs/tree/main/tools/proto-compiler) from the Tendermint protobuf definitions; a synchronous [ABCI server](https://github.com/informalsystems/tendermint-rs/tree/main/abci) with a trait the application can implement, with a [KV-store example](https://github.com/informalsystems/tendermint-rs/blob/main/abci/src/application/kvstore/main.rs) familiar from the tutorial; and various other goodies for building docker images, integration testing the application with Tendermint, and so on. Since [this PR](https://github.com/informalsystems/tendermint-rs/pull/1193) the library supports both `v0.34` (the last stable release of Tendermint Core) and the newer `v0.37` version (the two are not wire compatible).
-* [tower-abci](https://github.com/penumbra-zone/tower-abci) from Penumbra adapts the ABCI interfaces from `tendermint-rs` to be used with [tower](https://crates.io/crates/tower) and has a [server](https://github.com/penumbra-zone/tower-abci/blob/v0.7.0/src/v037/server.rs) implementation that works with the the `v0.37` wire format and uses [tokio](https://crates.io/crates/tokio). So, unlike the ABCI server in `tendermint-rs`, this is asynchronous, which we can make use of if we want to inject our own networking.
+* [tower-abci](https://github.com/penumbra-zone/tower-abci) from Penumbra adapts the ABCI interfaces from `tendermint-rs` to be used with [tower](https://crates.io/crates/tower) and has a [server](https://github.com/penumbra-zone/tower-abci/blob/v0.7.0/src/v037/server.rs) implementation that works with the `v0.37` wire format and uses [tokio](https://crates.io/crates/tokio). So, unlike the ABCI server in `tendermint-rs`, this is asynchronous, which we can make use of if we want to inject our own networking.
 
 That should be enough to get us started with Tendermint.
 

fendermint/rpc/src/query.rs

@@ -45,7 +45,7 @@ pub trait QueryClient: Sync {
         extract_opt(res, |res| Ok(res.value))
     }
 
-    /// Query the the state of an actor.
+    /// Query the state of an actor.
     async fn actor_state(
         &self,
         address: &Address,

fendermint/testing/README.md

@@ -11,6 +11,6 @@ The `fendermint_testing` crate (ie. the current directory) provides some reusabl
 
 Beyond this, for no other reason than code organisation, the directory has sub-projects, which contain actual tests.
 
-For example the [smoke-test](./smoke-test/) is a a crate that uses `cargo make` to start a local stack with Tendermint and Fendermint running in Docker, and run some integration tests, which can be found in the [Makefile.toml](./smoke-test/Makefile.toml).
+For example the [smoke-test](./smoke-test/) is a crate that uses `cargo make` to start a local stack with Tendermint and Fendermint running in Docker, and run some integration tests, which can be found in the [Makefile.toml](./smoke-test/Makefile.toml).
 
 To run these, either `cd` into that directory and run them from there, or run all from the root using `make e2e`, which also builds the docker images.

fendermint/testing/contract-test/src/ipc/registry.rs

@@ -42,7 +42,7 @@ impl<DB> RegistryCaller<DB> {
 }
 
 impl<DB: Blockstore + Clone> RegistryCaller<DB> {
-    /// Create a new instance of the built-in subnet implemetation.
+    /// Create a new instance of the built-in subnet implementation.
     ///
     /// Returns the address of the deployed contract.
     pub fn new_subnet(

fendermint/testing/contract-test/tests/staking/state.rs

@@ -250,7 +250,7 @@ impl StakingState {
 
     /// Check if checkpoints can be sent to the system.
     pub fn can_checkpoint(&self) -> bool {
-        // This is a technical thing of how the the state does transitions, it's all done in the checkpoint method.
+        // This is a technical thing of how the state does transitions, it's all done in the checkpoint method.
         if !self.activated {
             return true;
         }

fendermint/vm/interpreter/src/fvm/state/ipc.rs

@@ -304,7 +304,7 @@ impl<DB: Blockstore + Clone> GatewayCaller<DB> {
         Ok(IPCParentFinality::from(r))
     }
 
-    /// Get the Ethereum adresses of validators who signed a checkpoint.
+    /// Get the Ethereum addresses of validators who signed a checkpoint.
     pub fn checkpoint_signatories(
         &self,
         state: &mut FvmExecState<DB>,

ipc/provider/src/manager/evm/manager.rs

@@ -598,7 +598,7 @@ impl SubnetManager for EthSubnetManager {
         let token_address = payload_to_evm_address(
             subnet_supply_source
                 .token_address
-                .ok_or_else(|| anyhow!("zero adress not erc20"))?
+                .ok_or_else(|| anyhow!("zero address not erc20"))?
                 .payload(),
         )?;
         let token_contract = IERC20::new(token_address, signer.clone());

ipld/resolver/docs/README.md

@@ -63,7 +63,7 @@ The following diagram shows a typical sequence of events within the IPLD Resolve
 
 The diagrams in this directory can be rendered with `make diagrams`.
 
-Adding the following script to `.git/hooks/pre-commit` automatically renders and checks in the images when we commit changes to the them. CI should also check that there are no uncommitted changes.
+Adding the following script to `.git/hooks/pre-commit` automatically renders and checks in the images when we commit changes to them. CI should also check that there are no uncommitted changes.
 
 ```bash
 #!/usr/bin/env bash

recall/iroh_manager/src/manager.rs

@@ -53,7 +53,7 @@ impl IrohManager {
         })
     }
 
-    /// Retrives a blob client, and starts the node if it has not started yet.
+    /// Retrieves a blob client, and starts the node if it has not started yet.
     pub fn blobs_client(&self) -> BlobsClient {
         self.client.blobs_client().boxed()
     }

specs/addressing.md

@@ -2,7 +2,7 @@
 
 ## IPC Actors addressing
 
-### Filecoin adressing schemes
+### Filecoin addressing schemes
 
 When the contracts described below (Gateway, Registry, Subnet) are deployed to a Filecoin network (e.g. Mainnet, Calibration), `f0`, `f2` and `f410` addresses will be assigned to them. The latter is equivalent to an Ethereum hex address.
 Detailed explanation of Filecoin addressing scheme is available in [the documentation](https://docs.filecoin.io/smart-contracts/filecoin-evm-runtime/address-types).

specs/bottom-up-interaction.md

@@ -58,7 +58,7 @@ Creating a checkpoint in the ledger is performed deterministically by every full
 
 After the checkpoint has been added to the ledger *and committed in a block*, those nodes which are currently validators broadcast transactions which add their signatures using the `broadcast_signature` function of the [`checkpoint`](https://github.com/consensus-shipyard/ipc/blob/specs/fendermint/vm/interpreter/src/fvm/checkpoint.rs) module.
 
-The reason we wait for the the change to be committed is so that the transactions that add the signatures don’t get rejected by `check_tx` because they are referring to a non-existing checkpoint.
+The reason we wait for the change to be committed is so that the transactions that add the signatures don’t get rejected by `check_tx` because they are referring to a non-existing checkpoint.
 
 The signing and sending of transactions happens in the [`broadcast`](https://github.com/consensus-shipyard/ipc/blob/specs/fendermint/vm/interpreter/src/fvm/broadcast.rs) module which fetches the current nonce of the validator, estimates the gas, performs retries, etc. Because it fetches the nonce for each submission, it cannot be used in parallel.