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
Copy file name to clipboardExpand all lines: CHANGELOG/CHANGELOG-1.5.0.md
+10-8Lines changed: 10 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,19 +10,15 @@
10
10
11
11
- Redistribution is a feature that gives Service Builders a means to not just burn, but repurpose slashed funds.
12
12
- We introduce a new operatorSet creation mechanism: [`AllocationManager.createRedistributingOperatorSets`](../docs/core/AllocationManager.md#createredistributingoperatorsets), which allows slashed funds to be redistributed to a `RedistributionRecipient`. *Note: The redistribution recipient can be set only once and is immutable*.
13
-
-*All slashed funds will now be routed to individual `SlashEscrow` contracts.*The release of funds from escrow is gated by the `SlashEscrowFactory`. The `SlashEscrowFactory` deploys individual `SlashEscrow` contracts per slash, enforces a global delay for all escrowed funds, and handles pausing/unpausing of escrowed funds.
13
+
-*All slashed funds now follow a two-step process.*During a slash, we increase burn or redistributable shares. A cronjob then handles the actual redistribution or burning of these shares.
14
14
- The original `createOperatorSets` function still exists. This function creates operatorSets whose slashed funds will eventually be burned. There is no mechanism to convert an operatorSet to be redistributing.
15
15
- See [ELIP-006](https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-006.md) for a full description.
16
16
17
-
⛔ Breaking changes
18
-
- Funds marked for burning now go through a 4-day escrow period via `SlashEscrow` contracts. These funds are burned by calling [`SlashEscrowFactory.releaseSlashEscrow`](../docs/core/SlashEscrowFactory.md#releaseslashescrow).
19
-
20
17
📌 Future Deprecations
21
18
- The pre-redistribution burn pathway [`StrategyManager.decreaseBurnableShares`](../docs/core/StrategyManager.md#burnshares) will be deprecated in an upgrade *after* the redistribution release. This function can still be used to burn shares that have been slashed at any point prior to the redistribution upgrade.
22
19
23
20
🛠️ Security Updates
24
-
- The slashing of burned funds is no longer instantaneous. All slashed funds (burned or redistributed) now go through a 4-day escrow delay. The eventual burning or redistribution of slashed funds can be paused by the `PauserMultisig`.
25
-
- The upgradability of the `SlashEscrowFactory` is controlled by the `CommunityMultisig`. The contract will have a separate `ProxyAdmin` from the rest of the EigenLayer core protocol. Each individual `SlashEscrow` contract is an immutable clone.
21
+
- The slashing of burned funds is no longer instantaneous. All slashed funds (burned or redistributed) now go through a two-step process where shares are first marked for burning/redistribution, then processed by a cronjob. The burning or redistribution of slashed funds can be paused by the `PauserMultisig`.
26
22
27
23
🔧 Improvements
28
24
- The [`AllocationManager.slashOperator`](../docs/core/AllocationManager.md#slashoperator) function now returns a `slashId` and array of `shares` to be burned/redistributed. **The function selector remains the same.**
@@ -35,7 +31,6 @@
35
31
36
32
37
33
## Changelog
38
-
39
34
- feat(draft): `AllocationManager` redistribution support [PR #1346](https://github.com/layr-labs/eigenlayer-contracts/pull/1346)
Anyone can deploy and whitelist strategies for standard ERC20s by using the `StrategyFactory` deployed to the address below (see [docs](./docs/core/StrategyManager.md#strategyfactorydeploynewstrategy)). Strategies deployed from the `StrategyFactory` are deployed using the beacon proxy pattern:
@@ -211,16 +201,6 @@ You can view the deployed contract addresses below, or check out the code itself
Anyone can deploy and whitelist strategies for standard ERC20s by using the `StrategyFactory` deployed to the address below (see [docs](./docs/core/StrategyManager.md#strategyfactorydeploynewstrategy)). Strategies deployed from the `StrategyFactory` are deployed using the beacon proxy pattern:
@@ -288,15 +268,6 @@ The following strategies differ significantly from the other strategies deployed
0 commit comments