anza-xyz · jasmyhigh · Jan 20, 2025
diff --git a/docs/src/cli/examples/delegate-stake.md b/docs/src/cli/examples/delegate-stake.md
@@ -7,7 +7,7 @@ sidebar_label: Staking
 After you have [received SOL](./transfer-tokens.md), you might consider putting it
 to use by delegating _stake_ to a validator. Stake is what we call tokens in a
 _stake account_. Solana weights validator votes by the amount of stake delegated
-to them, which gives those validators more influence in determining then next
+to them, which gives those validators more influence in determining the next
 valid block of transactions in the blockchain. Solana then generates new SOL
 periodically to reward stakers and validators. You earn more rewards the more
 stake you delegate.

diff --git a/docs/src/consensus/stake-delegation-and-rewards.md b/docs/src/consensus/stake-delegation-and-rewards.md
@@ -178,7 +178,7 @@ custodian must also sign the transaction.
 
 - `account[0]` - RW - The StakeStateV2.
 
-  `StakeStateV2::authorized_staker` or `authorized_withdrawer` is set to to
+  `StakeStateV2::authorized_staker` or `authorized_withdrawer` is set to
   `Pubkey`.
 
 ### StakeInstruction::Deactivate

diff --git a/docs/src/implemented-proposals/ed_overview/ed_mvp.md b/docs/src/implemented-proposals/ed_overview/ed_mvp.md
@@ -12,7 +12,7 @@ been described above. We intend to fully engage with network stakeholders
 throughout the implementation phases \(i.e. pre-testnet, testnet, mainnet\)
 to ensure the system supports, and is representative of, the various network
 participants' interests. The first step toward this goal, however, is outlining
-a some desired MVP economic features to be available for early pre-testnet and
+some desired MVP economic features to be available for early pre-testnet and
 testnet participants. Below is a rough sketch outlining basic economic
 functionality from which a more complete and functional system can be developed.
 

diff --git a/docs/src/implemented-proposals/epoch_accounts_hash.md b/docs/src/implemented-proposals/epoch_accounts_hash.md
@@ -302,7 +302,7 @@ normal behavior.
 #### parent slot: `B`, warp slot: `B`
 
 A new EAH will be calculated at parent slot, which will be included in `stop
-slot 1`, _not_ the previously-calculated EAH from `start slot 1`.  This behaior
+slot 1`, _not_ the previously-calculated EAH from `start slot 1`.  This behavior
 is different.
 
 

diff --git a/docs/src/proposals/blockstore-rocksdb-compaction.md b/docs/src/proposals/blockstore-rocksdb-compaction.md
@@ -201,7 +201,7 @@ two different formats and panic.
 ## Single Node Benchmark Results
 To verify the effectiveness, I ran both 1m slots and 100m slots shred insertion
 benchmarks on my n2-standard-32 GC instance (32 cores 2800MHz cpu, 128GB memory,
-2048GB SSD).  Each slot contains 25 shreds, and the shreds are inserted with with
+2048GB SSD).  Each slot contains 25 shreds, and the shreds are inserted with
 8 writers.  Here are the summary of the result:
 
 * FIFO based validator: Shred insertion took 13450.8s, 185.8k shreds/s