Make mini instructions opt in

[metapileks]

Typed proposals (the mini-instructions catalog) become a per-DAO switch instead of applying to every DAO the moment the program upgrades. New DAOs start with the switch on. Migrated DAOs start with it off and keep running under their own configuration until they pass an update_dao proposal that turns it on. The switch is one-way.

Alongside that, launch_proposal now writes a proposal's duration, pass threshold and TWAP start delay from the configuration in force at launch rather than at create. A draft only carries a preview, so a draft created before the opt-in launches under the catalog after it. Admin-tuned values are the one exception and survive launch.

Instruction changes

Instruction	Change
initialize_dao	New DAOs start with typed_proposals_enabled = true.
update_dao	New typed_proposals_enabled: Option<bool>. Some(true) opts in, None leaves it alone, Some(false) is refused with TypedProposalsCannotBeDisabled.
resize_dao	Migrated DAOs start with typed proposals off. A zero min_quote_futarchic_liquidity or min_base_futarchic_liquidity is lifted to 1, since zero fails Dao::invariant and would block the opt-in for the live DAOs configured that way.
initialize_proposal	The draft snapshots a preview from params_for: the DAO's own terms while off, the catalog once on.
typed_initialize (all typed kinds)	Refused with TypedProposalsDisabled while the DAO has typed proposals off.
launch_proposal	Typed kinds refused with TypedProposalsDisabled while off. Writes duration, threshold and TWAP start delay from Proposal::launch_params, which resolves the terms in force at launch and keeps admin-tuned values when params_overridden is set. The duration-vs-warm-up check runs against those terms.
admin_update_proposal_params	Sets params_overridden so launch preserves the tuned duration and threshold. Its duration check uses the same per-DAO warm-up as launch.
resize_proposal	Drafts migrate to a preview from params_for, including the team-sponsored threshold where it applies. Launched proposals keep the rules they launched under.
initialize_hostile_takeover_proposal	Its inner update_dao payload leaves the new flag untouched.

State, events and errors

• Dao.typed_proposals_enabled: bool and Proposal.params_overridden: bool, one byte each. The resize_dao and resize_proposal pre-migration size constants move by one accordingly.
• ProposalAction::params_for(dao, is_team_sponsored) returns the DAO's own duration, threshold and warm-up for plain proposals of a DAO with typed proposals off, and the catalog otherwise. Proposal::launch_params(dao) layers the admin override on top.
• InitializeDaoEvent and UpdateDaoEvent gain typed_proposals_enabled; LaunchProposalEvent gains the written duration_in_seconds and pass_threshold_bps.
• Errors appended: TypedProposalsDisabled, TypedProposalsCannotBeDisabled.

SDK and scripts

Regenerated futarchy v0.6 types (UpdateDaoParams.typedProposalsEnabled), and scripts/utils/daoActions.ts swaps a stale isOptimisticGovernanceEnabled for typedProposalsEnabled in its empty-params constant.

Greptile Summary

This PR makes typed proposals a one-way, per-DAO opt-in and migrates existing DAOs with the feature disabled while enabling it for newly initialized DAOs. It also resolves proposal launch parameters from the configuration active at launch, preserves explicitly admin-tuned terms, updates account and event schemas, regenerates SDK types, and adds migration and opt-in coverage.

• Gates typed proposal initialization and launch on DAO opt-in.
• Migrates DAO and proposal accounts with the new state fields.
• Applies current duration, threshold, and TWAP delay when proposals launch.
• Adds unit and end-to-end coverage for migration, opt-in, launch, and admin override behavior.

Confidence Score: 5/5

The PR appears safe to merge; no new actionable issue was introduced since the previous review.

The only change since the previous review clarifies the intentionally shared duration-and-threshold override behavior without changing execution. metapileks accepted that partial admin updates preserve both values because changing proposal parameters is intentionally treated as applying to both. metapileks also accepted the queued-update compatibility constraint based on performing the controlled upgrade with no queued or unexecuted DAO updates and retaining an admin fallback.

Important Files Changed

Filename	Overview
programs/futarchy/src/instructions/update_dao.rs	Adds the one-way typed-proposals opt-in parameter and persists its resulting state.
programs/futarchy/src/instructions/launch_proposal.rs	Enforces typed-proposal opt-in and writes the effective launch parameters into the proposal and market.
programs/futarchy/src/state/proposal.rs	Adds admin-override state and resolves effective launch parameters.
programs/futarchy/src/instructions/resize_dao.rs	Migrates existing DAOs with typed proposals disabled and normalizes invalid zero liquidity minimums.
programs/futarchy/src/instructions/admin_update_proposal_params.rs	Marks admin-tuned proposal parameters for preservation at launch and now documents the accepted shared-override behavior.
tests/futarchy/integration/typedProposalsOptInEndToEnd.test.ts	Covers migration, opt-in governance, typed instruction gating, and transition to catalog launch terms.

