fix: patch (#956)

feat: bindings (#960) fix: remove numtocomplete interface (#966) feat: add share helpers (#964) * feat: add share helpers * fix: add deposit scaling factor * fix: rebase fix: slashable window boundaries (#965) * fix: slashable window boundaries * test: regression for alm * test: update withdrawal delay not passed reversion * test: burning indices * refactor: switch conditionals * fix: added unit tests * test: assert slashable shares in queue * fix: typos --------- Co-authored-by: Yash Patil <[email protected]> refactor: small cleanup (#959) refactor small cleanup chore: `forge fmt` fix: `getQueuedWithdrawals` + test fix: add constructor back test: `totalQueued` > `withdrawal.strategies.length` test(wip): `completeQueuedWithdrawals` currently failing fix: effectBlock test(wip): @8sunyuan patch fix: one flaky test fix: second flaky test refactor: remove max strats list (#968) feat: slashing patch upgrade script (#967) * feat: initial deploy * feat: slashing patch fix non-present upgrade.json chore: bindings (#969) fix: try catch out of gas edge case (#971) chore: slashing consolidated script (#972) test: more slashing integration todos (#961) * test(wip): todos * fix: dealloc issue * fix: remaining * fix: forktest upgrade issue * test: add `check_Withdrawal_AsShares_State_AfterSlash` * refactor: cleanup * fix: ci * refactor: review changes docs: wip slashing docs (#925) * docs: add slashing docs * chore: bindings * docs: fixed commenting and updated queue withdrawal docs * docs: minor cleanup --------- Co-authored-by: Nadir Akhtar <[email protected]> refactor: scaled shares accounting (#975) * fix: correct expected share calc * chore: bindings * fix: rounding on failing unit test refactor: final slashing cleanup (#982) * chore: clean comments and naming in dm * refactor: simplify undelegate method * feat: removed 0 address check because 0 stakers cant be delegated * feat: condensed non-staker caller logic * refactor: remove unnecessary check * feat: use checks-effects-interactions when completing withdrawals * feat: remove implicit public method for queuedWithdrawals and impl dedicated getter * feat: deprecate withdrawer field * chore: make bindings and clean compile errors * refactor: redelegate reuses delegateTo and undelegate * fix: broken integration test * docs: update to reflect deprecated field * feat: add getter for stakers withdrawal roots chore: remove unused avsd events (#984) fix: integration test initialization params (#978) * fix: initialization params * fix: roll blocks usage fix: `SignatureUtils` construction (#990) * fix: integration test initialization params (#978) * fix: initialization params * fix: roll blocks usage * fix: `SignatureUtils` construction --------- Co-authored-by: Yash Patil <[email protected]> Co-authored-by: davidironblocks <[email protected]> fix: readd manual checks (#996) * fix: readd manual checks * chore: forge fmt feat: slashing 1.0.3 upgrade script (#995) * feat: add step 1 * feat: step 1 & 2 complete; pending step 3 sanity * test: add `_validateProxyDomainSeparators` * feat: add rc validation --------- Co-authored-by: clandestine.eth <[email protected]> fix: update alloc config delay bound (#985) * fix: update alloc delay bound * test: remove unnecessary roll chore: storage report (#1000) docs: shares accounting (#997) * docs: shares accounting * docs: fix gh markdown view * docs: try fix gh again * docs: cleanup * docs: edit share accounting * docs: wrap up share accounting doc * docs: edit edge cases --------- Co-authored-by: wadealexc <[email protected]> refactor: async burning (#1001) * refactor: burning * chore: fmt * chore: update storage report * chore: update readme * refactor: add burnableShares for epm storage * chore: update storage report test: `Snapshots` lib (#1002) docs: finish delegation manager docs (#1004) * docs: finish delegation manager docs * docs: update docs readme * docs: permission controller * fix: small typos * docs: address feedback * docs: nit --------- Co-authored-by: Michael Sun <[email protected]> docs: Strategy Manager slashing updates (#999) * docs: update StrategyManager docs with slashing delta * docs: remove references to thirdPartyTransfersForbidden * docs: update strategy docs to latest * also various edits to docs and natspec * chore: fmt and make bindings --------- Co-authored-by: wadealexc <[email protected]> docs: EigenPod Manager slashing updates (#1005) * docs: complete EigenPodManager for slashing * docs: add in _beaconChainSlashingFactor state variable note * docs: finish epm docs * chore: make bindings --------- Co-authored-by: wadealexc <[email protected]>
Layr-Labs · Jan 29, 2025 · 079c8e8 · 079c8e8
1 parent f96461e
commit 079c8e8
Show file tree

Hide file tree

Showing 156 changed files with 20,456 additions and 4,661 deletions.
diff --git a/README.md b/README.md
@@ -102,6 +102,14 @@ surya mdreport surya_report.md ./src/contracts/**/*.sol
 make bindings
 ```
 
+### Generate updated Storage Report
+
+To update the storage reports in `/docs/storage-report` run:
+
+```bash
+make storage-report
+```
+
 ## Deployments
 
 ### Current Mainnet Deployment

diff --git a/docs/README.md b/docs/README.md
@@ -1,10 +1,11 @@
 [middleware-repo]: https://github.com/Layr-Labs/eigenlayer-middleware/
+[elip-002]: https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-002.md
 
-## EigenLayer Docs - v0.4.0 Release
+## EigenLayer Docs - v1.0.0 Release
 
-This repo contains the EigenLayer core contracts, which enable restaking of liquid staking tokens (LSTs) and beacon chain ETH to secure new services, called AVSs (actively validated services). For more info on AVSs, check out the EigenLayer middleware contracts [here][middleware-repo].
+This repo contains the EigenLayer core contracts, which enable restaking of liquid staking tokens (LSTs), beacon chain ETH, and permissionlessly deployed ERC20 Strategies to secure new services called AVSs (actively validated services). For more info on AVSs, check out the EigenLayer middleware contracts [here][middleware-repo].
 
-This document provides an overview of system components, contracts, and user roles. Further documentation on the major system contracts can be found in [/core](./core/).
+This document provides an overview of system components, contracts, and user roles and is up-to-date with the latest [ELIP-002][elip-002]. Further documentation on the major system contracts can be found in [/core](./core/).
 
 #### Contents
 
@@ -14,7 +15,8 @@ This document provides an overview of system components, contracts, and user rol
     * [`DelegationManager`](#delegationmanager)
     * [`RewardsCoordinator`](#rewardscoordinator)
     * [`AVSDirectory`](#avsdirectory)
-    * [`Slasher`](#slasher)
+    * [`AllocationManager`](#allocationmanager)
+    * [`PermissionController`](#permissioncontroller)
 * [Roles and Actors](#roles-and-actors)
 * [Common User Flows](#common-user-flows)
     * [Depositing Into EigenLayer](#depositing-into-eigenlayer)
@@ -53,7 +55,7 @@ See full documentation in:
 These contracts work together to enable restaking for ERC20 tokens supported by EigenLayer:
 * The `StrategyManager` acts as the entry and exit point for any supported tokens in EigenLayer. It handles deposits into LST-specific strategies, and manages accounting+interactions between users with restaked LSTs and the `DelegationManager`.
 * `StrategyFactory` allows anyone to deploy strategies to support deposits/withdrawals for new ERC20 tokens
-* `StrategyBaseTVLLimits` is deployed as multiple separate instances, one for each supported token. When a user deposits into a strategy through the `StrategyManager`, this contract receives the tokens and awards the user with a proportional quantity of shares in the strategy. When a user withdraws, the strategy contract sends the LSTs back to the user.
+* `StrategyBaseTVLLimits` is deployed as multiple separate instances, one for each supported token. When a user deposits into a strategy through the `StrategyManager`, this contract receives the tokens and awards the user with a proportional quantity of deposit shares in the strategy. When a user withdraws, the strategy contract sends the LSTs back to the user.
 
 See full documentation in [`/core/StrategyManager.md`](./core/StrategyManager.md).
 
@@ -63,9 +65,13 @@ See full documentation in [`/core/StrategyManager.md`](./core/StrategyManager.md
 | -------- | -------- | -------- |
 | [`DelegationManager.sol`](../src/contracts/core/DelegationManager.sol) | Singleton | Transparent proxy |
 
-The `DelegationManager` sits between the `EigenPodManager` and `StrategyManager` to manage delegation and undelegation of Stakers to Operators. Its primary features are to allow Operators to register as Operators (`registerAsOperator`), to keep track of shares being delegated to Operators across different strategies, and to manage withdrawals on behalf of the `EigenPodManager` and `StrategyManager`.
+The `DelegationManager` sits between the `EigenPodManager` and `StrategyManager` to manage delegation and undelegation of stakers to operators. Its primary features are to allow users to become operators, to keep track of delegated shares to operators across different strategies, and to manage withdrawals on behalf of stakers via the `EigenPodManager` and `StrategyManager`.
 
-See full documentation in [`/core/DelegationManager.md`](./core/DelegationManager.md).
+The `DelegationManager` is tightly coupled with the `AllocationManager`. The `DelegationManager` ingests information about slashing as part of managing share accounting for stakers whose operators have been slashed. It also receives directives to slash/burn operator shares when an AVS slashes an operator.
+
+See:
+* full documentation in [`/core/DelegationManager.md`](./core/DelegationManager.md)
+* share accounting documentation in [`/core/accounting/SharesAccounting.md`](./core/accounting/SharesAccounting.md)
 
 #### RewardsCoordinator
 
@@ -74,9 +80,9 @@ See full documentation in [`/core/DelegationManager.md`](./core/DelegationManage
 | [`RewardsCoordinator.sol`](../src/contracts/core/RewardsCoordinator.sol) | Singleton | Transparent proxy |
 
 The `RewardsCoordinator` is the main entry point of submission and claiming of ERC20 rewards in EigenLayer. It carries out three basic functions:
-* AVSs (via the AVS's contracts) submit "rewards submissions" to their registered Operators and Stakers over a specific time period 
-* *Off-chain*, the rewards updater will use each RewardsSubmission time period to apply reward amounts to historical Staker/Operator stake weights. This is consolidated into a merkle root that is posted *on-chain* to the `RewardsCoordinator`, allowing Stakers/Operators to claim their allocated rewards.
-* Stakers/Operators can claim rewards posted by the rewards updater.
+* AVSs (via the AVS's contracts) submit "rewards submissions" to their registered operators and stakers over a specific time period 
+* *Off-chain*, the rewards updater will use each RewardsSubmission time period to apply reward amounts to historical staker/operator stake weights. This is consolidated into a merkle root that is posted *on-chain* to the `RewardsCoordinator`, allowing stakers/operators to claim their allocated rewards.
+* Stakers/operators can claim rewards posted by the rewards updater.
 
 See full documentation in [`/core/RewardsCoordinator.md`](./core/RewardsCoordinator.md).
 
@@ -86,21 +92,42 @@ See full documentation in [`/core/RewardsCoordinator.md`](./core/RewardsCoordina
 | -------- | -------- | -------- |
 | [`AVSDirectory.sol`](../src/contracts/core/AVSDirectory.sol) | Singleton | Transparent proxy |
 
-The `AVSDirectory` handles interactions between AVSs and the EigenLayer core contracts. Once registered as an Operator in EigenLayer core (via the `DelegationManager`), Operators can 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 will record this registration in the core contracts by calling into the `AVSDirectory`.
+##### 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.
+
+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).
 
 See full documentation in [`/core/AVSDirectory.md`](./core/AVSDirectory.md).
 
 For more information on AVS contracts, see the [middleware repo][middleware-repo].
 
-#### Slasher
+#### AllocationManager
+
+| File | Type | Proxy |
+| -------- | -------- | -------- |
+| [`AllocationManager.sol`](../src/contracts/core/AllocationManager.sol) | Singleton | Transparent proxy |
+
+The `AllocationManager` is replaces the AVSDirectory with the introduction of _operator sets_ and slashing. It handles several use cases:
+* AVSs can create operator sets and can define the EigenLayer Strategies within them
+* Operators can register to or deregister from an AVS's operator sets
+* Operators can make slashable security commitments to an operator set by allocating a proportion of their total delegated stake for a Strategy to be slashable. Ex. As an operator, I can allocate 50% of my delegated stETH to be slashable by a specific operator set
+* AVSs can slash an operator who has allocated to and is registered for one of the AVS's operator sets
+
+See full documentation in [`/core/AllocationManager.md`](./core/AllocationManager.md).
+
+#### PermissionController
 
 | File | Type | Proxy |
 | -------- | -------- | -------- |
-| [`Slasher.sol`](../src/contracts/core/Slasher.sol) | - | - |
+| [`PermissionController.sol`](../src/contracts/permissions/PermissionController.sol) | Singleton | Transparent proxy |
+
+The `PermissionController` allows AVSs and operators to delegate the ability to call certain core contract functions to other addresses. This delegation ability is not available to stakers, and is not available in ALL core contract functions.
 
-<p align="center"><b>
-🚧 The Slasher contract is under active development and its interface expected to change. We recommend writing slashing logic without integrating with the Slasher at this point in time. Although the Slasher is deployed, it will remain completely paused/unusable during M2. No contracts interact with it, and its design is not finalized. 🚧
-</b><p>
+The following core contracts use the `PermissionController` in certain methods:
+* `DelegationManager`
+* `AllocationManager`
+* `RewardsCoordinator`
+
+See full documentation in [`/permissions/PermissionController.md`](./permissions/PermissionController.md).
 
 ---
 
@@ -110,39 +137,33 @@ To see an example of the user flows described in this section, check out our int
 
 ##### Staker
 
-A Staker is any party who has assets deposited (or "restaked") into EigenLayer. Currently, these assets can be:
+A staker is any party who has assets deposited (or "restaked") into EigenLayer. Currently, these assets can be:
 * Native beacon chain ETH (via the EigenPodManager)
-* Liquid staking tokens (via the StrategyManager): cbETH, rETH, stETH, ankrETH, OETH, osETH, swETH, wBETH
+* Arbitrary ERC20s (via the StrategyManager)
 
-Stakers can restake any combination of these: a Staker may hold ALL of these assets, or only one of them.
+Stakers can restake any combination of these: a staker may hold ALL of these assets, or only one of them.
 
 *Flows:*
-* Stakers **deposit** assets into EigenLayer via either the StrategyManager (for LSTs) or EigenPodManager (for beacon chain ETH)
+* Stakers **deposit** assets into EigenLayer via either the StrategyManager (for ERC20s) or the EigenPodManager (for beacon chain ETH)
 * Stakers **withdraw** assets via the DelegationManager, *no matter what assets they're withdrawing*
-* Stakers **delegate** to an Operator via the DelegationManager
-
-*Unimplemented as of v0.4.0:*
-* Stakers are at risk of being slashed if the Operator misbehaves
+* Stakers **delegate** to an operator via the DelegationManager
 
 ##### Operator
 
-An Operator is a user who helps run the software built on top of EigenLayer (AVSs). Operators register in EigenLayer and allow Stakers to delegate to them, then opt in to provide various services built on top of EigenLayer. Operators may themselves be Stakers; these are not mutually exclusive.
+An operator is a user who helps run the software built on top of EigenLayer (AVSs). operators register in EigenLayer and allow stakers to delegate to them, then opt in to provide various services built on top of EigenLayer. operators may themselves be stakers; these are not mutually exclusive.
 
 *Flows:*
-* User can **register** as an Operator via the DelegationManager
-* Operators can **deposit** and **withdraw** assets just like Stakers can
+* Users 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 more details.
 
-*Unimplemented as of v0.4.0:*
-* Operators may be slashed by the services they register with (if they misbehave)
-
 ---
 
 #### Common User Flows
 
 ##### Depositing Into EigenLayer
 
-Depositing into EigenLayer varies depending on whether the Staker is depositing Native ETH or LSTs:
+Depositing into EigenLayer varies depending on whether the staker is depositing Native ETH or LSTs:
 
 ![.](./images/Staker%20Flow%20Diagrams/Depositing.png)
 
@@ -152,13 +173,13 @@ Depositing into EigenLayer varies depending on whether the Staker is depositing
 
 ##### Undelegating or Queueing a Withdrawal
 
-Undelegating from an Operator automatically queues a withdrawal that needs to go through the `DelegationManager's` withdrawal delay. Stakers that want to withdraw can choose to `undelegate`, or can simply call `queueWithdrawals` directly.
+Undelegating from an operator automatically queues a withdrawal that needs to go through the `DelegationManager's` withdrawal delay. Stakers that want to withdraw can choose to `undelegate`, or can simply call `queueWithdrawals` directly.
 
 ![.](./images/Staker%20Flow%20Diagrams/Queue%20Withdrawal.png)
 
 ##### Completing a Withdrawal as Shares
 
-This flow is mostly useful if a Staker wants to change which Operator they are delegated to. The Staker first needs to undelegate (see above). At this point, they can delegate to a different Operator. However, the new Operator will only be awarded shares once the Staker completes their queued withdrawal "as shares":
+This flow is mostly useful if a staker wants to change which operator they are delegated to. The staker first needs to undelegate (see above). At this point, they can delegate to a different operator. However, the new operator will only be awarded shares once the staker completes their queued withdrawal "as shares":
 
 ![.](./images/Staker%20Flow%20Diagrams/Complete%20Withdrawal%20as%20Shares.png)
 
@@ -172,12 +193,12 @@ However, note that *before* a withdrawal can be completed, native ETH stakers wi
 
 ##### `EigenPods`: Processing Validator Exits
 
-If a Staker wants to fully withdraw from the beacon chain, they need to perform these additional steps before their withdrawal is completable:
+If a staker wants to fully withdraw from the beacon chain, they need to perform these additional steps before their withdrawal is completable:
 
 ![.](./images/Staker%20Flow%20Diagrams/Validator%20Exits.png)
 
 ##### `EigenPods`: Processing Validator Yield
 
-As the Staker's `EigenPod` accumulates consensus layer or execution layer yield, the `EigenPod's` balance will increase. The Staker can Checkpoint their validator to claim this yield as shares, which can either remain staked in EigenLayer or be withdrawn via the `DelegationManager` withdrawal queue:
+As the staker's `EigenPod` accumulates consensus layer or execution layer yield, the `EigenPod's` balance will increase. The staker can Checkpoint their validator to claim this yield as shares, which can either remain staked in EigenLayer or be withdrawn via the `DelegationManager` withdrawal queue:
 
 ![.](./images/Staker%20Flow%20Diagrams/Validator%20Yield.png)