Voting Delay

The Helium Improvement Proposal (HIP) process enforces a formal voting delay known as the "Draft" and "Discussion" phases. A proposal must be publicly available for community review for a minimum period (typically 7+ days) before a formal on-chain vote is initiated. This ensures network participants, including hotspot operators and token holders, have adequate time to analyze technical and economic impacts before committing their vote.

Livepeer's governance requires proposals to pass through a Temperature Check and Consensus Check on its forum before an on-chain vote. This multi-stage process creates a de facto voting delay, mandating several days of off-chain debate and signal voting. This delay filters out poorly defined proposals and builds community consensus, protecting the network's core protocol and orchestrator economics from abrupt changes.

The Graph Protocol mandates that all Governance Proposals (GPs) undergo a mandatory community review period. Following submission to the forum, a 7-day delay is enforced where delegates and indexers can scrutinize the proposal's code, economic impact, and alignment with network goals. This delay is crucial for technical audits and preventing governance attacks that could compromise the integrity of the decentralized indexing service.

While Arweave's core protocol governance is minimal, its Profit-Sharing Community (PSC) tokens, which grant rights to future application revenues, often implement voting delays in their individual governance systems. These delays prevent a sudden majority holder from rushing through changes to revenue distribution or licensing terms, protecting the long-term incentives for developers and content archivists within the permaweb ecosystem.

A primary DePIN use case for voting delay is preventing snapshot attacks. Without a delay, a malicious actor could:

• Acquire a large number of tokens (e.g., from a decentralized wireless or storage network).
• Immediately submit and vote on a self-serving proposal (e.g., to drain a treasury or alter rewards).
• The delay forces the attacker to hold tokens at risk during the review period, allowing the community to identify the threat and potentially exit or mount a defense, significantly raising the attack cost.

It is critical to distinguish voting delay from an execution timelock.

• Voting Delay: The period before voting starts (e.g., 3 days for review).
• Execution Timelock: The period after a vote passes but before code executes (e.g., 2 days for final checks). In DePIN, a voting delay protects the deliberation process, while an execution timelock provides a final escape hatch to react to a passed but harmful proposal, such as one altering physical hardware rewards or data integrity rules.

Voting delay is the mandatory time buffer between a governance proposal's on-chain submission and the opening of its voting period. Its primary purpose is to provide stakeholders with sufficient time to review the proposal's details, assess its implications, and coordinate their voting strategy before casting votes. This prevents rushed decisions and enhances the quality of governance participation.

The delay acts as a defense mechanism against governance attacks. It prevents a malicious actor from immediately pushing through a proposal that could drain funds or alter critical parameters before the community can react. This window allows for:

• Social consensus to form off-chain.
• Security researchers and watchdogs to audit the proposal's code.
• The execution of emergency procedures if a harmful proposal is detected.

The length of the voting delay is a configurable parameter that represents a trade-off between security and agility. A longer delay (e.g., 2-7 days) maximizes review time but slows protocol evolution. A shorter delay (e.g., < 1 day) enables faster upgrades but increases risk. This parameter is often set via governance itself and must be calibrated based on the protocol's total value locked (TVL) and complexity.

It is crucial to distinguish voting delay from two related concepts:

• Voting Period: The active window when token holders can cast their votes after the delay.
• Timelock Delay: A separate security delay after a vote passes and before the proposal's changes are executed on-chain. Together, these three parameters (submission → voting delay → voting period → timelock delay → execution) create a multi-stage defense for on-chain governance.

The Compound protocol provides a canonical example. Its Governor Bravo contract enforces a 2-day (approximately 13,140 blocks) voting delay. This means a proposal submitted at block N becomes votable at block N + 13,140. This period allows COMP token holders and delegates to analyze the proposal's calldata and discuss its merits on forums before the 3-day voting period begins.

Voting delay interacts with other key governance settings:

• Proposal Threshold: The minimum token power required to submit a proposal.
• Quorum: The minimum percentage of voting power that must participate for a vote to be valid.
• Voting Period Length: Duration of the active voting phase. Adjusting one parameter often requires reconsidering others to maintain the system's overall security and efficiency balance.

The minimum amount of governance tokens a user must hold to submit a new proposal to the governance system. This parameter works in tandem with voting delay to manage governance spam and quality. A higher threshold:

• Reduces spam and frivolous proposals that waste community attention.
• Can centralize proposal power among large token holders.
• Is often adjusted based on token distribution and desired governance accessibility.

The minimum level of voter participation required for a governance proposal to be valid. A proposal must meet both the quorum and a majority vote to pass. Quorum prevents a small, active minority from deciding outcomes for the entire community. Mechanisms include:

• Absolute Quorum: A fixed number of votes (e.g., 4% of total supply).
• Adaptive Quorum: Adjusts based on proposal type or historical turnout.
• Failure to meet quorum results in proposal rejection, regardless of the vote tally.

The native asset (e.g., UNI, COMP, MKR) that confers voting rights within a decentralized protocol. The voting delay and other parameters are applied to proposals involving these tokens. Key attributes include:

• Vote-escrowed models: Tokens are locked to increase voting power, aligning long-term incentives.
• Delegation: Token holders can delegate voting power to representatives or experts.
• The token's distribution directly impacts the security and decentralization of the governance process.