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: docs/core/AllocationManager.md
-28Lines changed: 0 additions & 28 deletions
Original file line number
Diff line number
Diff line change
@@ -40,7 +40,6 @@ The `AllocationManager` manages AVS metadata registration, registration and dere
40
40
41
41
---
42
42
43
-
<<<<<<< HEAD
44
43
## AVS Metadata
45
44
46
45
AVSs must register their metadata to declare themselves who they are as the first step, before they can create operator sets or register operators into operator sets. `AllocationManager` keeps track of AVSs that have registered metadata.
@@ -139,8 +138,6 @@ Later on, once AVSs have created operator sets, content in their metadata URI ca
139
138
* Caller MUST be authorized, either as the AVS itself or an admin/appointee (see [`PermissionController.md`](../permissions/PermissionController.md))
140
139
141
140
142
-
=======
143
-
>>>>>>> dev
144
141
## Operator Sets
145
142
146
143
Operator sets, as described in [ELIP-002](https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-002.md#operator-sets), are useful for AVSs to configure operator groupings which can be assigned different tasks, rewarded based on their strategy allocations, and slashed according to different rules. Operator sets are defined in [`libraries/OperatorSetLib.sol`](../../src/contracts/libraries/OperatorSetLib.sol):
@@ -248,10 +245,7 @@ Optionally, the `avs` can provide a list of `strategies`, specifying which strat
248
245
249
246
*Requirements*:
250
247
* Caller MUST be authorized, either as the AVS itself or an admin/appointee (see [`PermissionController.md`](../permissions/PermissionController.md))
251
-
<<<<<<< HEAD
252
248
* AVS MUST have registered metadata
253
-
=======
254
-
>>>>>>> dev
255
249
* For each `CreateSetParams` element:
256
250
* Each `params.operatorSetId` MUST NOT already exist in `_operatorSets[avs]`
257
251
@@ -570,11 +564,7 @@ _Note: this method can be called directly by an operator, or by a caller authori
570
564
571
565
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:
572
566
* If `newMagnitude` is _greater than_`Allocation.currentMagnitude`, this is an allocation
573
-
<<<<<<< HEAD
574
-
* If `newMagnitude` is _less than_`Allocation.currentMagnitude`, this is a dellocation
575
-
=======
576
567
* If `newMagnitude` is _less than_`Allocation.currentMagnitude`, this is a deallocation
577
-
>>>>>>> dev
578
568
* If `newMagnitude` is _equal to_`Allocation.currentMagnitude`, this is invalid (revert)
579
569
580
570
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).
@@ -661,11 +651,7 @@ This queue contains a per-strategy ordered list of operator sets that, due to pr
661
651
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.
662
652
663
653
*Effects*:
664
-
<<<<<<< HEAD
665
-
* For each `strategy` and _completeable_ deallocation in `deallocationQueue[operator][strategy]`:
666
-
=======
667
654
* For each `strategy` and _completable_ deallocation in `deallocationQueue[operator][strategy]`:
668
-
>>>>>>> dev
669
655
* Pops the corresponding operator set from the `deallocationQueue`
670
656
* Reduces `allocation.currentMagnitude` by the deallocated amount
671
657
* Sets `allocation.pendingDiff` and `allocation.effectBlock` to 0
@@ -700,7 +686,6 @@ struct SlashingParams {
700
686
}
701
687
702
688
/**
703
-
<<<<<<< HEAD
704
689
* @notice Called by an AVS to slash an operator in a given operator set. The operator must be registered
705
690
* and have slashable stake allocated to the operator set.
706
691
*
@@ -721,9 +706,6 @@ struct SlashingParams {
721
706
* @dev Small slashing amounts may not result in actual token burns due to
722
707
* rounding, which will result in small amounts of tokens locked in the contract
723
708
* rather than fully burning through the burn mechanism.
724
-
=======
725
-
* @notice Called by an AVS to slash an operator in a given operator set
726
-
>>>>>>> dev
727
709
*/
728
710
function slashOperator(
729
711
address avs,
@@ -740,11 +722,7 @@ AVSs use slashing as a punitive disincentive for misbehavior. For details and ex
740
722
741
723
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.
742
724
743
-
<<<<<<< HEAD
744
725
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.
745
-
=======
746
-
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.
747
-
>>>>>>> dev
748
726
749
727
There are two edge cases to note for this method:
750
728
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.
@@ -788,10 +766,7 @@ Once slashing is processed for a strategy, [slashed stake is burned via the `Del
788
766
**Methods:**
789
767
*[`setAllocationDelay`](#setallocationdelay)
790
768
*[`setAVSRegistrar`](#setavsregistrar)
791
-
<<<<<<< HEAD
792
-
=======
793
769
*[`updateAVSMetadataURI`](#updateavsmetadatauri)
794
-
>>>>>>> dev
795
770
796
771
#### `setAllocationDelay`
797
772
@@ -882,8 +857,6 @@ Note that when an operator registers, registration will FAIL if the call to `IAV
882
857
883
858
*Requirements*:
884
859
* Caller MUST be authorized, either as the AVS itself or an admin/appointee (see [`PermissionController.md`](../permissions/PermissionController.md))
885
-
<<<<<<< HEAD
886
-
=======
887
860
888
861
#### `updateAVSMetadataURI`
889
862
@@ -960,4 +933,3 @@ Below is the format AVSs should use when updating their metadata URI. This is no
960
933
961
934
*Requirements*:
962
935
* Caller MUST be authorized, either as the AVS itself or an admin/appointee (see [`PermissionController.md`](../permissions/PermissionController.md))
0 commit comments