> ## 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.

# Vault Roles & Control

> Understand how Strategy Vault authority is split across roles, Squads accounts, and governance flows.

***

Strategy Vaults are controlled through a combination of **role-based permissions**, **Squads smart accounts**, and optional **proposal-based governance flows**.

This page explains who controls a vault, how that control is exercised onchain, and how to think about the distinction between the **manager signer**, the **vault smart account**, and the **governance flow** for vault changes.

## Strategy Vault Control Model

At a high level, a Strategy Vault has three different control surfaces:

1. **Vault roles** — role lists stored directly in the `ExponentStrategyVault` account
2. **Squads accounts** — the vault’s settings account and smart account used for execution
3. **Governance flow** — proposal, voting, timelock, and execution for certain vault changes

## The Main Accounts

The `ExponentStrategyVault` account stores the core vault configuration and authority references, including:

* `roles`
* `squads_settings`
* `squads_vault`
* `token_entries`
* `strategy_positions`
* financial state and vault config

### `squads_settings`

The **Squads settings account** stores smart-account configuration, signers, and policies. It governs what the Strategy Vault smart account can do.

### `squads_vault`

The **Squads smart account** is the execution account for the vault. It is the account that:

* holds funds on behalf of the vault
* signs CPIs as the vault
* executes policy-constrained interactions with external protocols

<Info>
  The **manager key is not the vault’s fund-holding account**. The vault’s assets and CPI authority live under the **Squads smart account**.
</Info>

## Vault Roles

The vault stores role membership in `VaultRoles`:

```rust theme={null}
pub struct VaultRoles {
    pub manager: Vec<Pubkey>,
    pub curator: Vec<Pubkey>,
    pub allocator: Vec<Pubkey>,
    pub sentinel: Vec<Pubkey>,
}
```

<Tabs>
  <Tab title="Manager">
    The **manager** is the main administrative and operational role of the vault. Managers are responsible for vault-level configuration, role management, tracked strategy position updates, and governance proposal creation.

    The manager key is an authorized control signer, but it is **not** the vault’s asset-holding account. Vault assets and CPI authority remain under the vault’s **Squads smart account**.

    ```ts theme={null}
    // Typical manager-controlled responsibilities
    // - manage vault settings
    // - update role sets
    // - update tracked strategy positions
    // - create governance proposals
    ```

    **Basic role management flow**

    1. Fetch the current vault state
    2. Read `vault.roles.manager`
    3. Add, remove, or replace the relevant manager public key
    4. Submit the corresponding manager-authorized update
    5. Refetch the vault and verify the new manager set onchain

    **Use this role for**

    * vault administration
    * rotating manager authority
    * updating other role sets
    * creating governed changes
  </Tab>

  <Tab title="Curator">
    The **curator** is responsible for the vault’s supported asset and configuration surface. This role is generally used for token entry management and other configuration that defines what the vault is allowed to support.

    In practice, the curator shapes the vault’s structure, while the manager oversees broader vault operation.

    ```ts theme={null}
    // Typical curator-controlled responsibilities
    // - manage token entry configuration
    // - define supported assets
    // - shape the vault’s configuration surface
    ```

    **Basic role management flow**

    1. Fetch the current vault state
    2. Read `vault.roles.curator`
    3. Update the curator public key list
    4. Submit the corresponding manager-authorized update
    5. Refetch the vault and verify the updated curator set

    **Use this role for**

    * token entry configuration
    * supported asset management
    * configuration ownership separate from execution
  </Tab>

  <Tab title="Allocator">
    The **allocator** is the strategy execution role. Allocators are responsible for deploying capital through supported integrations and executing strategy actions within the vault’s configured policy boundaries.

    This role is narrower than the manager role. It is intended for execution, not full vault administration.

    ```ts theme={null}
    // Typical allocator-controlled responsibilities
    // - deploy capital into supported integrations
    // - execute policy-constrained strategy actions
    // - operate execution bots or strategy operators
    ```

    **Basic role management flow**

    1. Fetch the current vault state
    2. Read `vault.roles.allocator`
    3. Add, remove, or rotate the allocator signer
    4. Submit the corresponding manager-authorized update
    5. Refetch the vault and verify the updated allocator set

    **Use this role for**

    * execution bots
    * delegated strategy operators
    * separating execution authority from admin authority
  </Tab>

  <Tab title="Sentinel">
    The **sentinel** is the emergency control role. Sentinels can set or clear vault status flags that block categories of operations, such as withdrawals, manager invoke flows, or user invoke flows.

    This role acts as an emergency brake for operational protection.

    ```ts theme={null}
    // Typical sentinel-controlled responsibilities
    // - set emergency status flags
    // - clear emergency status flags
    // - block withdrawals or invoke flows when needed
    ```

    **Basic role management flow**

    1. Fetch the current vault state
    2. Read `vault.roles.sentinel`
    3. Update the sentinel public key list
    4. Submit the corresponding manager-authorized update
    5. Refetch the vault and verify the updated sentinel set

    **Use this role for**

    * emergency response
    * operational safety controls
    * restricting sensitive emergency authority to a trusted set
  </Tab>
</Tabs>
