PIP-65 - Enhancing Predictability in VeloraDAO Governance

Governance Proposals
1

Abstract

We propose a simple set of guidelines to make Snapshot votes in VeloraDAO more predictable and easier for delegates by creating a clear, regular voting schedule. By agreeing as a community to start all votes on Thursdays, extend the voting window to seven days, and pause new votes during the holiday break from December 24 to January 6, this approach delivers a consistent schedule without requiring formal Charter changes. If approved by Snapshot, these changes can take effect as early as June 19, 2025, at no additional cost to the DAO.

Goals & review

Over the past four years, VeloraDAO has completed 89 off-chain proposals and built a strong, incentivized delegate program. Delegates still operate within a five-day Snapshot window that sometimes overlaps the weekend, limiting the time available for thorough review and feedback. Our timestamp data (Velora voting period) show participation climbing from Monday through Thursday, peaking on Tuesday, then dropping roughly 40 percent over the weekend. We propose extending the voting window to seven days and having every window start on Thursday.This change keeps both the opening and closing of each vote within peak-engagement period, removes weekend deadlines entirely, and grants delegates a full week to evaluate proposals. It also creates a clear, predictable weekly cadence, inspired by ArbitrumDAO’s proven model.

888Ă—633 42.4 KB

*This voting data is from Jan 2025 - May 2025

Check out the full data: Velora voting period

Rationale

Means

Current Process and Proposed Adjustment
The Proposal Improvement Process consists of five stages:

  • Stages one, two, four and five remain unchanged.
  • Stage three is revised as follows:
    • Snapshot drafts must be queued by Wednesday 23:59 UTC.
    • Voting opens automatically at 00:00 UTC on Thursday and closes at 23:59 UTC the following Thursday.

This adjustment delivers three practical benefits:

  • Delegates enjoy a uniform seven‑day review period that always spans a complete working week.
  • Weekend participation becomes optional, reducing demand on personal time.
  • Authors who miss the queue deadline wait only seven days for the next window, easing pressure to rush unfinished work.

Key Factors Behind the Thursday Selection Behind the Thursday Selection

  1. Delegate turnout is highest mid‑week with Tuesday recording the single largest share of voting interactions in the dataset. Weekend participation is correspondingly weak, averaging roughly forty per cent lower than weekday engagement.

  2. Thursday openings ensure both the start and the finish of every vote land on weekdays when delegates are most responsive.
    art and the finish of every vote land on weekdays when delegates are most responsive.

  3. The Monday‑to‑Wednesday gap between queuing and opening offers a seventy‑two‑hour preview period so delegates can skim the upcoming ballot in advance.

  4. A Thursday rhythm already operates effectively in other large DAOs such as Arbitrum, providing a field‑tested model.

Holiday Break: December 24 – January 6

Each year, VeloraDAO will observe a winter holiday hiatus from December 24 through January 6. During this period, delegates are encouraged to rest and return refreshed for the new year. No new proposals should be posted to the forum or Snapshot, except for urgent security that demand immediate attention.

Emergency Proposals

Proposals addressing critical security vulnerabilities or urgent constitutional matters may bypass the above rules and proceed directly to Snapshot if time-sensitive, ensuring that the DAO can respond swiftly when necessary.

Reward & Refunds Distrubtion Proposals

Distribution proposals for rewards and refunds are likewise exempt, as they should be posted immediately after each epoch ends to ensure users receive their payouts without delay.This exemption therefore remains in the current version of the proposal.

Timeline

We propose a feedback period from May 28 to June 4, 2025, followed by a Snapshot vote.

The vote will offer options to

  1. Adopt all three (changing window from 5 to 7 days, Thursday Voting and Holiday break)

  2. Maintain a 5-day voting window starting Monday–Friday and include a holiday break

  3. Adopt only Holiday break

  4. Abstain

  5. Against

Implementation Overview

Implementation requires only updates to forum documentation and the calendar.

Time of Implementation:

The proposal will be implemented immediately after its passing.

Budget

There are no additional financial costs associated with these changes.

Risk Assessment

Pros

  • Easier planning: A consistent weekly schedule helps delegates and authors organize their time better.

  • Less noise: Reduces random or rushed submissions, leading to higher-quality proposals.

  • Weekend flexibility: Delegates aren’t expected to review or vote on weekends unless they choose to.

