The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
Thanks for putting this together.
We support moving to one election per year because it should reduce fatigue and help delegates spend more time on actual evaluation. To protect predictability, could we add a simple rule to setCadence: any change takes effect only for the next cohort with at least 90 days of notice, and never extends a cohort already in its final 90 days.
If we go that route, it would help to either link the candidate declarations where applicants agreed to a potential extension, or collect an explicit confirmation from seated members before enactment. Publishing a three year election calendar alongside this AIP would make planning easier for candidates and delegates.
As mentioned by @jameskbh, @0xDonPepe & @JoJo as well, we think competition should stay live each cycle. In the last election, 22 candidates registered and 13 reached the bar at 0.2% of Votable Tokens to advance, so the pipeline already looks healthy. And in the final round, voting power decayed over time to encourage early participation, which is a useful protection on its own.
Instead of an auto-pass, a lighter continuity test could work: a small micro-threshold plus a minimum number of unique endorsers, and a short “term report” in the forum post covering attendance and incidents handled, so delegates can judge recent service.
Also, the proposal mentions “0.1% of circulating ARB” while the Constitution uses Votable Tokens for thresholds and defines the vote-decay schedule. It would be clearer if the proposal, the code, and the docs all use the same term (Votable Tokens).
This direction makes sense; we’ve had non-emergency rotations before, and a clearer path will reduce friction. Two asks to make this safer in practice.
First, please publish a public feed of rotations as they happen, not just Foundation monitoring, and link it from the elections page.
Second, add a simple emergency playbook: if a key is suspected of being compromised, place it in a “containment” state with no upgrade actions until the standard rotation completes, and publish a short incident note within 48 hours. It would also help if the compliance checklist required hardware-backed or threshold wallets and included an attestation template.
Lastly, the Constitution today says a Snapshot temperature check “can only be submitted by an address that can vote at least 0.01% of the Votable Tokens,” and the AIP proposes a fixed 500,000 ARB threshold. A fixed number can drift as supply and delegation change. If possible, please consider keeping it proportional with a floor and a cap, or document how and when the threshold will be reviewed so the bar stays fair over time.
Net, we’re supportive if these guardrails are added. They keep the spirit of your changes while tightening accountability and transparency for the DAO.