No Drama DAO: Where Snapshot Mirrors Aragon, Put It All Onchain

[zuzu_eeka]

TL;DR

This proposal suggests removing the separate Snapshot vote for a specific subset of proposals: those where the Snapshot and Aragon votes are effectively two parts of the same decision, split across two consecutive voting slots for historical reasons. In these cases, the Snapshot confirms the design and the very next Aragon vote executes it onchain. Instead of two votes, the full off-chain context will be uploaded to IPFS and embedded directly in the Aragon vote description.

Proposed process: Forum post with full context is published → Discussion and feedback → Off-chain text is frozen on IPFS → Announcements → Aragon vote launched with IPFS links embedded.

This shortens proposals’ time-to-market, lowers the number of votings and operational costs, reduces governance noise, and simplifies proposal coordination.

Background

Some proposals go through two separate voting stages back-to-back: first on Snapshot (offchain), then on Aragon (onchain), usually in the next voting slot. In these cases, the Snapshot vote confirms the offchain context (design, motivation, side decisions), and the Aragon vote executes the onchain actions - together they form one decision, split into two steps.

Examples of proposals in scope:

• Protocol releases where the Snapshot confirms the final design and Aragon executes onchain
• Oracle committee member rotations
• Operational actions such as Easy Track parameter changes (adding/removing setups, changing limits)

What is usually approved on Snapshot:

• General description of the decision and motivation behind the initiative (e.g., design (LIP) for technical releases, new oracle portfolio, etc.).
• Related side actions, such as increasing share limits alongside the CSMv2 release.
• Committee creation for follow-up work.
• And so on.

What is approved on Aragon:

• Onchain actions required to launch the initiative.

Why the Snapshot stage is no longer necessary for these cases

1. Aragon now supports full-text descriptions. Previously, it was not possible to attach meaningful textual context to an Aragon vote. That is no longer the case - offchain context can now be uploaded to IPFS and embedded directly in the vote description.

2. The Aragon main phase is now 72 hours. When Aragon votes lasted only 24 hours, it made sense for voters to review the proposal on Snapshot beforehand. With a 72-hour main phase and sharing context in advance, voters have sufficient time to review both on-chain and off-chain components in a single stage.

What problem are we trying to solve? Why this matters

• Votes become integrated, not fragmented. Voters get the full context once, and at the point of execution.
• Fewer votes decrease governance noise.
• It decreases time-to-market for proposals that now have to wait two months before execution (e.g., Oracle rotations, example).
• Removing a step cuts operational overhead and governance costs.
• Quorum needs to be reached only once instead of twice for the same project.

Proposal

It is proposed to move from a two-stage Snapshot + Aragon flow to a single-stage Aragon vote for proposals where Snapshot effectively duplicates the Aragon stage, with the full off-chain context uploaded to IPFS and embedded in the onchain vote description.

What this does NOT apply to

This proposal does not cover all on-chain votes. Snapshot remains the appropriate stage for:

• Temperature checks on controversial or uncertain proposals
• Early signal votes for major decisions that do not follow directly from GOOSE or other previously approved initiatives, where tokenholder alignment is needed before committing to development or execution.
• Proposals where a forum discussion reveals a lack of convergence or significant unresolved concerns. In this case, a Snapshot vote can still be launched as an intermediate step before Aragon.

Voting slot frequency is expected to remain roughly the same (approximately once a month). The difference is that proposals that were previously split across two consecutive slots, as Snapshot + Aragon, will now go through as a single Aragon vote.

Anti-bloat principle: DAO Ops and proposers should avoid creating overly bloated onchain votes. Major initiatives should be separated into distinct Aragon votes; if combining is necessary for operational efficiency, the total scope must remain reviewable within the standard timeframe.

Process

It is proposed to adopt the following DAO-facing process for proposals in scope:

1. Forum post published presenting both the onchain and offchain context, no later than 10 days before the Aragon launch (unless it is an emergency).

   Note: A 10-day time is the minimum and works only for “straightforward” proposals or operational onchain actions where we do not expect meaningful tokenholder feedback, and any changes are unlikely.

   For protocol releases, a forum post should be published well in advance to give all participants time for review and feedback.

   With no Snapshot stage, sufficient discussion time is critical - rushing it would undermine transparent, accountable governance.

