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
**Motivation:**
Fixes an issue where stakers delegating Beacon Chain ETH from slashed
Eigen Pods were able to delegate more shares than they should.
Specifically, operators now are delegated a staker's
`withdrawableShares` rather than their `depositShares`.
**Modifications:**
- Changed accounting logic on delegation in `DelegationManger.sol`
- `DepositScalingFactor` now resets when a staker withdraws all their
shares, whether through undelegation, redelegation, or a simple
withdrawal
- Changes in `StrategyManager.sol`, `IShareManager.sol`,
`SlashingLib.sol`, and `EigenPodManager.sol` to accommodate new
accounting
- New test files and changes to others to reflect new accounting and
invariants
- Updated `docs/SharesAccounting.md`
**Result:**
System is now robust to stakers with arbitrary EigenPod states
---------
Co-authored-by: Michael <michael@Michaels-MacBook-Pro.local>
Co-authored-by: Michael Sun <michaelsun97@gmail.com>
Co-authored-by: wadealexc <pragma-services@proton.me>
Co-authored-by: Yash Patil <40046473+ypatil12@users.noreply.github.com>
Co-authored-by: clandestine.eth <96172957+0xClandestine@users.noreply.github.com>
Suppose we have an undelegated staker who decides to delegate to an operator.
171
+
We have the following properties that should be preserved.
172
+
173
+
#### Operator Level
174
+
175
+
Operator shares should be increased by the amount of delegatable shares the staker has, this is synonymous to their withdrawable shares $a_n$. Therefore,
176
+
177
+
$$
178
+
op_{n+1} = op_{n} + a_n
179
+
$$
180
+
181
+
$$
182
+
= op_{n} + s_n k_n l_n m_n
183
+
$$
184
+
185
+
186
+
#### Staker Level
187
+
188
+
withdrawable shares should remain unchanged
189
+
190
+
$$
191
+
a_{n+1} = a_n
192
+
$$
193
+
194
+
deposit shares should remain unchanged
195
+
196
+
$$
197
+
s_{n+1} = s_n
198
+
$$
199
+
200
+
beaconChainSlashingFactor and maxMagnitude should also remain unchanged. In this case, since the staker is not delegated, then their maxMagnitude should by default be equal to 1.
201
+
202
+
$$
203
+
l_{n+1} = l_n
204
+
$$
205
+
206
+
Now the question is what is the new depositScalingFactor equal to?
Notice how the staker variables that update $k_{n+1}$ and $m_{n+1}$ do not affect previously queued withdrawals and shares received upon withdrawal completion. This is because the maxMagnitude that is looked up is dependent on the operator at the time of the queued withdrawal and the $k_n$ is effectively stored in the scaled shares field.
225
+
165
226
---
166
227
167
228
### Slashing
@@ -297,6 +358,8 @@ $$
297
358
298
359
Note that when a withdrawal is queued, a `Withdrawal` struct is created with _scaled shares_ defined as $q_t = x_t k_t$ where $t$ is the time of the queuing. The reason we define and store scaled shares like this will be clearer in [Complete Withdrawal](#complete-withdrawal) below.
299
360
361
+
Additionally, we reset the depositScalingFactor when a user queues a withdrawal for all their shares, either through un/redelegation or directly. This is because the DSF at the time of withdrawal is stored in the scaled shares, and any "new" deposits or delegations by the staker should be considered as new. Note that withdrawal completion is treated as a kind of deposit when done as shares, which again will be clearer below.
0 commit comments