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

# Intents

> How vault configuration changes work through the intent system.

For SDK-facing workflows, vault configuration changes are performed via the intent system. An intent is an on-chain account that stores a proposed change to a vault's settings. This enables time-locks, scheduled changes, and bounty incentives for keeper execution.

<Note>
  The protocol also includes a direct private-basket settings instruction path, primarily for creator-controlled private setup flows. This path is not exposed in the SDK.
</Note>

## How Intents Work

<Steps>
  <Step title="Manager creates an intent">
    A manager calls one of the `edit*Tx` methods (e.g., `editFeesTx`, `addOrEditTokenTx`).
  </Step>

  <Step title="SDK checks modification delay">
    If modification delay is 0 AND no scheduled activation time, the intent is created and executed in the same transaction (immediate).
  </Step>

  <Step title="Intent waits (if delayed)">
    If there is a modification delay or scheduled activation, the intent is created on-chain and waits.
  </Step>

  <Step title="Execution or cancellation">
    After the activation timestamp, any keeper can call `executeVaultIntentTx`. After the expiration timestamp, any keeper can call `cancelVaultIntentTx`.
  </Step>
</Steps>

## Intent Structure

```typescript theme={null}
interface FormattedIntent {
  pubkey: string;
  manager: string;
  status: "not_active" | "active" | "reverted" | "completed";
  activation_timestamp: number;
  expiration_timestamp: number;
  vault: string;
  bounty: FormattedBounty;
  task_type: FormattedTaskType;
  task_data: Settings;
}
```

## Task Types

| TaskType                           | String                           | Description                            |
| ---------------------------------- | -------------------------------- | -------------------------------------- |
| `EditCreator` (1)                  | `edit_creator`                   | Transfer vault creator role            |
| `EditManagerSettings` (2)          | `edit_manager_settings`          | Edit managers, weights, authorities    |
| `EditFeeSettings` (3)              | `edit_fee_settings`              | Update fee structure                   |
| `EditScheduleSettings` (4)         | `edit_schedule_settings`         | Configure cycle timing                 |
| `EditAutomationSettings` (5)       | `edit_automation_settings`       | Configure rebalance automation         |
| `EditLpSettings` (6)               | `edit_lp_settings`               | Configure LP settings                  |
| `EditMetadataSettings` (7)         | `edit_metadata_settings`         | Update name, symbol, URI               |
| `EditDepositsSettings` (8)         | `edit_deposits_settings`         | Enable/disable deposits                |
| `EditForceRebalanceSettings` (9)   | `edit_force_rebalance_settings`  | Enable/disable force rebalance         |
| `EditCustomRebalanceSettings` (10) | `edit_custom_rebalance_settings` | Enable/disable custom rebalance        |
| `EditAddTokenDelay` (11)           | `edit_add_token_delay`           | Set time-lock for adding tokens        |
| `EditUpdateWeightsDelay` (12)      | `edit_update_weights_delay`      | Set time-lock for weight updates       |
| `EditMakeDirectSwapDelay` (13)     | `edit_make_direct_swap_delay`    | Set time-lock for direct swaps         |
| `AddToken` (14)                    | `add_token`                      | Add new token or edit oracle config    |
| `UpdateWeights` (15)               | `update_weights`                 | Change token target weights            |
| `MakeDirectSwap` (16)              | `make_direct_swap`               | Execute a direct swap within the vault |

## Settings Types