_{Reviews (2): Last reviewed commit: "add clarifying comment" | Re-trigger Greptile}

[github-actions]

Repository Guard

• Cargo.lock: pass
• yarn.lock (sdk): pass
• yarn.lock (root): pass
• Repo guard: pass

Repository Guard

Cargo dependency pinning

• Status: pass
• Every programs/*/Cargo.toml dep uses =x.y.z, a path = .. workspace ref, or a git dep with a 40-char rev.

Cross-program Anchor/Solana version consistency

• Status: pass
• anchor-lang and anchor-spl are pinned to the version declared in repo-guard.toml across every program.

solana-program crate pin

• Status: pass
• Every solana-program = "=X" declaration is =1.17.14 (locked to match Cargo.lock).

Anchor.toml solana_version

• Status: pass
• Anchor.toml declares solana_version = "1.17.34" (local-dev install for anchor test).

Crate minimum age

• Status: pass
• All Cargo deps changed by this PR are at least 14 days old on crates.io.

Yarn package.json pinning

• Status: pass
• All package.json deps use exact versions (no ^, ~, ranges).

npm minimum age

• Status: pass
• All npm deps changed by this PR are at least 14 days old.

Workflow toolchain consistency

• Status: pass
• Every workflow declares anchor-version: 0.29.0.
• Per-file solana-cli-version values match [toolchain.workflow_solana_cli] in repo-guard.toml.

GitHub Action SHA pinning

• Status: pass
• Every third-party action is pinned to a SHA in [actions.sha_allowlist].

Sensitive program / config changes

• Status: warn
• Review hint only (CODEOWNERS is the merge gate). Lines below match heuristics for security-sensitive changes:
• High-sensitivity files touched: Anchor.toml, Cargo.lock
• programs/futarchy/src/instructions/admin_enqueue_multisig_proposal_cancellation.rs:7 declare_id! literal change; Hardcoded Solana address literal -> + declare_id!("6awyHMshBGVjJ3ozdSJdyyDE1CTAXUwrpNMaRGMsb4sf");
• programs/futarchy/src/instructions/admin_update_proposal_params.rs:7 declare_id! literal change; Hardcoded Solana address literal -> + declare_id!("6awyHMshBGVjJ3ozdSJdyyDE1CTAXUwrpNMaRGMsb4sf");
• programs/futarchy/src/instructions/initialize_hostile_liquidate_proposal.rs:7 declare_id! literal change; Hardcoded Solana address literal -> + declare_id!("6awyHMshBGVjJ3ozdSJdyyDE1CTAXUwrpNMaRGMsb4sf");
• programs/futarchy/src/instructions/initialize_hostile_takeover_proposal.rs:42 Program ID constant or variable change -> + program_id: crate::ID,
• programs/futarchy/src/instructions/initialize_hostile_takeover_proposal.rs:82 Program ID constant or variable change -> + program_id: crate::ID,
• programs/futarchy/src/instructions/initialize_mint_tokens_proposal.rs:99 Program ID constant or variable change -> + program_id: mint_governor::ID,
• programs/futarchy/src/instructions/initialize_spending_limit_change_proposal.rs:39 Program ID constant or variable change -> + program_id: crate::ID,
• tests/futarchy/integration/typedProposalsOptInEndToEnd.test.ts:24 Hardcoded Solana address literal -> + "MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr",
• tests/futarchy/unit/executeMultisigProposalCancellation.test.ts:145 Program ID constant or variable change -> + programId: multisig.PROGRAM_ID,
• tests/futarchy/unit/executeMultisigProposalCancellation.test.ts:157 Program ID constant or variable change -> + squadsMultisigProgram: multisig.PROGRAM_ID,
• tests/futarchy/unit/initializeBuybackTokenProposal.test.ts:28 Hardcoded Solana address literal -> + "MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr",
• tests/futarchy/unit/initializeHostileLiquidateProposal.test.ts:67 Hardcoded Solana address literal -> + programId: new PublicKey("MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr"),
• tests/futarchy/unit/typedProposalsOptIn.test.ts:12 Hardcoded Solana address literal -> + "MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr",

Overall status: pass

Lockfile freshness (Cargo.lock + yarn.lock) is checked by the workflow directly and cannot be bypassed. The sensitive-diff section is a review hint - CODEOWNERS handles the actual merge gate.