Hey @bmpalatiello, thanks for sharing the team’s research regarding the withdrawal and deallocation delay recommendations for stakers and operators. We appreciate all the work.
After reviewing these recommendations, we have a couple of questions:
- On task assignment window: Can you clarify how broad task assignment is? It’s unclear to us that an AVS would want to be able to assign tasks once every 7 days. For example an oracle service could process multiple oracle updates within that 7-day period. Similarly, for a Solver network, if task assignment refers to “solve this task” instead of “solve this class of tasks” then 7 days is far too long.
- On slashing request window: Can you elaborate on why a request window of 3.5 days is required after governance approves the request? If the slashing action is irreversible after gov confirmation, there might be an opportunity to shorten this period.
- On finality period: The referenced doc for this 3.5-day duration points to a post on OP stack’s Fault Proof system. Given that Ethereum finality of 2 epochs or ~13min is significantly faster than finality on typical optimistic rollups (the original ref uses a 7-day bisection game model for its fault dispute game), can you explain the rationale for using the same 3.5 days as the finality benchmark?
- An alternative design worth exploring: instead of defining a global SGW parameter for all stake, let’s define the SGW for shared (non-unique) stake only, and let the AVS configure slashing window for their unique stake (i.e., define as part of the slashing rule of operator sets with unique stake)
- With this customizable option, each service can define the length of stake guarantee that most suits their tasks. This is similar to the
EpochDurationparameter for symbiotic vaults.
- With this customizable option, each service can define the length of stake guarantee that most suits their tasks. This is similar to the