Documentation Fixes: Grammar, Typos, and Prepositions

docs/README.md

@@ -95,8 +95,8 @@ An Operator is a user who helps run the software built on top of EigenLayer (AVS
 *Flows:*
 * User can **register** as an Operator via the DelegationManager
 * Operators can **deposit** and **withdraw** assets just like Stakers can
-* Operators can opt in to providing services for an AVS using that AVS's middleware contracts. See the [EigenLayer middleware][middleware-repo] repo for now details.
+* Operators can opt in to providing services for an AVS using that AVS's middleware contracts. See the [EigenLayer middleware][middleware-repo] repo for more details.
 
 *Unimplemented as of M2:*
 * Operators earn fees as part of the services they provide
-* Operators may be slashed by the services they register with (if they misbehave)
+* Operators may be slashed by the services they register with (if they misbehave)

docs/core/EigenPodManager.md

@@ -42,7 +42,7 @@ The functions of the `EigenPodManager` and `EigenPod` contracts are tightly link
         * In some cases, a beacon chain balance update may cause a Staker's balance to drop below zero. This is because when queueing for a withdrawal in the `DelegationManager`, the Staker's current shares are fully removed. If the Staker's beacon chain balance drops after this occurs, their `podOwnerShares` may go negative. This is a temporary change to account for the drop in balance, and is ultimately corrected when the withdrawal is finally processed.
         * Since balances on the consensus layer are stored only in Gwei amounts, the EigenPodManager enforces the invariant that `podOwnerShares` is always a whole Gwei amount for every staker, i.e. `podOwnerShares[staker] % 1e9 == 0` always.
 * `EigenPod`:
-    * `_validatorPubkeyHashToInfo[bytes32] -> (ValidatorInfo)`: individual validators are identified within an `EigenPod` according the their public key hash. This mapping keeps track of the following for each validator:
+    * `_validatorPubkeyHashToInfo[bytes32] -> (ValidatorInfo)`: individual validators are identified within an `EigenPod` according to their public key hash. This mapping keeps track of the following for each validator:
         * `validatorStatus`: (`INACTIVE`, `ACTIVE`, `WITHDRAWN`)
         * `validatorIndex`: A `uint40` that is unique for each validator making a successful deposit via the deposit contract
         * `mostRecentBalanceUpdateTimestamp`: A timestamp that represents the most recent successful proof of the validator's effective balance

docs/core/proofs/BeaconChainProofs.md

@@ -6,7 +6,7 @@ However there is a way we can combine these proofs into a single proof.  This is
 
 The idea is simple, in a Merkle tree, every node has two children: left (or 0) and right (or 1). Starting from the root and moving down to a specific leaf, you can interpret each bit in the binary representation of the leaf's index as an instruction to traverse left (for 0) or right (for 1).  The length of a binary representation of an index is just `log(num_leaves) = height_of_the tree`.  
 
-Taking an example, lets say I had one merkle tree A who's Nth leaf was the root of merkle tree B.  So to calculate the index for the Mth leaf in B against the root of A, the index would be:
+Taking an example, let's say I had one merkle tree A whose Nth leaf was the root of merkle tree B.  So to calculate the index for the Mth leaf in B against the root of A, the index would be:
 `index_B_against_A = N << height_of_merkle_tree_B | M`.  In the image below, the blue nodes indicate the path we are trying to prove, the pink nodes are nodes in merkle tree B, which is a subtree of merkle tree A.
 
 ![Sample Merkle Tree](../../images/samplemerkle.png)