2. Discussion on the forum; feedback is collected, and the final version of the proposal is crafted and polished.
3. Off-chain and on-chain scope freeze. The final off-chain text is uploaded to IPFS.
4. Announcements. The proposal set is distributed through all communication channels.
5. Aragon vote starts, combining both the offchain and onchain context into a single package.

Voting UI improvements

Moving offchain context into Aragon requires UX improvements to ensure voters can navigate and review proposals effectively.

Key changes planned for the dao.lido.fi portal interface:

Main page:

• Keyword search across titles and descriptions, enabling voters to find information and track history.
• Improved proposal display: show vote title instead of truncated description snippets, one proposal per line for better readability.

Vote details page:

• Vote title displayed prominently.
• Restructured description format: a lightweight, readable summary with links to full IPFS descriptions, forum discussions, and mapping to onchain items. Example:

  1. Rotate Lido on Ethereum Oracle Set member Kyber Network for Caliber | Full proposal on IPFS | Forum discussion | Onchain items 1.1–1.6.
  2. Increase CSM stake share limit from 2% to 3% | Full proposal on IPFS | Forum discussion | Onchain item 1.7.
  3. Enable a grace period for CSM Node Operators by setting keyRemovalCharge = 0 **| Full proposal on IPFS | Forum discussion | Onchain items 1.8-1.10.
  4. Introduce a simplified CSVerifier for CSM. | Full proposal on IPFS | Forum discussion | Onchain items 1.11, 1.12.

• Link-read color indicators in the description for navigation.
• Notice next to the vote button indicating that offchain items are also approved with the vote.
• Backward compatibility: fallback display mode for historical votes or uncoordinated third-party votes that do not follow the new structure.

Technical notes

• No changes to the core Aragon voting contracts are required.
• The voting scripts and off-chain tooling rely on implicit data structure assumptions (e.g., parsing titles from the first line of ipfs_description, extracting IPFS links).
• Governance bots and notification systems will be updated to parse the new data structure.

Next steps

The DAO has never formally voted to approve the two-stage governance flow itself as a binding rule. Since all proposals within this scope ultimately require an Aragon onchain vote to be approved by the DAO, which is embedded in the protocol, tokenholders and delegates effectively endorse or reject the decision-making process when they vote on a proposal. Given that, it is recommended that no separate vote be held on this procedural change.

Tokenholders and delegates are encouraged to share their feedback here on the forum.

Once the voting UI improvements are implemented (targeted for Q2 2026), the first proposals will go through the new single-stage flow. Voters, delegates, and the community will be informed in advance. Stay tuned.

[Leuts]

Massive yes!

This change saves every stakeholder time and energy both in DAO ops and voter fatigue.

[FP_Validated]

Wow! As a protocol specialist who has extensively studied governance frameworks—and as a newbie on Lido governance—I’ve been impressed by Lido’s structured governance framework.

But at the same time, I observed there is a clear distinction between agendas that require broader discussion and those that do not as you pointed out.

Would like to support for this proposal ! Let’s reduce governance fatigue

[Nansen]

Supportive of this proposal. Collapsing the Snapshot + Aragon flow into a single Aragon vote for “mirror” proposals removes latency and governance overhead without losing signal.

We agree that the scoping works. Keeping Snapshot for temperature checks and contested proposals means the deliberation layer stays where it adds value. The 72-hour main phase and embedded proposal context give delegates enough review time in one stage.

Just one detail, who makes the call on the 10-day minimum forum window for “straightforward” proposals? Perhaps could include clearer guidance on who makes that call, so delegates can plan accordingly.

[cp287]

I am for it.

Definitely cuts down bureaucracy for a lot of votes. Not entirely sure how “controversial or uncertain proposals” get defined though (arguably every proposal is uncertain, otherwise why would anyone need to express an opinion through a vote?), especially given there’s already a third point about “lack of convergence on the forum”.

[polar]

Strongly support. This should help substantially with delegate ability to assess proposals. Currently the process can feel a little repetitive due to the doubling up. The new process looks leaner and has plenty of safeguards.

[katernoir]

Perfectly fine to do it this way for me. I think my biggest concern would be temperature checks or developing costs that then get voted NO on, but the proposal is already clearing these up. So we can ship as is

[batuX]

Streamlining voting to save everyone’s time. In support.

[cp0x]

