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:**
Newly created operators in core have to wait 17.5 days to begin
allocating. This is a UX painpoint for new AVSs to onboard their
operators.
**Modifications:**
Update the `AllocationManager` so that the allocation delay for a newly
created operator is active immediately block. This allows operators to
make an allocation at the very next block.
**Result:**
Easier onboarding
Copy file name to clipboardExpand all lines: docs/core/AllocationManager.md
+6-2Lines changed: 6 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -837,6 +837,9 @@ Once slashing is processed for a strategy, [slashed stake is burned or redistrib
837
837
* allocating magnitude to an operator set, and the magnitude becoming slashable.
838
838
* @param operator The operator to set the delay on behalf of.
839
839
* @param delay the allocation delay in blocks
840
+
* @dev When the delay is set for a newly-registered operator (via the `DelegationManager.registerAsOperator` method),
841
+
* the delay will take effect immediately, allowing for operators to allocate slashable stake immediately.
842
+
* Else, the delay will take effect after `ALLOCATION_CONFIGURATION_DELAY` blocks.
840
843
*/
841
844
function setAllocationDelay(
842
845
address operator,
@@ -847,15 +850,16 @@ function setAllocationDelay(
847
850
848
851
_Note: IF NOT CALLED BY THE `DelegationManager`, this method can be called directly by an operator, or by a caller authorized by the operator. See [`PermissionController.md`](../permissions/PermissionController.md) for details._
849
852
850
-
This function sets an operator's allocation delay, in blocks. This delay can be updated by the operator once set. Both the initial setting of this value and any further updates _take `ALLOCATION_CONFIGURATION_DELAY` blocks_ to take effect. Because having a delay is a requirement to allocating slashable stake, this effectively means that once the slashing release goes live, no one will be able to allocate slashable stake for at least `ALLOCATION_CONFIGURATION_DELAY` blocks.
853
+
This function sets an operator's allocation delay, in blocks. This delay can be updated by the operator once set. The initial setting of this value by a newly created operator via [`DelegationManager.registerAsOperator`](./DelegationManager.md#registerasoperator) will take 1 block to take effect. The setting of this value for an operator who has already been registered in core or further updates _take `ALLOCATION_CONFIGURATION_DELAY` blocks_ to take effect. Because having a delay is a requirement to allocating slashable stake, this effectively means that once the slashing release goes live, no already-created operators will be able to allocate slashable stake for at least `ALLOCATION_CONFIGURATION_DELAY` blocks.
851
854
852
855
The `DelegationManager` calls this upon operator registration for all new operators created after the slashing release. For operators that existed in the `DelegationManager`_prior_ to the slashing release, **they will need to call this method to configure an allocation delay prior to allocating slashable stake to any AVS**.
853
856
854
857
The allocation delay's primary purpose is to give stakers delegated to an operator the chance to withdraw their stake before the operator can change the risk profile to something they're not comfortable with. However, operators can choose to configure this delay however they want - including setting it to 0.
855
858
856
859
*Effects*:
857
860
* Sets the operator's `pendingDelay` to the proposed `delay`, and save the `effectBlock` at which the `pendingDelay` can be activated
* If a newly registered operator in core, `effectBlock = uint32(block.number)`, allowing operators to allocate slashable stake immediately after registration
Copy file name to clipboardExpand all lines: docs/core/DelegationManager.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -96,7 +96,7 @@ function registerAsOperator(
96
96
97
97
Registers the caller as an operator in EigenLayer. The new operator provides the following input parameters:
98
98
*`address initDelegationApprover`: *(OPTIONAL)* if set to a non-zero address, this address must sign and approve new delegation from stakers to this operator (See [`delegateTo`](#delegateto))
99
-
*`uint32 allocationDelay`: the delay (in blocks) before slashable stake allocations will take effect. This is passed to the `AllocationManager` (See [`AllocationManager.md#setAllocationDelay`](./AllocationManager.md#setallocationdelay))
99
+
*`uint32 allocationDelay`: the delay (in blocks) before slashable stake allocations will take effect. This is passed to the `AllocationManager` (See [`AllocationManager.md#setAllocationDelay`](./AllocationManager.md#setallocationdelay)). Upon registration, this allocation delay is effective immediately. Further modifications directly via `AllocationManager.setAllocationDelay` take `ALLOCATION_CONFIGURATION_DELAY` blocks.
100
100
*`string calldata metadataURI`: emits this input in the event `OperatorMetadataURIUpdated`. Does not store the value anywhere.
101
101
102
102
`registerAsOperator` cements the operator's delegation approver and allocation delay in storage, and self-delegates the operator to themselves - permanently marking the caller as an operator. They cannot "deregister" as an operator - however, if they have deposited funds, they can still withdraw them (See [Delegation and Withdrawals](#delegation-and-withdrawals)).
0 commit comments