Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow supermajority of validators to vote in a rapid governance proposal of any category #2193

Open
davidsiska-vega opened this issue Feb 28, 2024 · 5 comments
Milestone

Comments

@davidsiska-vega
Copy link
Contributor

supermajority == 66%

simple beats clever

In PoS 2/3 validators can do whatever they want.

@gordsport gordsport added this to the 🏛️ Colosseo milestone Feb 28, 2024
@davidsiska-vega
Copy link
Contributor Author

In my mind the logic should be: a consensus validator key with stake representing more than minVoterBalance can submit a proposal that ignores minClose and minEnact and as soon as 66% of consensus validators voted for it - it goes through. If the votes are not in by closing time the proposal is abandoned.

@Vegaklaus
Copy link
Contributor

To kickstart the discussion here; I agree we need fast validator voting on some issues (mostly the technical ones on there blockchain level, such as anti-spam), but it may not be desirable for them to have an easy way to permanently close markets (i.e., do it via the UI rather than via code changes).
First idea that comes to mind is that they can do this, but that automatically triggers a normal governance vote; if that one fails, the market is reopened, and the validators cannot close it down on their own anymore.
A (in my view) nicer (but way to complicated) idea would be that the validators can tag a market, which creates a snapshot and blocks asset transfers out of the market; if the governance vote then confirms the choice, the market is blocked at the time of the snapshot, otherwise it continues normally (and cannot be tagged again for a while).

Any thoughts ?

@davidsiska-vega
Copy link
Contributor Author

When you say "snapshot" we already have that with "suspending" a market. Margin account balance cannot be reduced, the market must be either resumed by governance or closed by governance (this would release assets) or settled via governance (this would release assets).

Reading this:

  • we have a table of network parameters that validators can "override"; this is itself a network parameter (that validators can't override - obviously).
  • validators can "suspend" a market but this immediately triggers a governance vote to "confirm it"; if it's confirmed fine, market stays suspended; if it's declined then the market is resumed and the validators cannot suspend it again for some period of time (network parameter).

@Vegaklaus
Copy link
Contributor

I means something slightly lighter (if I understand suspension right) with the second option - people can still trade, but with the risk that it is all undone if tagging the market is undone). The reasoning for this avoids issues if a market is suspended at a time when big price changes happen outside of Vega and people can't react to it. Might be a UI nightmare though on second thought.

@davidsiska-vega
Copy link
Contributor Author

I means something slightly lighter (if I understand suspension right) with the second option - people can still trade, but with the risk that it is all undone if tagging the market is undone).

I am not sure how to even begin to think about this in terms of cross margin mode, withdrawals (block all keys active on the market from withdrawing ?!?) etc.

The reasoning for this avoids issues if a market is suspended at a time when big price changes happen outside of Vega and people can't react to it. Might be a UI nightmare though on second thought.

But that's besides the point - we're looking for something that fits with where vega core is now. And right now we have meaningful and well defined "market suspended" mode that we'd want to use for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants