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
We are still going to need the idea of contract state which we get directly from subgraph as well as the actual state we want to show the user. Since we now have multiple types of state: state, proposal state and execution state, what we show the user is even more important.
All options we have:
enum State (this seems to have the same name in contracts, but think its just called state on the subgraph) {
None,
Submitted,
Rejected,
Passed
}
enum ProposalState {
None,
Expired,
ExecutedInQueue,
ExecutedInBoost,
Queued,
PreBoosted,
Boosted,
QuietEndingPeriod
}
enum ExecutionState {
None,
Failed,
QueueBarCrossed,
QueueTimeOut,
PreBoostedBarCrossed,
BoostedTimeOut,
BoostedBarCrossed
}
Fortunately, a lot of these states are more details than most users actually need so we can discount execution state for the most part for now.
If the State variable in subgraph is Rejected or Passed then that is what we should show.
If Proposal State is anything but None then we should show that.
We also need to handle states where it hasn't yet been updated on the contracts but can be, for example
Pre-boosted state but ready for boosting (can be boosted)
Boosted but passed boost time (can be executed if over boost quorum)
Queued or boosted but passed quorum (can be executed)
Look into _execute() function in voting machine contracts to see logic for all of this
This stuff gets complicated with holographic consensus so reach out if this is not clear.
The text was updated successfully, but these errors were encountered:
So, states with gov 1.5 are a little complex.
We are still going to need the idea of contract state which we get directly from subgraph as well as the actual state we want to show the user. Since we now have multiple types of state: state, proposal state and execution state, what we show the user is even more important.
All options we have:
Fortunately, a lot of these states are more details than most users actually need so we can discount execution state for the most part for now.
If the
State
variable in subgraph isRejected
orPassed
then that is what we should show.If
Proposal State
is anything but None then we should show that.We also need to handle states where it hasn't yet been updated on the contracts but can be, for example
Look into _execute() function in voting machine contracts to see logic for all of this
This stuff gets complicated with holographic consensus so reach out if this is not clear.
The text was updated successfully, but these errors were encountered: