> ## Documentation Index
> Fetch the complete documentation index at: https://docs.exponent.finance/llms.txt
> Use this file to discover all available pages before exploring further.

# Governance

> Proposal voting system for Strategy Vaults

Strategy Vaults include a governance system that lets managers propose changes and vault depositors/LP holders vote (optional) on them.

Policy changes on a live vault (AUM > 0) must go through this proposal flow using `PolicyAction` — direct wrapper policy calls are restricted to vaults with zero AUM.

Governance settings such as voting period, timelock, and rejection threshold can be updated through the vault’s governance and settings flow.

## Proposal Lifecycle

```text theme={null}
Manager proposes → Voting period → Finalize → Timelock → Execute
```

1. **Propose** — manager creates a proposal with a `ProposalAction` (settings change or position update)
2. **Vote** — LP holders stake LP tokens to vote `Reject` or `OptOut` during the voting period

   <Info>
     Managers can disable vault depositor rejection voting by setting the voting period to 0 hours. In that configuration, proposals skip the voting step and proceed directly to the timelock phase, and depositors can no longer veto or block vault parameter changes.
   </Info>
3. **Finalize** — after the voting period ends, anyone can finalize to determine pass/reject
4. **Timelock** — if approved, the proposal enters a timelock period before execution
5. **Execute** — after the timelock passes, anyone can execute the approved proposal

Managers can cancel a proposal at any time before execution. For details on the voting model and proposal account structure, see [ActionProposal](/developer-strategy-vaults/account-references/action-proposal).

<Note>
  Sentinel operations (emergency pause/freeze) are currently managed by the Exponent core team.
</Note>

## Voting

Strategy Vault voting is **rejection-based**. Proposals pass by default unless depositors (vault LP holders) reject them with enough shares during the voting period to reach the [rejection threshold](/developer-strategy-vaults/typescript/governance/overview#rejection-threshold).

Vault depositors can vote in two ways:

* `Reject` — counts toward rejecting the proposal
* `OptOut` — counts toward rejecting the proposal and triggers a withdrawal queue for user funds if the proposal passes

Whether a proposal is rejected depends on the vault’s configured **rejection threshold**.

For a vault depositor’s vote to count, their funds must remain staked until the proposal has been finalized, which means they cannot simply vote and withdraw immediately afterward. If they change their mind during the voting period and wish to withdraw, they can remove their vote and therefore unstake their position.

<Callout icon="square-info">
  If a vault depositor voted `OptOut`  and the proposal passed, their position is automatically queued for withdrawal instead of being returned. If the proposal fails, their position remains unchanged in the vault.

  This feature allows depositors to protect themselves against sudden changes to the vault’s mandate.
</Callout>

### Voting Parameters

The voting model is configured at the vault level through governance parameters such as:

* `voting_enabled`
* `default_voting_period_seconds`
* `min_voting_period_seconds`
* `max_voting_period_seconds`
* `default_timelock_seconds`
* `rejection_threshold_bps`

This means the voting window and timelock are **not fixed globally** for every vault. They are configurable as part of the vault’s governance settings.

### Voting Period vs. Timelock

Voting and timelock are separate phases.

* The **voting period** is the time within which vault depositors can react to a proposal
* The **timelock** starts only after voting has ended and the proposal has been finalized as approved

For example:

* voting period = 2 days
* timelock = 3 days

In that case, the earliest execution time is about **5 days** after proposal creation.

### Rejection Threshold

Proposal rejection is controlled by `rejection_threshold_bps`.

By default, this is set to **33%**, meaning vault depositors must stake enough LP in Reject to cross that threshold during the voting period for the proposal to fail.

<Info>
  Managers can disable vault depositor rejection voting by setting the voting period to **0 hours**. In that configuration, proposals skip the voting step and proceed directly to the timelock phase, and depositors can no longer veto or block vault parameter changes.
</Info>

## Instructions

<CardGroup cols={2}>
  <Card icon="scroll" horizontal href="/developer-strategy-vaults/typescript/governance/propose-action" title="Propose Action">
    Create a governance proposal for settings or position changes.
  </Card>

  <Card icon="check-to-slot" horizontal href="/developer-strategy-vaults/typescript/governance/voting" title="Voting">
    Stake LP tokens to vote on proposals. Unstake after voting ends.
  </Card>

  <Card icon="play" horizontal href="/developer-strategy-vaults/typescript/governance/execute-proposal" title="Execute Proposal">
    Finalize and execute approved proposals.
  </Card>
</CardGroup>