Optimistic governance #396

pileks · 2026-01-10T23:46:01Z

This PR introduces optimistic governance, an alternative governance mode that allows the designated team address to propose treasury spends that automatically pass after a time delay unless challenged.

Overview

Optimistic governance enables faster treasury operations for routine spends while preserving the ability for token holders to challenge and force a full futarchy vote when needed.

Mechanics

Initiating an Optimistic Proposal

The team address (stored in dao.team_address) can call initiate_vault_spend_optimistic_proposal to create a token transfer proposal. This instruction:

Requires is_optimistic_governance_enabled to be true on the DAO
Requires the DAO to have no active proposal (pool must be in spot state)
Requires no other optimistic proposal to be currently enqueued
Caps the transfer amount at 3x the DAO's spending limit
Creates a Squads vault transaction and proposal
Stores the proposal reference and timestamp in dao.optimistic_proposal

Challenge Window

Once enqueued, the optimistic proposal enters a challenge window equal to seconds_per_proposal. During this period, anyone can challenge the proposal by initializing, staking to, and launching a futarchy proposal with the same Squads proposal, which:

Clears dao.optimistic_proposal
Launches a standard futarchy proposal
The spend must now pass the decision market to be approved (without the benefit of the team-sponsored pass threshold)

Finalization

After seconds_per_proposal elapses without a challenge, anyone can call finalize_optimistic_proposal to:

Have the DAO approve the Squads proposal
Clear dao.optimistic_proposal
The Squads vault transaction can then be executed normally

Safety Checks

Time-based protection: Proposals cannot be finalized before seconds_per_proposal elapses
Challenge cutoff: Once the time window passes, the proposal cannot be challenged via initialize_proposal (returns OptimisticProposalAlreadyPassed)
Launch guard: launch_proposal also checks that the optimistic proposal hasn't already passed, preventing edge cases where initialization succeeds but launch fails
Single proposal: Only one optimistic proposal can be active at any time
Amount cap: Transfer amounts are bounded by 3x the spending limit
No team sponsorship of challenges: The team cannot sponsor a futarchy proposal that challenges their own optimistic proposal. This prevents the team from benefiting from the team_sponsored_pass_threshold_bps when a challenge goes to a decision market.

State Changes

The Dao account gains two new fields:

optimistic_proposal: Option<OptimisticProposal> - tracks the active optimistic proposal if any
is_optimistic_governance_enabled: bool - feature flag (defaults to false)

OptimisticProposal contains:

squads_proposal: Pubkey - the Squads proposal that will be approved on finalization
enqueued_timestamp: i64 - when the optimistic proposal was created

New Instructions

initiate_vault_spend_optimistic_proposal - team-only, creates a transfer proposal
finalize_optimistic_proposal - permissionless, approves the Squads proposal after time delay

Refactoring

The compile_transaction_message helper was extracted to src/squads.rs as compile_squads_transaction_message for reuse across instructions that create Squads vault transactions.

…al if one exists

…e proposal has already passed but not been finalized yet

R-K-H

Only other thing is I don't think another proposal should be able to be created while there exists an unexecuted OGP.

programs/futarchy/src/instructions/collect_meteora_damm_fees.rs

programs/futarchy/src/instructions/mod.rs

scripts/v0.6/launchSOLO.ts

metaproph3t · 2026-01-16T19:04:10Z

programs/futarchy/src/instructions/finalize_optimistic_proposal.rs

+        match self.dao.amm.state {
+            PoolState::Spot { spot: _ } => {}
+            _ => {
+                return Err(FutarchyError::PoolNotInSpotState.into());
+            }
+        }


same comment with the matches!

metaproph3t · 2026-01-16T19:19:12Z

programs/futarchy/src/instructions/initiate_vault_spend_optimistic_proposal.rs

+    pub squads_multisig_vault: UncheckedAccount<'info>,
+
+    #[account(seeds = [squads_multisig_program::SEED_PREFIX, squads_multisig.key().as_ref(), squads_multisig_program::SEED_SPENDING_LIMIT, dao.key().as_ref()], bump, seeds::program = squads_program)]
+    pub squads_spending_limit: Account<'info, squads_multisig_program::SpendingLimit>,


make sure this is always one account

add a test for updating spending limit that optimistic governance still works

metaproph3t · 2026-01-16T19:22:02Z

programs/futarchy/src/instructions/initialize_dao.rs

+            optimistic_proposal: None,
+            is_optimistic_governance_enabled: false,


don't we need to add some update account instructions again here

theoretically this could be a separate PR but I prefer it in this one

update_dao handles updating already. We decided to go with false as a default on creation as we don't want it on when a new DAO gets created. We can add a param to creation if you want to.

metaproph3t · 2026-01-16T19:29:58Z

