Key Constants in OpenGov
Welcome to another episode in our Polkadot OpenGov Distilled series. In this article, we dive into a fundamental aspect of Polkadot Open Governance: the constants.
Polkadot’s Open Governance (OpenGov) system is a core facet of its decentralized ethos, but as with any complex system, understanding its individual components can seem like a daunting task. However, it is through comprehending these intricate details that we can gain a fuller understanding of how the system operates. One such set of components we’ll be examining in this article are the constants, which serve as key parameters in the Polkadot OpenGov system.
In this article, we’ll be unraveling these constants, one by one, to shed light on their purpose.
If you haven’t, please check out the previous articles in this series:
So, sit tight, and let’s get started.
Alarm Interval
The alarm interval is a specified number of blocks at which the system checks or updates the status of a referendum.
When the alarm is triggered, it leads to a call to nudge_referendum which moves the referendum to its next state. This is similar to a timer ringing after 10 minutes to remind you to check if the temperature of your oven has reached the desired level. In this case, the alarm interval would be 10 minutes, and the action is checking the oven’s temperature. Similarly, in the case of Polkadot referenda, the alarm interval is a specified number of blocks, and the action would be moving a referendum to its next state.
The alarm interval works as a scheduling mechanism that efficiently manages resources. The system waits for the alarm interval to be reached before checking the status of a referendum. This means that every nth block (where n is the alarm interval), the system checks if a proposal should move to referendum or if a referendum’s voting period should end, and then executes the necessary actions.
This mechanism helps to balance system resource consumption and the need to keep the status of referenda updated in a timely manner. It ensures that the operations related to the referenda are not done more often than necessary.
The alarm interval for referenda on Polkadot and Kusama (including fellowship referenda) is currently set to 1 block, which implies that the system checks or updates the status of a referendum after every block in the blockchain. This regular check essentially means that there will be little to no delays in automatic referendum status changes.
Maximum Queue
This refers to the upper limit of referenda that can be awaiting processing at any one time. It acts as a cap on the number of referenda that can be in the queue awaiting being nudged into the first phase of referenda. ie., the ‘preparation phase’.
To understand it better, let’s imagine this analogy. Consider a busy restaurant during peak hours. This restaurant has 20 sits and has a policy of only allowing a maximum of 100 orders to be queued up at a time for the kitchen to process once the 20 seats are filled. This limit is to ensure the kitchen staff can maintain a high level of food quality and customer service without being overwhelmed.
In Polkadot’s referenda context, the maximum queue acts similarly. There’s a limit to how many referenda can be in a state of awaiting being nudged into the “preparation” phase. This is done to prevent the system from being overwhelmed with too many active referenda and to ensure that each referendum is processed efficiently and without excessive delay.
Each referendum in the queue is waiting to get into the ‘preparation’ phase and eventually go through the decision-making process, which includes activities like checking if the referendum is ready to be decided, if it’s timed out, if it’s ongoing and passing or failing, among other conditions.
The maximum queue for Polkadot and Kusama is currently 100.
Submission Deposit
This is the minimum amount that can be used as a deposit for a public referendum proposal.
By requiring a deposit, the system reduces the chances of unserious and uncommitted proposals being submitted.
Referenda can generally be cancelled by:
- Canceling it via the referendum canceler track
- Canceling it without using a referendum (This is only possible once a referenda has timed out, after which anyone can cancel it without going through a referendum)
- Killing it via the referendum killer track.
The first two options do not carry out any punitive action like slashing deposits and are used when there’s a reason to stop the referendum but no malicious intent is detected.
The third option (Kill) not only cancels the referendum but also slashes the submission deposit associated with it. This punitive action serves to disincentivize any potentially harmful or malicious submissions.
The current submission deposit for Kusama referenda is 0.033 KSM, while for Polkadot, it will be 1 DOT. However, fellowship referenda currently don’t require a submission deposit.
Tracks Information
This constant contains the parameters that may vary for different tracks.
It holds crucial information about the various tracks, such as:
- The maximum number of referendas that can be deciding at a particular point in time (
Maxdeciding). - Decision deposit: This is needed for a referenda to move on from the “prepare” period to the decision period.
- Prepare period: This is the period after the referendum has been submitted until the beginning of the decision period (this period doesn’t take queued referenda into account).
- Confirmation period: This period comes after the decision period, and a proposal can be deemed passed or failed after this period.
- Minimum enactment period: This is the minimum period of time it takes for a referenda to be executed after passing.
- Minimum approval: this is the minimum percentage of ‘aye’ votes that’s needed for a proposal to be passing at a particular point in time.
- Minimum support: This is the minimum support that is needed for a proposal to be passing at a particular point in time.
Note: both minimum support and minimum approval decreases as the referenda period progresses. the rate of decline depends on the track. You can get more details about the track info on the previous part of this series or the Polkadot wiki. Use can also use subsquare’s UI to quickly check out the constants in individual tracks
Timeout Period
This is the period after submitting a referendum during which it must start deciding. This period is currently 14 days on Kusama and is planned to be 14 days on Polkadot too. However, the timeout period for fellowship referenda is 7 days.
During this period, a “decision deposit has” to be made. If a “decision deposit”” is not made during this period, the referendum will time out and no longer be active. This ensures that referenda with no decision deposit don’t take up the capacity of a particular track for a long period of time.
After the timeout period, the referendum has to be cancelled for its submission deposit to be returned. Fortunately, a timed-out referendum can be canceled by anyone and doesn’t require any special privileged origin.
Vote Locking Period
This is the minimum period for which your tokens will be locked when voting on a referendum. This period is currently 7 days on Kusama and will be 7 days on Polkadot too.
This essentially means that if a referenda passes before this minimum lock-up period, all tokens will remain locked until at least the minimum lock-up period elapses.
Conclusion
In this Polkadot OpenGov Distilled article, we’ve delved into the intricacies of Polkadot’s Open Governance system, spotlighting its key operational constants. From the submission deposit, which is the minimum amount that can be used as a deposit for a public referendum proposal, to the maximum queue, which caps the number of awaiting referenda, we’ve unwrapped the intricate mechanisms that make Polkadot’s governance tick.
We’ve also explored the submission deposit, a deterrent against frivolous proposal submissions, and the varying parameters of different tracks contained in the track information. The importance of the timeout period in maintaining track capacity and the role of the vote locking period in ensuring voter commitment have also been outlined.
These constants, each vital in its own right, collectively create a balance between system efficiency, resource management, and user participation. They ensure a seamless and orderly progression of referenda from submission to enactment, steering the direction of Polkadot’s decentralized governance.
In the next article, we’ll delve into the process of submitting an on-chain proposal. Stay tuned!