<AccordionGroup>
  <Accordion title="EditCreatorSettings">
    ```typescript theme={null}
    { creator: string }
    ```
  </Accordion>

  <Accordion title="EditManagerSettings">
    ```typescript theme={null}
    {
      managers: {
        pubkey: string;
        fee_split_weight_bps: number;
        authorities: {
          managers: boolean;
          fees: boolean;
          schedule: boolean;
          automation: boolean;
          lp: boolean;
          metadata: boolean;
          deposits: boolean;
          force_rebalance: boolean;
          custom_rebalance: boolean;
          add_token: boolean;
          update_weights: boolean;
          make_direct_swap: boolean;
        };
      }[];
      modification_delay: number;
    }
    ```
  </Accordion>

  <Accordion title="EditFeeSettings">
    ```typescript theme={null}
    {
      creator_deposit_fee_bps: number;
      creator_withdraw_fee_bps: number;
      creator_management_fee_bps: number;
      creator_performance_fee_bps: number;
      managers_deposit_fee_bps: number;
      managers_withdraw_fee_bps: number;
      managers_management_fee_bps: number;
      managers_performance_fee_bps: number;
      vault_deposit_fee_bps: number;
      vault_withdraw_fee_bps: number;
      modification_delay: number;
    }
    ```
  </Accordion>

  <Accordion title="EditScheduleSettings">
    Configures repeating time cycles that control when deposits, automated rebalancing, and management actions are allowed. The current position within the cycle is computed as `(current_time - cycle_start_time) % cycle_duration`. An action is allowed when the cycle position falls between its `start` and `end` offsets. If `cycle_duration` is 0, everything is always allowed. See [Schedule & Cycles](/concepts/vaults#schedule--cycles) for full documentation.

    ```typescript theme={null}
    {
      cycle_start_time: number;     // unix timestamp marking the first cycle's start
      cycle_duration: number;       // length of each cycle in seconds (0 = no restriction)
      deposits_start: number;       // offset (seconds) from cycle start when deposits open
      deposits_end: number;         // offset (seconds) from cycle start when deposits close
      automation_start: number;     // offset (seconds) from cycle start when automated rebalancing opens
      automation_end: number;       // offset (seconds) from cycle start when automated rebalancing closes
      management_start: number;     // offset (seconds) from cycle start when management actions open
      management_end: number;       // offset (seconds) from cycle start when management actions close
      modification_delay: number;   // seconds — time-lock for future schedule changes
    }
    ```
  </Accordion>

  <Accordion title="EditAutomationSettings">
    Configures automated keeper-initiated rebalancing. When `enabled`, keepers can trigger rebalances when the vault's token weights drift beyond the specified thresholds. See [Rebalancing — Vault Rebalance](/concepts/rebalancing#vault-rebalance-keeper-initiated) for the full list of conditions.

    ```typescript theme={null}
    {
      enabled: boolean;                                     // whether automated rebalancing is allowed
      rebalance_slippage_threshold_bps: number;             // max overall TVL slippage allowed during the rebalance auction (bps)
      per_trade_rebalance_slippage_threshold_bps: number;   // max slippage allowed per individual flash swap trade (bps)
      rebalance_activation_threshold_abs_bps: number;       // a token must deviate by at least this % of total TVL to trigger (e.g., 500 = 5%)
      rebalance_activation_threshold_rel_bps: number;       // a token must deviate by at least this % relative to its own target value (e.g., 1000 = 10%)
      rebalance_activation_cooldown: number;                // minimum seconds between automated rebalances
      modification_delay: number;                           // seconds — time-lock for future automation changes
    }
    ```

    Both `rebalance_activation_threshold_abs_bps` AND `rebalance_activation_threshold_rel_bps` must be exceeded by at least one token for a rebalance to be triggered — they are not independent conditions.
  </Accordion>

  <Accordion title="EditLpSettings">
    Configures LP (liquidity provider) mode. When `enabled`, the vault can act as a liquidity provider. `lp_threshold_bps` sets the maximum deviation from target weights before LP swaps are restricted.

    ```typescript theme={null}
    {
      enabled: boolean;
      lp_threshold_bps: number;
      modification_delay: number;
    }
    ```
  </Accordion>

  <Accordion title="EditMetadataSettings">
    ```typescript theme={null}
    {
      symbol: string;
      name: string;
      uri: string;
      modification_delay: number;
    }
    ```
  </Accordion>

  <Accordion title="EditDepositsSettings">
    Controls whether users can deposit into the vault. Always takes effect immediately (no modification delay).

    ```typescript theme={null}
    { enabled: boolean }
    ```
  </Accordion>

  <Accordion title="EditForceRebalanceSettings">
    Controls whether authorized managers can trigger rebalances that bypass the normal automation checks (schedule window, cooldown, deviation threshold). When `enabled: false`, this override is disabled and all rebalances must go through normal automation conditions.

    ```typescript theme={null}
    {
      enabled: boolean;
      modification_delay: number;  // seconds — time-lock for future changes to this setting
    }
    ```
  </Accordion>

  <Accordion title="EditCustomRebalanceSettings">
    Controls whether custom rebalances (type `VaultCustom`) are allowed.

    ```typescript theme={null}
    {
      enabled: boolean;
      modification_delay: number;  // seconds — time-lock for future changes to this setting
    }
    ```
  </Accordion>

  <Accordion title="EditAddTokenSettings / EditUpdateWeightsSettings / EditMakeDirectSwapSettings">
    ```typescript theme={null}
    { modification_delay: number }
    ```
  </Accordion>

  <Accordion title="AddOrEditTokenInput">
    ```typescript theme={null}
    {
      token_mint: string;
      active: boolean;
      min_oracles_thresh: number;
      min_conf_bps: number;
      conf_thresh_bps: number;
      conf_multiplier: number;
      oracles: OracleInput[];
    }
    ```
  </Accordion>

  <Accordion title="UpdateWeightsInput">
    ```typescript theme={null}
    {
      token_weights: {
        mint: string;
        weight_bps: number;
      }[];
      token_mints_hash?: number[];
    }
    ```
  </Accordion>

  <Accordion title="MakeDirectSwapInput">
    ```typescript theme={null}
    {
      from_token_mint: string;
      to_token_mint: string;
      amount_from: number;
      amount_to: number;
    }
    ```
  </Accordion>
</AccordionGroup>

## TaskContext

Every edit method takes a `TaskContext` object:

```typescript theme={null}
interface TaskContext {
  vault: string;
  manager: string;
  activation_timestamp?: number;
  expiration_timestamp?: number;
  min_bounty?: number;
  max_bounty?: number;
}
```

## Creating Intents

All edit methods follow the same pattern:

```typescript theme={null}
const tx = await sdk.editFeesTx(
  {
    vault: "<VAULT_PUBKEY>",
    manager: wallet.publicKey.toBase58(),
    activation_timestamp: Math.floor(Date.now() / 1000) + 86400,
    expiration_timestamp: Math.floor(Date.now() / 1000) + 172800,
  },
  {
    creator_deposit_fee_bps: 50,
    creator_withdraw_fee_bps: 50,
    creator_management_fee_bps: 100,   // currently disabled in global config
    creator_performance_fee_bps: 500,  // currently disabled in global config
    managers_deposit_fee_bps: 0,
    managers_withdraw_fee_bps: 0,
    managers_management_fee_bps: 0,    // currently disabled in global config
    managers_performance_fee_bps: 0,   // currently disabled in global config
    vault_deposit_fee_bps: 0,
    vault_withdraw_fee_bps: 0,
    modification_delay: 0,
  }
);

await sdk.signAndSendTxPayloadBatchSequence({
  txPayloadBatchSequence: tx,
  wallet,
});
```

## Executing Intents

After the activation timestamp, a keeper (or any user) can execute the intent:

```typescript theme={null}
const tx = await sdk.executeVaultIntentTx({
  keeper: wallet.publicKey.toBase58(),
  intent: "<INTENT_PUBKEY>",
});
```

For `MakeDirectSwap` intents, use `executeDirectSwapVaultIntentTx` which builds the flash swap:

```typescript theme={null}
const tx = await sdk.executeDirectSwapVaultIntentTx({
  keeper: wallet.publicKey.toBase58(),
  intent: "<INTENT_PUBKEY>",
  jup_swap_ix: jupiterSwapInstruction,
  jup_token_ledger_ix: jupiterTokenLedgerInstruction,
  jup_address_lookup_table_addresses: [...],
});
```

## Cancelling Intents

After the expiration timestamp (or by the manager before activation):

```typescript theme={null}
const tx = await sdk.cancelVaultIntentTx({
  keeper: wallet.publicKey.toBase58(),
  intent: "<INTENT_PUBKEY>",
});
```

## Fetching Intents

```typescript theme={null}
const intent = await sdk.fetchIntent("<INTENT_PUBKEY>");

const map = await sdk.fetchMultipleIntents(["<PUBKEY_1>", "<PUBKEY_2>"]);

const all = await sdk.fetchAllIntents();
const byManager = await sdk.fetchAllIntents({ type: "manager", pubkey: "<MANAGER>" });
const byVault = await sdk.fetchVaultIntents("<VAULT_PUBKEY>");
```

## Bounty System

Each intent carries a bounty that incentivizes keepers to execute it:

```typescript theme={null}
interface FormattedBounty {
  bounty_depositor: string;
  bounty_mint: string;
  bounty_per_price_update_task: FormattedBountySchedule;
  bounty_per_task: FormattedBountySchedule;
  bounty_total: number;
  bounty_left: number;
}

interface FormattedBountySchedule {
  min_bounty: number;
  max_bounty: number;
  min_bounty_until: number;
  max_bounty_after: number;
}
```

The bounty scales between `min_bounty` and `max_bounty` based on how long the intent has been waiting, incentivizing faster execution.