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:
- 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.
- Discussion on the forum; feedback is collected, and the final version of the proposal is crafted and polished.
- Off-chain and on-chain scope freeze. The final off-chain text is uploaded to IPFS.
- Announcements. The proposal set is distributed through all communication channels.
- 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:
- Rotate Lido on Ethereum Oracle Set member Kyber Network for Caliber | Full proposal on IPFS | Forum discussion | Onchain items 1.1–1.6.
- Increase CSM stake share limit from 2% to 3% | Full proposal on IPFS | Forum discussion | Onchain item 1.7.
- Enable a grace period for CSM Node Operators by setting
keyRemovalCharge = 0**| Full proposal on IPFS | Forum discussion | Onchain items 1.8-1.10. - 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.