Intents

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.

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.

How Intents Work

Manager creates an intent

A manager calls one of the edit*Tx methods (e.g., editFeesTx, addOrEditTokenTx).

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

Intent waits (if delayed)

If there is a modification delay or scheduled activation, the intent is created on-chain and waits.

Execution or cancellation

After the activation timestamp, any keeper can call executeVaultIntentTx. After the expiration timestamp, any keeper can call cancelVaultIntentTx.

Intent Structure

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

EditCreatorSettings

{ creator: string }

EditManagerSettings

{
  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;
}

EditFeeSettings

{
  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;
}

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 for full documentation.

{
  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
}

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 for the full list of conditions.

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

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.

{
  enabled: boolean;
  lp_threshold_bps: number;
  modification_delay: number;
}

EditMetadataSettings

{
  symbol: string;
  name: string;
  uri: string;
  modification_delay: number;
}

EditDepositsSettings

Controls whether users can deposit into the vault. Always takes effect immediately (no modification delay).

{ enabled: boolean }

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.

{
  enabled: boolean;
  modification_delay: number;  // seconds — time-lock for future changes to this setting
}

EditCustomRebalanceSettings

Controls whether custom rebalances (type VaultCustom) are allowed.

{
  enabled: boolean;
  modification_delay: number;  // seconds — time-lock for future changes to this setting
}

EditAddTokenSettings / EditUpdateWeightsSettings / EditMakeDirectSwapSettings

{ modification_delay: number }

AddOrEditTokenInput

{
  token_mint: string;
  active: boolean;
  min_oracles_thresh: number;
  min_conf_bps: number;
  conf_thresh_bps: number;
  conf_multiplier: number;
  oracles: OracleInput[];
}

UpdateWeightsInput

{
  token_weights: {
    mint: string;
    weight_bps: number;
  }[];
  token_mints_hash?: number[];
}

MakeDirectSwapInput

{
  from_token_mint: string;
  to_token_mint: string;
  amount_from: number;
  amount_to: number;
}

TaskContext

Every edit method takes a TaskContext object:

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:

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:

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

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

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):

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

Fetching Intents

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:

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.

Getting Started

Core Concepts

Guides

How Intents Work

Intent Structure

Task Types

Settings Types

TaskContext

Creating Intents

Executing Intents

Cancelling Intents

Fetching Intents

Bounty System

​How Intents Work

​Intent Structure

​Task Types

​Settings Types

​TaskContext

​Creating Intents

​Executing Intents

​Cancelling Intents

​Fetching Intents

​Bounty System

How Intents Work

Intent Structure

Task Types

Settings Types

TaskContext

Creating Intents

Executing Intents

Cancelling Intents

Fetching Intents

Bounty System