process: Effective at Threshold

[hythloda]

No description provided.

[hythloda]

@jalonsdrw Can you review this when you get a chance?

[abryandrw]

@stas-sbi @hythloda

After speaking with @jalonsdrw one comment from our side: I think we can better define what an "emergency" constitutes in the "When It Can Be Used" section. Generally, I think we should make an "emergency" as objective as possible to remove doubt or additional coordination overhead associated with whether the feature should be used in an actual emergency.

What do you think about the following:
"Emergencies Only - The Effective at Threshold feature should only be used when the Super Validator proposing the vote has evidence the additional time delay required for vote expiration may result in increased instability of the network."

[hythloda]

@abryandrw ready for your review again

[abryandrw]

@hythloda - i think we'd like to make one last adjustment to the language. It currently says that this will only be used if waiting would "create or worsen instability in the network".

I'd like to propose that we should include instances where waiting would have an economic impact to the network as well. For example incorrect reward mint, etc. What about the following language

"The proposing Super Validator has evidence that waiting for the normal expiration window would create or worsen instability in the network or result in network economics different than what has been approved via the CIP governance process."

[waynecollier-da]

I agree; I was considering language along these lines:

"rapidly implementing a new proposal correcting an error in an existing vote proposal, where

• All SVs agree with the intent of the original proposal, and a majority have voted in favor
• Implementation of the original proposal would have a material negative impact on network operations or reward distribution across all SVs, apps or Validators."

[waynecollier-da]

@hythloda Let's propose this in the next SV Ops call