diff --git a/SECURITY.md b/SECURITY.md
index 02b37486a09197..a27ccbe1f2da4a 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -50,7 +50,7 @@ comment as such and then close the report.
 
 ### 2. Triage
 Within the draft security advisory, discuss and determine the severity of the issue. If necessary, members of the solana-labs/security-incident-response group may add other github users to the advisory to assist.
-If it is determined that this not a critical network issue then the advisory should be closed and if more follow-up is required a normal Solana public github issue should be created.
+If it is determined that this is not a critical network issue then the advisory should be closed and if more follow-up is required a normal Solana public github issue should be created.
 
 ### 3. Prepare Fixes
 For the affected branches, typically all three (edge, beta and stable), prepare a fix for the issue and push them to the corresponding branch in the private repository associated with the draft security advisory.
diff --git a/ci/README.md b/ci/README.md
index 64af969ae9b292..45ebd39e1d4a94 100644
--- a/ci/README.md
+++ b/ci/README.md
@@ -73,7 +73,7 @@ sudo CUDA=1 ./setup-new-buildkite-agent/setup-new-machine.sh
 
 ### Configure Node for Buildkite-agent based CI
 
-- Install `buildkite-agent` and set up it user environment with:
+- Install `buildkite-agent` and set up its user environment with:
 ```bash
 sudo ./setup-new-buildkite-agent/setup-buildkite.sh
 ```
diff --git a/docs/src/validator/gossip.md b/docs/src/validator/gossip.md
index 07a2758fe30e47..3c637f5c707357 100644
--- a/docs/src/validator/gossip.md
+++ b/docs/src/validator/gossip.md
@@ -34,7 +34,7 @@ record with the most recent timestamp.
 
 ### Push Message
 
-A node sends a push message to tells the cluster it has information to share.
+A node sends a push message to tell the cluster it has information to share.
 Nodes send push messages to `PUSH_FANOUT` push peers.
 
 Upon receiving a push message, a node examines the message for:
@@ -56,7 +56,7 @@ Upon receiving a push message, a node examines the message for:
 
 ### Push Peers, Prune Message
 
-A nodes selects its push peers at random from the active set of known peers. The
+A node selects its push peers at random from the active set of known peers. The
 node keeps this selection for a relatively long time. When a prune message is
 received, the node drops the push peer that sent the prune. Prune is an
 indication that there is another, higher stake weighted path to that node than
@@ -133,6 +133,6 @@ The main differences are:
 - Push messages have a wallclock that is signed by the originator. Once the
   wallclock expires the message is dropped. A hop limit is difficult to
   implement in an adversarial setting.
-- Lazy Push is not implemented because its not obvious how to prevent an
+- Lazy Push is not implemented because it's not obvious how to prevent an
   adversary from forging the message fingerprint. A naive approach would allow
   an adversary to be prioritized for pull based on their input.
diff --git a/docs/src/validator/runtime.md b/docs/src/validator/runtime.md
index 48fa7f041b47f3..2bf8a52563f88b 100644
--- a/docs/src/validator/runtime.md
+++ b/docs/src/validator/runtime.md
@@ -28,9 +28,9 @@ At the _execute_ stage, the loaded accounts have no data dependencies, so all th
 The runtime enforces the following rules:
 
 1. Only the _owner_ program may modify the contents of an account. This means that upon assignment data vector is guaranteed to be zero.
-2. Total balances on all the accounts is equal before and after execution of a transaction.
+2. Total balances on all the accounts are equal before and after execution of a transaction.
 3. After the transaction is executed, balances of read-only accounts must be equal to the balances before the transaction.
-4. All instructions in the transaction executed atomically. If one fails, all account modifications are discarded.
+4. All instructions in the transaction are executed atomically. If one fails, all account modifications are discarded.
 
 Execution of the program involves mapping the program's public key to an entrypoint which takes a pointer to the transaction, and an array of loaded accounts.
 
diff --git a/geyser-plugin-interface/README.md b/geyser-plugin-interface/README.md
index 761601d0dc4be1..864a914fdc643d 100644
--- a/geyser-plugin-interface/README.md
+++ b/geyser-plugin-interface/README.md
@@ -6,10 +6,10 @@
 
 # Solana Geyser Plugin Interface
 
-This crate enables an plugin to be added into the Solana Validator runtime to
+This crate enables a plugin to be added into the Solana Validator runtime to
 take actions at the time of account updates or block and transaction processing;
 for example, saving the account state to an external database. The plugin must
-implement the `GeyserPlugin` trait. Please see the detail of the
+implement the `GeyserPlugin` trait. Please see the details of the
 `geyser_plugin_interface.rs` for the interface definition.
 
 The plugin should produce a `cdylib` dynamic library, which must expose a `C`
@@ -18,7 +18,7 @@ interface.
 
 The https://github.com/solana-labs/solana-accountsdb-plugin-postgres repository
 provides an example of how to create a plugin which saves the accounts data into
-an external PostgreSQL databases.
+an external PostgreSQL database.
 
 More information about Solana is available in the [Solana documentation](https://docs.solana.com/).
 
diff --git a/metrics/README.md b/metrics/README.md
index db9eb8f1036b49..f1890aacc308fe 100644
--- a/metrics/README.md
+++ b/metrics/README.md
@@ -4,10 +4,10 @@
 
 ## InfluxDB
 
-In oder to explore validator specific metrics from mainnet-beta, testnet or devnet you can use Chronograf:
+In order to explore validator specific metrics from mainnet-beta, testnet or devnet you can use Chronograf:
 
-* https://metrics.solana.com:8888/ (production enviroment)
-* https://metrics.solana.com:8889/ (testing enviroment)
+* https://metrics.solana.com:8888/ (production environment)
+* https://metrics.solana.com:8889/ (testing environment)
 
 For local cluster deployments you should use:
 
@@ -47,4 +47,4 @@ The fee market dashboard shows:
 
 ### Ping Results
 
-The ping reults dashboard displays relevant information about the Ping API
+The ping results dashboard displays relevant information about the Ping API
diff --git a/net/README.md b/net/README.md
index 70953a44f0d68d..a3dd929fcf40b7 100644
--- a/net/README.md
+++ b/net/README.md
@@ -43,7 +43,7 @@ $ ./gce.sh delete               #<-- Dispose of the network (billing stops here)
 
 ### Running the network over public IP addresses
 By default private IP addresses are used with all instances in the same
-availability zone to avoid GCE network engress charges.  However to run the
+availability zone to avoid GCE network egress charges. However to run the
 network over public IP addresses:
 ```bash
 $ ./gce.sh create -P ...