Thanks for the proposal — the direction makes sense and the operational benefits are clear.

1. Who decides what counts as a “temperature check candidate” – and how?

   In practice, who makes that call – and at what point in the process? The proposal currently leaves this to DAO Ops and proposers on a case-by-case basis. @Nansen already flagged a related concern around the 10-day minimum window. I’d extend that: without a clearer decision rule (even a lightweight one), there’s a risk that proposals which should get a temperature check skip it simply because no one formally triggered one. Could the proposal define a minimal checklist or a named accountable role for this judgment?

2. Moving from 7 days to 3 days of “yes” voting?

   Would it make sense to consider extending the Aragon main phase for proposals transitioning under this new flow – for example to 5 days – to compensate for the removal of the Snapshot window? The objection phase could remain as-is. This seems especially relevant given that Lido already extended the main phase from 48h to 72h in March 2025 specifically to address declining participation.

3. What are the actual costs being saved here?

   Just to be precise, it’s probably worth talking only about time as a resource that we save. (Snapshot is gasless)

[Leuts]

1. If you feel censored offchain then someone can just put the vote onchain, there’s no change to that.
2. We already have to do the 3 days anyways now, we just have to do 7 days before. This just removes the 7 days. So there’s no change on reaction time required.
3. Saving time and mental bandwidth is worth millions of dollars.

[cp0x]

1. I simply need to understand the rules of the game—in what cases what is done and who decides it.
2. Previously, people had seven days to decide what to vote for—now they only have 3. The challenge is giving delegates time to think things through, ask questions, and get answers before rushing into a vote.

[zuzu_eeka]

@Nansen

Just one detail, who makes the call on the 10-day minimum forum window for “straightforward” proposals? Perhaps could include clearer guidance on who makes that call, so delegates can plan accordingly.

Hi @Nansen!
Good question. The call sits with the proposer, with DAO Ops workstream as a sanity check.
10 days is a floor, not a target. If the window is too tight for the scope, the proposal can fail simply because tokenholders and delegates didn’t have time to engage.
That risk is on the proposer, which is why defaulting to the minimum is a bad strategy.

[zuzu_eeka]

Hello @cp0x !

1. who decides temperature check candidate

Thanks, worth unpacking this.

For proposals coming from Lido Foundations contributors, the call is made by DAO Ops together with the Team preparing the change.

DAO Ops team will take into account:

• if the initiative is a part of the GOOSE goals
• if there is an obvious operational need for this

And for sure, if after publishing it on the research forum discussion showed a reasonable level of controversy it will go with the long flow: with a Snapshot temp check and then an on-chain vote.

On the risk framing: I’d reframe slightly. “proposals which should get a temperature check skip it simply because no one formally triggered one” isn’t really a risk, it’s a procedural observation. The actual risk worth managing is: a proposal doesn’t get enough engagement and fails to gather support from tokenholders and delegates.

That risk is mitigated by (a) the fact that contributors develop proposals internally in depth, taking all the details and nuances into account, and most of them when published aren’t controversial precisely for that reason (which is a feature, not a bug), (b) clear publication with the full context in one place, and (c) broadcasting at step 4. If any of those are skipped or rushed, the proposal carries the cost.

2. extending main phase to 5 days

Helpful to understand what is a goal for that action or a risk it is meant to mitigate. I’d guess the same one as above: insufficient engagement leading to weak support.

If so, the proposed model actually improves on the status quo. Today tokenholders get 7 days on Snapshot + 3 days on Aragon, with roughly a month gap in between and context fragmented across two stages. In the new model they get at least 10 days on the forum + 3 days on Aragon, back-to-back, with consistent context in one place. In terms of time and clarity to engage, single-stage looks better, not worse.

Additionally, slowing down potential governance reactions at DAOs like Lido increases the cost of failure for the entire DAO. It’s better to have those risks thinner than the risk that not enough holders will engage with the proposal before the on-chain vote starts.

3. actual costs

“Costs” here means time and coordination overhead, not gas; Snapshot is gasless, agreed.

That said, this proposal isn’t really about cost savings. It’s about removing awkward legacy from the process. Preparation effort stays roughly the same. What goes away is the duplicate quorum chase, the ~month-long gap between stages, context fragmented across two votes, and governance noise from votes that have mirrored Aragon 100% of the time in this scope.