programs/futarchy/src/instructions/initialize_proposal.rs

    pub fn validate(&self) -> Result<()> {
+        // If we're trying to challenge an optimistic proposal that has already passed due to age, we should error
+        // This is because the optimistic proposal's Squads proposal will eventually have to be executed
+        match self.dao.optimistic_proposal {


I think an if let would be better here

metaproph3t · 2026-01-16T19:30:39Z

programs/futarchy/src/instructions/initiate_vault_spend_optimistic_proposal.rs

+
+    /// CHECK: The squads multisig vault that executes the transaction
+    #[account(seeds = [squads_multisig_program::SEED_PREFIX, squads_multisig.key().as_ref(), squads_multisig_program::SEED_VAULT, 0_u8.to_le_bytes().as_ref()], bump, seeds::program = squads_program)]
+    pub squads_multisig_vault: UncheckedAccount<'info>,


wouldn't have this be unchecked unless necessary

Note - Squads Multisig Vaults don't have any data, they are just derived addresses.
Disregarding this comment for now.

metaproph3t · 2026-01-16T21:25:45Z

programs/futarchy/src/instructions/initiate_vault_spend_optimistic_proposal.rs

+        match self.dao.amm.state {
+            PoolState::Spot { spot: _ } => {}
+            _ => {
+                return Err(FutarchyError::PoolNotInSpotState.into());
+            }
+        }


metaproph3t · 2026-01-16T21:27:37Z

programs/futarchy/src/instructions/initiate_vault_spend_optimistic_proposal.rs

+        match self.dao.optimistic_proposal {
+            Some(ref optimistic_proposal) => {
+                require_gte!(
+                    Clock::get()?.unix_timestamp,
+                    optimistic_proposal.enqueued_timestamp + self.dao.seconds_per_proposal as i64,
+                    FutarchyError::ProposalDurationTooShort
+                );
+            }
+            None => {}
+        };


I don't like ever enqueuing an optimistic proposal while another one is still there, I'd rather add an instruction to remove the optimistic proposal

metaproph3t · 2026-01-16T21:29:11Z

programs/futarchy/src/instructions/initiate_vault_spend_optimistic_proposal.rs

+
+        // Amount must be less than or equal to 3 times the spending limit
+        require_gte!(
+            self.squads_spending_limit.amount.checked_mul(3).unwrap(),


checked_mul unwrap is equivalent to just doing multiplication because anchor has the overflow checks

metaproph3t · 2026-01-16T22:12:44Z

programs/futarchy/src/instructions/launch_proposal.rs

+                self.proposal.squads_proposal
+            );
+
+            // The optimistic proposal must be younger than seconds_per_proposal, otherwise it is considered passed and must be finalized


also check that it's unpassed

This actually applies in general, so the check will be outside this condition.

metaproph3t · 2026-01-16T22:13:32Z

programs/futarchy/src/instructions/launch_proposal.rs

        proposal.timestamp_enqueued = clock.unix_timestamp;

+        // Update the DAO state
+        if dao.optimistic_proposal.is_some() {


you don't need to do this, can just do
dao.optimistic_proposal = None and clear out any active proposal

metaproph3t · 2026-01-16T22:21:19Z

programs/futarchy/src/instructions/sponsor_proposal.rs

+        // Team cannot sponsor a challenge to an optimistic proposal
+        if let Some(optimistic_proposal) = &self.dao.optimistic_proposal {
+            require_keys_neq!(
+                optimistic_proposal.squads_proposal,
+                self.proposal.squads_proposal,
+                FutarchyError::CannotSponsorOptimisticProposalChallenge
+            );
+        }


idk if we need this

After our conversation, we don't.

pileks · 2026-01-16T22:55:08Z

After talking to @metaproph3t we came to the following conclusion:

Converting an optimistic proposal to a regular market proposal (by means of using launch_proposal) should make that proposal team-sponsored.

…istic-governance

metaproph3t · 2026-01-17T00:16:45Z

LGTM aside from the account resizing

…AOproject/programs into pileks/met-5-optimistic-governance

…istic-governance

pileks added 11 commits January 8, 2026 22:34

wip

31dd49b

wip

a303f5c

implementation of initiation of new optimistic governance proposal

81064fd

add finalize optimistic proposal ix

2e85455

launch_proposal should only be able to challenge an optimistic propos…

7f458ea

…al if one exists

minor cleanups

63ed333

tests for optimistic vault transaction proposal initiation

8606360

optimistic proposal finalization tests

6702eaf

prevent initialization of futarchy proposal when optimistic governanc…

69a4b61

…e proposal has already passed but not been finalized yet

add missing check

27962d0

team can't sponsor a challenge to an optimistic governance proposal

2aa4420

pileks requested review from R-K-H, jrooks7 and metaproph3t January 10, 2026 23:46

pileks self-assigned this Jan 10, 2026

R-K-H requested changes Jan 13, 2026

View reviewed changes

programs/futarchy/src/instructions/collect_meteora_damm_fees.rs Show resolved Hide resolved

programs/futarchy/src/instructions/mod.rs Show resolved Hide resolved

scripts/v0.6/launchSOLO.ts Show resolved Hide resolved

metaproph3t reviewed Jan 16, 2026

View reviewed changes

pileks added 2 commits January 16, 2026 15:24

work-in-progress PR comments

0d55d11

Merge remote-tracking branch 'origin/develop' into pileks/met-5-optim…

5d012b1

…istic-governance

address review comments

c98ce2e

pileks and others added 6 commits January 16, 2026 17:02

reintroduce resize_dao crankable instruction with scripts

484e7ad

reintroduce resize_dao crankable instruction with scripts (#400)

62e4d8a

Merge branch 'pileks/met-5-optimistic-governance' of github.com:metaD…

a1acfaf

…AOproject/programs into pileks/met-5-optimistic-governance

Merge remote-tracking branch 'origin/develop' into pileks/met-5-optim…

4731cf6

…istic-governance

Merge remote-tracking branch 'origin/develop' into pileks/met-5-optim…

d05c432

…istic-governance

remove duplicate optimistic proposal check

98dfe15

		optimistic_proposal: None,
		is_optimistic_governance_enabled: false,

Optimistic governance #396

Are you sure you want to change the base?

Optimistic governance #396

Uh oh!

Conversation

pileks commented Jan 10, 2026

Overview

Mechanics

Initiating an Optimistic Proposal

Challenge Window

Finalization

Safety Checks

State Changes

New Instructions

Refactoring

Uh oh!

R-K-H left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pileks Jan 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pileks commented Jan 16, 2026

Uh oh!

metaproph3t commented Jan 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

pileks Jan 16, 2026 •

edited

Loading