You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 delegated shares to Operators across different strategies, and to manage withdrawals on behalf of the `EigenPodManager` and `StrategyManager`.
68
-
The `DelegationManager` is tightly coupled with the `AllocationManager` as withdrawable shares for a Staker is dependent on reading state from the `AllocationManager`. That is, a staker's withdrawable shares is decreased in the event their delegated Operator was slashed by an AVS (more specifically an operatorSet but more on this later).
68
+
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`.
69
69
70
-
See full documentation in [`/core/DelegationManager.md`](./core/DelegationManager.md).
70
+
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.
71
+
72
+
See:
73
+
* full documentation in [`/core/DelegationManager.md`](./core/DelegationManager.md)
74
+
* share accounting documentation in [`/core/accounting/SharesAccounting.md`](./core/accounting/SharesAccounting.md)
71
75
72
76
#### RewardsCoordinator
73
77
@@ -76,9 +80,9 @@ See full documentation in [`/core/DelegationManager.md`](./core/DelegationManage
The `RewardsCoordinator` is the main entry point of submission and claiming of ERC20 rewards in EigenLayer. It carries out three basic functions:
79
-
* AVSs (via the AVS's contracts) submit "rewards submissions" to their registered Operators and Stakers over a specific time period
80
-
**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.
81
-
* Stakers/Operators can claim rewards posted by the rewards updater.
83
+
* AVSs (via the AVS's contracts) submit "rewards submissions" to their registered operators and stakers over a specific time period
84
+
**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.
85
+
* Stakers/operators can claim rewards posted by the rewards updater.
82
86
83
87
See full documentation in [`/core/RewardsCoordinator.md`](./core/RewardsCoordinator.md).
84
88
@@ -88,9 +92,9 @@ See full documentation in [`/core/RewardsCoordinator.md`](./core/RewardsCoordina
##### 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(no longer indexed) in a future release.
95
+
##### 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.
92
96
93
-
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`.
97
+
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).
94
98
95
99
See full documentation in [`/core/AVSDirectory.md`](./core/AVSDirectory.md).
96
100
@@ -102,19 +106,28 @@ For more information on AVS contracts, see the [middleware repo][middleware-repo
The `AllocationManager` is meant to replace the AVSDirectory with the introduction of OperatorSets as well as introduce the core functionality of Slashing. It handles several use cases:
106
-
* AVSs can create OperatorSets and can define the EigenLayer Strategies within them
107
-
* Operators can register/deregister with AVS operatorSets
108
-
* Operators can make slashable security commitments to an operatorSet 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 stETH to be slashable by a specific OperatorSet
109
-
* AVSs can slash an operator (without being objectively attributable) who has slashable allocations to the AVS's corresponding OperatorSet.
109
+
The `AllocationManager` is replaces the AVSDirectory with the introduction of _operator sets_ and slashing. It handles several use cases:
110
+
* AVSs can create operator sets and can define the EigenLayer Strategies within them
111
+
* Operators can register to or deregister from an AVS's operator sets
112
+
* 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
113
+
* AVSs can slash an operator who has allocated to and is registered for one of the AVS's operator sets
110
114
111
115
See full documentation in [`/core/AllocationManager.md`](./core/AllocationManager.md).
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.
114
124
115
-
#### Shares Accounting
125
+
The following core contracts use the `PermissionController` in certain methods:
126
+
*`DelegationManager`
127
+
*`AllocationManager`
128
+
*`RewardsCoordinator`
116
129
117
-
TODO
130
+
See full documentation in [`/permissions/PermissionController.md`](./permissions/PermissionController.md).
118
131
119
132
---
120
133
@@ -124,39 +137,33 @@ To see an example of the user flows described in this section, check out our int
124
137
125
138
##### Staker
126
139
127
-
A Staker is any party who has assets deposited (or "restaked") into EigenLayer. Currently, these assets can be:
140
+
A staker is any party who has assets deposited (or "restaked") into EigenLayer. Currently, these assets can be:
128
141
* Native beacon chain ETH (via the EigenPodManager)
Stakers can restake any combination of these: a Staker may hold ALL of these assets, or only one of them.
144
+
Stakers can restake any combination of these: a staker may hold ALL of these assets, or only one of them.
132
145
133
146
*Flows:*
134
-
* Stakers **deposit** assets into EigenLayer via either the StrategyManager (for LSTs) or EigenPodManager (for beacon chain ETH)
147
+
* Stakers **deposit** assets into EigenLayer via either the StrategyManager (for ERC20s) or the EigenPodManager (for beacon chain ETH)
135
148
* Stakers **withdraw** assets via the DelegationManager, *no matter what assets they're withdrawing*
136
-
* Stakers **delegate** to an Operator via the DelegationManager
137
-
138
-
*Unimplemented as of v0.4.0:*
139
-
* Stakers are at risk of being slashed if the Operator misbehaves
149
+
* Stakers **delegate** to an operator via the DelegationManager
140
150
141
151
##### Operator
142
152
143
-
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.
153
+
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.
144
154
145
155
*Flows:*
146
-
*User can **register** as an Operator via the DelegationManager
147
-
* Operators can **deposit** and **withdraw** assets just like Stakers can
156
+
*Users can **register** as an operator via the DelegationManager
157
+
* Operators can **deposit** and **withdraw** assets just like stakers can
148
158
* 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.
149
159
150
-
*Unimplemented as of v0.4.0:*
151
-
* Operators may be slashed by the services they register with (if they misbehave)
152
-
153
160
---
154
161
155
162
#### Common User Flows
156
163
157
164
##### Depositing Into EigenLayer
158
165
159
-
Depositing into EigenLayer varies depending on whether the Staker is depositing Native ETH or LSTs:
166
+
Depositing into EigenLayer varies depending on whether the staker is depositing Native ETH or LSTs:
@@ -166,13 +173,13 @@ Depositing into EigenLayer varies depending on whether the Staker is depositing
166
173
167
174
##### Undelegating or Queueing a Withdrawal
168
175
169
-
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.
176
+
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.
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":
182
+
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":
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:
202
+
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:
0 commit comments