Cons

  • Less flexibility: Authors need to work around a fixed schedule, which might slow things down in some cases.

  • Can feel strict for newcomers: Those less familiar with the process might find the structure a bit limiting at first.

  • May slow submission timing: If a proposal is ready late in the week, it might have to wait until the next cycle, slightly delaying momentum.

2 Likes
2

Thanks for your proposal.

While I’m generally in favor of standardized processes and find most of the suggestions here reasonable (like the holiday period), I wonder whether extending the snapshot vote window to seven days is truly necessary. In theory, we want active delegates and governance participants who have already discussed the proposal before it goes to a vote.

About the vote options:

I think this proposal suggests three different things: changing the window from 5 to 7 days, adopting Thursday as the voting opening day, and the holiday season. Therefore, those options should be reflected in the proposal if it goes to a vote.

Note: nice dashboard!

3

What about Rewards & Refunds distribution votes? can’t be on a specific day of the week, can’t be on a 7 days voting period, It has to be done as quickly as possible once Epoch ends.

2 Likes
4

Thanks for the thoughtful feedback, @jameskbh, We suggested a seven-day window mainly to keep both the opening and closing dates on weekdays: by kicking off every vote on Thursday and ending the following Thursday, no delegate is forced to log in over a weekend, yet anyone who has already made up their mind can still vote on day one.

The extra two days are really a buffer for people in tricky time zones or with busy workweeks; that said, If most delegates feel five days is enough, we can keep that length and still launch every vote on Thursday.

You’re also right that the proposal actually contains three independent changes, Thursday start day, 7-day window, and the December 24-January 6 holiday pause so the Snapshot ballot will let delegates pick any combination they like:

  1. Adopt all three (changing window from 5 to 7 days, Thursday Voting and Holyday break),
  2. Adopt only Thursday Voting and Holiday break
  3. Adopt only Holiday break
  4. Abstain
  5. Against

we’ll revise the forum post to show those separate options and invite more comments before we queue the Snapshot. Thanks again for helping tighten this up!

Good point, thanks for raising this, @enorow. We’ve updated the proposal to exempt Rewards & Refunds distribution votes from the this cadence so they can be posted and finalized as soon as each epoch ends.

2 Likes
5

@curia, thanks for the proposal.

At WakeUp Labs, we support the idea of standardizing processes, as it’s very helpful in such a dynamic environment.

From our side, we’d like to point out that while rewards and gas refunds can be standardized, there’s a practical reality to consider.

If the voting period for those two proposals were a bit shorter, we could run the scripts and automations in less than a week.

Let’s break it down:

  1. When the epoch closes, we usually wait 1 or 2 days to make sure all values are properly set, prices remain stable, and the APIs and scripts we use don’t return inconsistent results.
  2. Then we need about 1 more day to run and configure everything.
  3. After that, we wait for the voting period, which usually takes 3 to 5 days depending on the setup.
  4. Finally, there’s 1 extra day for UMA’s oracle to go through its challenge period.

So overall, we’re working with very tight timing if we follow a standard schedule.
Even when everything runs smoothly, the process tends to stretch slightly.

That’s why in these specific cases, it might make sense to shorten the voting period for this cases.

1 Like
6

Great!

Also I think instead of exempting/excluding it from your proposal framework we should add an “express/expedit voting period” type of 48/72 hours max that aim for that kind of automated recurrent script to run smoothly.
We shouldn’t had to wait 5/6/7+ days to execute automated scripts.

7

Thank you, @Curia, for the detailed analysis of the DAO’s voting patterns and the thoughtful proposal in response. We especially appreciate how quickly you incorporated the feedback received and your decision to separate the voting options to allow voting either as a whole or by sections.

In principle, we support the move toward standardizing governance processes, as it adds predictability. While a 7-day voting period may seem slightly long that would delay decisions by 2 days — especially since it hasn’t caused any issues so far, and moreover, in a DAO with high levels of participation and engagement as we want 5 days of voting would not seem short — it’s true that it helps neutralize low weekend participation, which can improve overall voter engagement. This is our initial reaction just a few hours after the proposal was posted. We would like to hear more feedback from other delegates and stakeholders before forming a final opinion.

While we agree that a 5-day voting period might be too long for proposals concerning gas refund and fee distributions, it’s also important to consider that shortening the timeframe increases the risk of some tokenholders and delegates missing the vote or not participating. This could result in proposals failing to reach quorum — a risk that becomes even more relevant if, as anticipated in the debate, quorum threshold are raised again in the near future. Therefore, any change to reduce the voting period in this cases should be carefully considered. We’re not saying we’re against the idea, but we do believe it requires further analysis when it comes to determining what timeframe would be most appropriate to avoid unintended consequences, such as setting a period that is too short and potentially impacting in lower participation that could put the quorum at risk.

1 Like
8

Thanks @Curia for this post and for the quick feedback below. I support the broad goal of making governance timings more predictable and thanks for taking on this initiative. I think we’re close to a consensus with just a few tweaks.

Some thoughts:

  • Keep the Thursday cadence, but let authors “dial‑in” the voting window: The data you shared show weekday engagement peaking Tues–Thurs and dropping ~40 % on weekends—so Thursday → Thursday makes sense to bracket an entire working week without forcing weekend log‑ins.
  • Several delegates worry that a blanket seven‑day window slows non‑controversial decisions: Maybe adopting a shorter express voting period or something could be useful. Haven’t thought out the full extent of what this could look like, but idea could be reasonable.
  • Guard‑rails for quorum and accessibility: As @SEEDGov noted, quorum could rise again; shortening windows can backfire if notice is poor. A good thing here is requiring proposers to use the Express Track to tag all delegates 24h before the Snapshot goes live.
  • Holiday pause and emergency exceptions: The December 24 – January 6 break seems uncontroversial and mirrors practices in other large DAOs.

Thanks again to the Curia team for taking this on!

1 Like
9

As an active delegate in several DAOs, I appreciate Curia’s efforts to bring more structure and consistency to Velora’s governance. Having votes go live on a fixed day like Thursday brings more structure, more professional, and honestly, it helps me plan better. Thursday might become “Velora Day” where I check Snapshot first thing :slight_smile:

However, extending the voting period from 5 to 7 days may be unnecessarily long in many cases. In DAOs I participate in, such as Lido and Aave, voting windows are often shorter, 3 to 5 days and decisions are made efficiently without impacting participation.

I agree. There is currently no clear evidence that the 5 days voting period limits engagement or leads to failed proposals.

So maybe we can keep the standard voting window at 5 days, start from Thursday, while allowing an option for extended 7 days voting on more complex or critical proposals?

Would love to hear more thoughts from others!

1 Like
10

Thank you for the proposal @Curia While i understand the rationale behind the suggested changes, many of these are more social changes which require an admin type of entity to enforce. While we have a Governance lead at the moment, in the long run, it is in the best interest of the DAO to automate many of these elements which require social coordination. Hence, while i am not opposed to these changes, I’d urge you to look at solutions which can be implemented without having to involve social coordination.

2 Likes
11

We’re directionally in favor of the changes made in this proposal. We share others’ opinions raised so far regarding the extension of the voting window perhaps being unnecessary. We don’t think proposals need to start and end on the same day. The predictable start day is useful, but we’d rather keep Velora’s proposal velocity high. Two days may not seem like much on a granular level, but when you zoom out, taking two extra days for every decision drastically slows down the development of a DAO. We understand the rationale behind it (trying to add an extra buffer for delegates in different time zones), but most delegates check the forums/voting portal at least once every 5 days.

1 Like
12

I’d like to thank @Curia for this clear, data-driven analysis, I admire your work and I appreciate every bit of effort towards enhancing governance and furthering @SEEDGov initial mission. Overall this seems to give us a thoughtfully crafted schedule that will undoubtedly help human-centric schedule and of course us delegates a way to plan our weeks. The idea hits all the right notes of predictability and community care but I tempted to echo’s @jengajojo_daoplomats succinct reference that this will require a bit of social coordination that might not be desirable.

I dare say, VeloraDAO’s governance ultimately runs “live” on every block, not on our human calendars, we live and die by blocks kek. In itself by anchoring our process to UTC weekdays, we risk imposing artificial constraints on a system that’s fundamentally agoric, it really never really sleeps and should not sleep. Weekend engagement may dip but the chain never pauses and urgent security or distribution votes can’t wait for Monday morning.

On another note I urge our GTF *wink *wink @SEEDGov to asses some of the right approaches seen in the comments that script base or a criteria related to security safety should have a quicker faster trigger so we can get everything across to snapshot speedy and smooth, I’d be tempted to echo some of the thoughts I’ve put in the previous PIP to refresh governance that we should split in categories perhaps 2 enough Regular and Urgent where Regular tag follows the same approach adopted until now and Urgent a much shorter timeframe.

I once again appreciate Curia for taking time to draft and bring to discussion this topic, I am sure it will lead to fruitful efforts after a little crafting by Velorians. LFGrow

1 Like
13

First, we’d like to reassure the community in response to a valid concern raised by @citizen42: urgent proposals that require a quick response from the DAO are not PIPs (ParaSwap Improvement Proposals), but PEPs (ParaSwap Express Proposals) wich are regulated by this framework approved in PSP-IPΔ22: PSP 2.0 and are intended to respond to emergency situations that require swift action — including, but not limited to, vulnerability mitigation, PSP liquidity crises or matters related to the PSP 2.0 system (staking, fee/reward distribution, etc.), risks to user funds, attacks, or potential exploits and in general any situation where it is necessary to take agile and rapid actions. In such cases, shorter timeframes are established for both discussion and voting on Snapshot. The proposal presented by @Curia explicitly exempts such emergency proposals, so we want to reassure the community that this concern is already accounted for. This proposal, if approved, would only update the current PIP framework.

Additionally, we’d like to share a few pros and cons of the idea of setting Thursday as a fixed day for submitting proposals to Snapshot:

Pros:

  • Provides predictability for tokenholders and delegates, who will know exactly when to expect new proposals.
  • This regularity may help avoid missed votes and allow teams to better organize their schedules to respond thoughtfully to proposals.
  • In general, process standardization adds value through improved planning and participation.

Cons:

  • It could unnecessarily prolong timelines. For example, if a proposal is posted to the forum on a Wednesday and requires 7 days of discussion plus 2 days of frozen period, that takes us to Friday. With a “Thursday-only” rule, the proposal would have to wait nearly another week to be submitted on Snapshot — turning a 9-day process into 15 days before voting.
  • While this issue could be avoided by only posting proposals on Mondays or Tuesdays, that would “rigidify” the governance process, requiring strict planning of when to post and how long discussions can last — otherwise, one must wait until the next Thursday. This limits the natural flow and flexibility of the debate and voting process.

That said, we are still forming our opinion on the proposal and would like to hear more feedback from other community members before taking a definitive stance. We welcome the level of debate that is taking place and the diverse opinions we are reading!

2 Likes
14

Appreciate you for providing the data to bring more structure to the DAO.
As other delegates have mentioned, 7 days is slightly long, and 5 days should be sufficient for Snapshot voting.
Since the data shows most voting activity occurs on Thursdays and each proposal requires 9 days before being posted on Snapshot, I believe proposals should be posted on the forum at the start of the week—ideally on Monday—so they can be submitted to Snapshot almost immediately after the freeze period ends.

Of course, this shouldn’t be a strict rule that forces everyone to submit proposals only on Mondays. As @jengajojo_daoplomats pointed out, it should be part of our social coordination efforts. Since most proposals come from delegates and are already aligned with DAO rules, I don’t think there will be an issue in 99% of cases.

1 Like
15

Thank you @Curia for this proposal, appreciate you taking the time to analyse the DAO and put this forward. Your experience and expertise in the matter is very much welcomed.

Conceptually we agree that having clearer structure can be helpful, but given the smaller size of the DAO and the presently tight coordination between delegates we also feel that too much of this may just be counterproductive and unnecessary at this point. Similarly to what @jengajojo_daoplomats suggests, it might just add additional governance overhead.

Fully agree that voting during the weekend should be avoided as much as possible, but at the same time this could probably be avoided with a bit of common sense, though we are not opposed to the idea of constituting a set day for queuing proposals if other delegates wants it. Similarly, we are supportive of implementing a holiday break over Christmas and New Years.

However, extending the voting window is not something we agree with, as we believe 5 days is more than enough for VeloraDAO at this point.

Again, thank you for posting and facilitating this discussion.

1 Like
16

From our experience in other DAOs, instituting a more strict and predictable proposal cadence tends to aid in voter turnout, and generally, overall DAO organization. As long as there is a clear distinction between the PIP and PEP processes, we are willing to vote in favor of implementing a week-long PIP structure that predictably starts every Thursday.

