Abstract

This proposal is designed to test the Security Council veto mechanism within the RARI DAO v2 governance system on RARI Chain. It simulates the submission of a proposal that will intentionally be vetoed by the Security Council to confirm that the veto function works as expected and provides a reliable safeguard against harmful or erroneous proposals.

---

Rationale

The Security Council is a critical failsafe in the DAO’s governance design, empowering a trusted multisig to block proposals that may pose urgent risk to the protocol, community, or treasury. Before this power is relied upon in a live scenario, it must be tested in a controlled and transparent manner.

---

Motivation

To validate the full governance safety framework, this test proposal will:

• Confirm that the Security Council has the authority and technical ability to veto a live proposal
• Demonstrate that a vetoed proposal is halted and not executable, regardless of its voting outcome
• Build confidence among delegates and tokenholders that security mechanisms are operational
• Encourage shared understanding of roles and responsibilities within the DAO

---

Specifications

1. Proposal Action

This proposal will include a simple token transfer action with an amount of 0.001 ETH.

This proposal is expected to pass community voting but will be vetoed by the Security Council before execution.

2. Security Council Veto

Once the proposal has passed voting, but during the timelock, the Security Council will veto the proposal.

After the veto is recorded:

• The proposal will be marked as vetoed onchain
• Execution will be blocked
• Voters and delegates will be notified through governance channels

---

---

Steps to Implement

1. Proposal Submission: Submit a benign proposal that does not cause state changes
2. Voting: Tokenholders vote to approve the proposal, simulating normal support
3. Security Council Action: After vote passes, Security Council vetoes the proposal onchain
4. Confirmation: Proposal status changes to "vetoed"; execution becomes unavailable
5. Postmortem: Technical analysis and delegate feedback published

---

Timeline

• Week 1: Voting period + Security Council coordination
• Week 2:
• Week 3: Veto is executed; proposal is blocked; postmortem shared

---

Costs

N/A