docs: fix all misspellings

Author: 0xClandestine

certora/specs/core/Slasher.spec

@@ -142,7 +142,7 @@ invariant listHeadHasSmallestValueOfLatestUpdateBlock(address operator, uint256
 TODO: rule doesn't pass. We've got separate rules for checking the LinkedList lib properties.
 key properties seem to be that
 1) `StructuredLinkedList._createLink` creates only two-way links
-2) `StructuredLinkedList.remove` removes both links from a node, and stiches together its existing links (which it breaks)
+2) `StructuredLinkedList.remove` removes both links from a node, and stitches together its existing links (which it breaks)
 3) `StructuredLinkedList._insert` similarly inserts a new node 'between' nodes, ensuring that the new node is well-linked
 invariant consistentListStructure(address operator, uint256 node1)
 	(

certora/specs/libraries/StructuredLinkedList.spec

@@ -134,7 +134,7 @@ invariant headInList(uint256 node)
 
 /*
 1) `StructuredLinkedList._createLink` creates only two-way links
-2) `StructuredLinkedList.remove` removes both links from a node, and stiches together its existing links (which it breaks)
+2) `StructuredLinkedList.remove` removes both links from a node, and stitches together its existing links (which it breaks)
 3) `StructuredLinkedList._insert` similarly inserts a new node 'between' nodes, ensuring that the new node is well-linked
 */
 /*

docs/README.md

@@ -92,7 +92,7 @@ See full documentation in [`/core/RewardsCoordinator.md`](./core/RewardsCoordina
 | -------- | -------- | -------- |
 | [`AVSDirectory.sol`](../src/contracts/core/AVSDirectory.sol) | Singleton | Transparent proxy |
 
-##### Note: This contract is left unchanged for backwards compatability. Operator<>AVS Registrations are to be replaced entirely with the `AllocationManager` and this contract will be deprecated in a future release.
+##### Note: This contract is left unchanged for backwards compatibility. Operator<>AVS Registrations are to be replaced entirely with the `AllocationManager` and this contract will be deprecated in a future release.
 
 Previously, the `AVSDirectory` handled interactions between AVSs and the EigenLayer core contracts. Once registered as an operator in EigenLayer core (via the `DelegationManager`), operators could register with one or more AVSs (via the AVS's contracts) to begin providing services to them offchain. As a part of registering with an AVS, the AVS would record this registration in the core contracts by calling into the `AVSDirectory`. As of the slashing release, this process is now managed by the [`AllocationManager`](#allocationmanager).
 

docs/core/AVSDirectory.md

@@ -18,7 +18,7 @@ Functionality is provided for AVSs to migrate from an pre-operatorSet registrati
 function becomeOperatorSetAVS() external;
 ```
 
-AVSs call this to become an operator set AVS. Once an AVS becomes an operator set AVS, they can no longer register operators via the legacy M2 registration path. This is a seperate function to help avoid accidental migrations to the operator set AVS model.
+AVSs call this to become an operator set AVS. Once an AVS becomes an operator set AVS, they can no longer register operators via the legacy M2 registration path. This is a separate function to help avoid accidental migrations to the operator set AVS model.
 
 ## `createOperatorSets`
 ```solidity
@@ -122,7 +122,7 @@ function forceDeregisterFromOperatorSets(
 
 Operators can use this function to deregister from an operator set without requiring the AVS to sign off on the deregistration. This function is intended to be used in cases where the AVS contracts are in a state that prevents operators from deregistering (either malicious or unintentional).
 
-Operators can also deallocate their slashable stake allocation seperately to avoid slashing risk, so this function is mainly for external integrations to interpret the correct state of the protocol.
+Operators can also deallocate their slashable stake allocation separately to avoid slashing risk, so this function is mainly for external integrations to interpret the correct state of the protocol.
 
 ## `updateAVSMetadataURI`
 ```solidity
@@ -142,4 +142,4 @@ This function allows an AVS to update the metadata URI associated with the AVS.
 
 ## View Functions
 
-See the [AVS Directory Inteface](../../../src/contracts/interfaces/IAVSDirectory.sol) for view functions. 
+See the [AVS Directory Interface](../../../src/contracts/interfaces/IAVSDirectory.sol) for view functions. 

docs/core/AllocationManager.md

@@ -463,7 +463,7 @@ _Note: this method can be called directly by an operator, or by a caller authori
 
 This function is called by an operator to EITHER increase OR decrease the slashable magnitude allocated from a strategy to an operator set. As input, the operator provides an operator set as the target, and a list of strategies and corresponding `newMagnitudes` to allocate. The `newMagnitude` value is compared against the operator's current `Allocation` for that operator set/strategy:
 * If `newMagnitude` is _greater than_ `Allocation.currentMagnitude`, this is an allocation
-* If `newMagnitude` is _less than_ `Allocation.currentMagnitude`, this is a dellocation
+* If `newMagnitude` is _less than_ `Allocation.currentMagnitude`, this is a deallocation
 * If `newMagnitude` is _equal to_ `Allocation.currentMagnitude`, this is invalid (revert)
 
 Allocation modifications play by different rules depending on a few factors. Recall that at all times, the `encumberedMagnitude` for a strategy may not exceed that strategy's `maxMagnitude`. Additionally, note that _before processing a modification for a strategy,_ the `deallocationQueue` for that strategy is first cleared. This ensures any completable deallocations are processed first, freeing up magnitude for allocation. This process is further explained in [`clearDeallocationQueue`](#cleardeallocationqueue). 
@@ -550,7 +550,7 @@ This queue contains a per-strategy ordered list of operator sets that, due to pr
 This method stops iterating when: the queue is empty, a deallocation is reached that cannot be completed yet, or when it has cleared `numToClear` entries from the queue.
 
 *Effects*:
-* For each `strategy` and _completeable_ deallocation in `deallocationQueue[operator][strategy]`:
+* For each `strategy` and _completable_ deallocation in `deallocationQueue[operator][strategy]`:
     * Pops the corresponding operator set from the `deallocationQueue`
     * Reduces `allocation.currentMagnitude` by the deallocated amount
     * Sets `allocation.pendingDiff` and `allocation.effectBlock` to 0
@@ -602,7 +602,7 @@ AVSs use slashing as a punitive disincentive for misbehavior. For details and ex
 
 In order to slash an eligible operator, the AVS specifies which operator set the operator belongs to, the `strategies` the operator should be slashed for, and for each strategy, the _proportion of the operator's allocated magnitude_ that should be slashed (given by `wadsToSlash`). An optional `description` string allows the AVS to add context to the slash.
 
-Once triggered in the `AllocationManager`, slashing is instant and irreversable. For each slashed strategy, the operator's `maxMagnitude` and `encumberedMagnitude` are decreased, and the allocation made to the given operator set has its `currentMagnitude` reduced. See [TODO - Accounting Doc]() for details on how slashed amounts are calculated.
+Once triggered in the `AllocationManager`, slashing is instant and irreversible. For each slashed strategy, the operator's `maxMagnitude` and `encumberedMagnitude` are decreased, and the allocation made to the given operator set has its `currentMagnitude` reduced. See [TODO - Accounting Doc]() for details on how slashed amounts are calculated.
 
 There are two edge cases to note for this method:
 1. In the process of slashing an `operator` for a given `strategy`, if the `Allocation` being slashed has a `currentMagnitude` of 0, the call will NOT revert. Instead, the `strategy` is skipped and slashing continues with the next `strategy` listed. This is to prevent an edge case where slashing occurs on or around a deallocation's `effectBlock` -- if the call reverted, the entire slash would fail. Skipping allows any valid slashes to be processed without requiring resubmission.

docs/core/DelegationManager.md

@@ -47,7 +47,7 @@ The `DelegationManager's` responsibilities can be broken down into the following
 The `DelegationManager` tracks operator-related state in the following mappings:
 
 ```solidity
-/// @notice Returns the `operator` a `staker` is delgated to, or address(0) if not delegated.
+/// @notice Returns the `operator` a `staker` is delegated to, or address(0) if not delegated.
 /// Note: operators are delegated to themselves
 mapping(address staker => address operator) public delegatedTo;
 
@@ -192,7 +192,7 @@ The `DelegationManager` tracks withdrawal-related state in the following mapping
  *
  * @param staker The address that queued the withdrawal
  * @param delegatedTo The address that the staker was delegated to at the time the withdrawal was queued. Used to determine if additional slashing occurred before
- * this withdrawal became completeable.
+ * this withdrawal became completable.
  * @param withdrawer The address that will call the contract to complete the withdrawal. Note that this will always equal `staker`; alternate withdrawers are not
  * supported at this time.
  * @param nonce The staker's `cumulativeWithdrawalsQueued` at time of queuing. Used to ensure withdrawals have unique hashes.
@@ -464,7 +464,7 @@ struct QueuedWithdrawalParams {
  * to slashing. If any slashing has occurred, the shares received may be less than the queued deposit shares.
  *
  * @dev To view all the staker's strategies/deposit shares that can be queued for withdrawal, see `getDepositedShares`
- * @dev To view the current coversion between a staker's deposit shares and withdrawable shares, see `getWithdrawableShares`
+ * @dev To view the current conversion between a staker's deposit shares and withdrawable shares, see `getWithdrawableShares`
  */
 function queueWithdrawals(
     QueuedWithdrawalParams[] calldata queuedWithdrawalParams
@@ -518,7 +518,7 @@ Note that the `QueuedWithdrawalParams.__deprecated_withdrawer` field is ignored.
  *
  * @param staker The address that queued the withdrawal
  * @param delegatedTo The address that the staker was delegated to at the time the withdrawal was queued. Used to determine if additional slashing occurred before
- * this withdrawal became completeable.
+ * this withdrawal became completable.
  * @param withdrawer The address that will call the contract to complete the withdrawal. Note that this will always equal `staker`; alternate withdrawers are not
  * supported at this time.
  * @param nonce The staker's `cumulativeWithdrawalsQueued` at time of queuing. Used to ensure withdrawals have unique hashes.
@@ -661,7 +661,7 @@ This method is called by the `AllocationManager` when processing an AVS's slash
 
 Additionally, any _slashable shares_ in the withdrawal queue are marked for burning according to the same slashing proportion (shares in the withdrawal queue remain slashable for `MIN_WITHDRAWAL_DELAY_BLOCKS`). For the slashed strategy, the corresponding share manager (`EigenPodManager/StrateyManager`) is called, increasing the burnable shares for that strategy.
 
-**Note**: native ETH does not currently posess a burning mechanism, as this requires Pectra to be able to force exit validators. Currently, slashing for the `beaconChainETHStrategy` is realized by modifying the amount stakers are able to withdraw.
+**Note**: native ETH does not currently possess a burning mechanism, as this requires Pectra to be able to force exit validators. Currently, slashing for the `beaconChainETHStrategy` is realized by modifying the amount stakers are able to withdraw.
 
 *Effects*:
 * The `operator's` `operatorShares` are reduced for the given `strategy`, according to the proportion given by `prevMaxMagnitude` and `newMaxMagnitude`

docs/core/RewardsCoordinator.md

@@ -43,7 +43,7 @@ This document is organized according to the following themes (click each to be t
     * Stakers and Operators can designate a "claimer" who can claim rewards via on their behalf via `processClaim`. If a claimer is not set in `claimerFor`, the earner will have to call `processClaim` themselves.
     * Note that the claimer isn't necessarily the reward recipient, but they do have the authority to specify the recipient when calling `processClaim` on the earner's behalf.
 * `mapping(address => mapping(IERC20 => uint256)) public cumulativeClaimed`: earner => token => total amount claimed to date
-    * Mapping for earners(Stakers/Operators) to track their total claimed earnings per reward token. This mapping is used to calculate the difference between the cumulativeEarnings stored in the merkle tree and the previous total claimed amount. This difference is then transfered to the specified destination address.
+    * Mapping for earners(Stakers/Operators) to track their total claimed earnings per reward token. This mapping is used to calculate the difference between the cumulativeEarnings stored in the merkle tree and the previous total claimed amount. This difference is then transferred to the specified destination address.
 * `uint16 public defaultOperatorSplitBips`: *Used off-chain* by the rewards updater to calculate an Operator's split for a specific reward.
     * This is expected to be a flat 10% rate for the initial rewards release. Expressed in basis points, this is `1000`.
 * `mapping(address => mapping(address => OperatorSplit)) internal _operatorAVSSplitBips`: operator => AVS => `OperatorSplit`
@@ -58,7 +58,7 @@ This document is organized according to the following themes (click each to be t
 * **AVS** (Autonomous Verifiable Service) refers to the contract entity that is submitting rewards to the `RewardsCoordinator`.
   * This is assumed to be a customized `ServiceManager` contract of some kind that is interfacing with the EigenLayer protocol. See the `ServiceManagerBase` docs here: [`eigenlayer-middleware/docs/ServiceManagerBase.md`](https://github.com/Layr-Labs/eigenlayer-middleware/blob/dev/docs/ServiceManagerBase.md).
 * An **Operator Set** refers to a collection of registered operators and strategies. See [ELIP-002](https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-002.md#operator-sets) for more details.
-* An **Operator Set Key** descibes the tuple of an AVS address and an ID that uniquely identifies an Operator Set. See the [AllocationManager](./AllocationManager.md#operator-sets) for details.
+* An **Operator Set Key** describes the tuple of an AVS address and an ID that uniquely identifies an Operator Set. See the [AllocationManager](./AllocationManager.md#operator-sets) for details.
 * A **rewards submission** includes, unless specified otherwise, both the v1 `RewardsSubmission` and the v2 `OperatorDirectedRewardsSubmission` types.
 * The internal function `_checkClaim(RewardsMerkleClaim calldata claim, DistributionRoot memory root)` checks the merkle inclusion of a claim against a `DistributionRoot`
     * It reverts if any of the following are true:

docs/core/accounting/SharesAccountingEdgeCases.md

@@ -32,7 +32,7 @@ Note that in the first case, it _is_ possible for the staker to undelegate, queu
 
 Additionally, if $l_n = 0$ for a given staker in the beacon chain ETH strategy, then **any further deposits of ETH or restaking of validators will not yield shares in EigenLayer.** This should only occur in extraordinary circumstances, as a beacon chain slashing factor of 0 means that a staker both has ~0 assets in their `EigenPod`, and ALL of their validators have been ~100% slashed on the beacon chain - something that happens only when coordinated groups of validators are slashed. If this case occurs, an `EigenPod` is essentially bricked - the pod owner should NOT send ETH to the pod, and should NOT point additional validators at the pod.
 
-These are all expected edge cases and their occurances and side effects are within acceptable tolerances.
+These are all expected edge cases and their occurrences and side effects are within acceptable tolerances.
 
 ## Upper Bound on Deposit Scaling Factor $k_n$
 

package.json

@@ -1,7 +1,7 @@
 {
   "name": "eigenlayer-contracts",
   "version": "1.0.0",
-  "description": "<a name=\"introduction\"/></a> # EigenLayer EigenLayer (formerly 'EigenLayr') is a set of smart contracts deployed on Ethereum that enable restaking of assets to secure new services. At present, this repository contains *both* the contracts for EigenLayer *and* a set of general \"middleware\" contracts, designed to be reuseable across different applications built on top of EigenLayer.",
+  "description": "<a name=\"introduction\"/></a> # EigenLayer EigenLayer (formerly 'EigenLayr') is a set of smart contracts deployed on Ethereum that enable restaking of assets to secure new services. At present, this repository contains *both* the contracts for EigenLayer *and* a set of general \"middleware\" contracts, designed to be reusable across different applications built on top of EigenLayer.",
   "main": "index.js",
   "directories": {
     "doc": "docs",

script/deploy/devnet/deploy_from_scratch.s.sol

@@ -330,7 +330,7 @@ contract DeployFromScratch is Script, Test {
         // Create a proxy beacon for base strategy implementation
         strategyBeacon = new UpgradeableBeacon(address(baseStrategyImplementation));
 
-        // Strategy Factory, upgrade and initalized
+        // Strategy Factory, upgrade and initialized
         eigenLayerProxyAdmin.upgradeAndCall(
             ITransparentUpgradeableProxy(payable(address(strategyFactory))),
             address(strategyFactoryImplementation),