But, the 7-day voting period, as others have pointed out, may be a bit excessive. In our opinion, as long as a vote doesn’t end on a weekend, proposals tend to achieve a satisfactory turnout rate. This is in a sense more important than the proposal being up for vote for 5 vs 7 days. Therefore, a start of day Monday til EOD Friday setup may make more sense if a 5-day window is kept. The presence of a delegate incentive programs also helps alleviate pains around voter turnout, so it doesn’t seems too worrisome if the voting period doesn’t last an entire week.

In any case, the difference between a 5-day and 7-day window for a PIP operationally would likely make negligible difference—but it seems to be the most contentious point so far. It would therefore be helpful to include that as a voting option during the Snapshot phase.

1 Like
17

Thank you all for your feedback. Most delegates felt that a seven-day window is too long and prefer returning to a five-day schedule. To accommodate both views, we’ve updated the proposal so delegates can choose between:

  • Seven-day Thursday-to-Thursday window: Opens at 00:00 UTC on Thursday and closes at 23:59 UTC the following Thursday.

  • Five-day Monday-to-Friday window: Opens at 00:00 UTC on Monday and closes at 23:59 UTC on Friday. In this track, authors must submit their proposals by 23:59 UTC on Sunday to meet the Monday start.

Both options keep voting strictly on weekdays to avoid weekend deadlines. These two tracks will appear on the Snapshot ballot so everyone can vote for their preferred cadence.

We truly appreciate everyone’s contributions to this proposal. We remain open to further adjustments to align with your vision and to make Velora’s operations more structured and accessible for all participants.

7 Likes
18

Thank you for the proposal, @Curia!
This proposal, offering two voting tracks, is attractive in providing delegates with options. However, it does not fundamentally resolve the core issue of responsiveness, the limitation of needing to wait until the following Thursday when urgent proposals arise earlier in the week. While improving predictability, the current proposal equally introduces drawbacks by potentially delaying decisions.

We see three possible alternative approaches to address this issue more effectively:

  1. Dynamic Quorum with Optimistic Voting:
    Implementing shorter voting periods with lower quorum thresholds can be achieved using Snapshot’s Optimistic Quorum model. Risks associated with expedited decision-making can be significantly reduced by mandating prior forum notice, and/or requiring explicit approvals from specific members at the forum stage.

  2. Easy Track (Lido Model):
    Adopt a model requiring no active voting unless a specified veto threshold is reached, facilitating swift approvals unless actively contested.

  3. Committee-based Operative Decisions:
    Delegate operative decisions to a dedicated committee, limiting the DAO’s role to overseeing and approving the committee’s structure, members, and overarching strategic direction.

We believe exploring these approaches would provide greater flexibility and responsiveness, ensuring that urgent governance needs are promptly addressed without compromising the integrity or transparency of DAO processes.

19

Thanks for this, @Tane. On the topic of responsiveness, I think that the options that you provided might bring on more negatives than the predictable voting schedule would. Optimistic quorum can deepen the problem of voter apathy (even more than usual; it’s even easier to do “nothing” rather than blindly voting “for” on every proposal). Auto-approvals (Easy Track) removes the need for an explicit community vote unless they have objections. Both of those, in my mind, make it more appealing for voters to be complacent and do less due diligence on proposals. Using a committee model also flies in the face of decentralization a bit. I’d rather see the DAO’s role remain expanded in making operations decisions. Again, the intentions behind this makes sense, I just think the OP structure introduces fewer tradeoffs.

This proposal, offering two voting tracks, is attractive in providing delegates with options. However, it does not fundamentally resolve the core issue of responsiveness

Wouldn’t a predictable schedule increase responsiveness, though? Both of the new windows keep voting on weekdays, and participation climbs from Monday through Thursday. I think the strongest path forward here is to move ahead with the improved weekly cadence as proposed (esp. the 5-day Monday-Friday track). It makes governance timing predictable and avoids weekend lulls. It keeps proposal turnaround quick.

Happy to hear other arguments though!

2 Likes
20

Appreciate the continued discussion in here. Don’t think the DAO needs optimistic governance nor a lower quorum threshold at the moment, seems like it would just introduce risk with little to gain. On the whole, we probably don’t need to rush any new changes to our voting system as of now, things are running fine and as contributors (through the Growth Committee) are holding conversations with service providers could come to have an impact on the DAO’s governance, implementing structures that may (somewhat soon) be replaced doesn’t seem like a top priority to be honest.

4 Likes