Skip to main content
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

1

Manager creates an intent

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

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

Intent waits (if delayed)

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

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

TaskTypeStringDescription
EditCreator (1)edit_creatorTransfer vault creator role
EditManagerSettings (2)edit_manager_settingsEdit managers, weights, authorities
EditFeeSettings (3)edit_fee_settingsUpdate fee structure
EditScheduleSettings (4)edit_schedule_settingsConfigure cycle timing
EditAutomationSettings (5)edit_automation_settingsConfigure rebalance automation
EditLpSettings (6)edit_lp_settingsConfigure LP settings
EditMetadataSettings (7)edit_metadata_settingsUpdate name, symbol, URI
EditDepositsSettings (8)edit_deposits_settingsEnable/disable deposits
EditForceRebalanceSettings (9)edit_force_rebalance_settingsEnable/disable force rebalance
EditCustomRebalanceSettings (10)edit_custom_rebalance_settingsEnable/disable custom rebalance
EditAddTokenDelay (11)edit_add_token_delaySet time-lock for adding tokens
EditUpdateWeightsDelay (12)edit_update_weights_delaySet time-lock for weight updates
EditMakeDirectSwapDelay (13)edit_make_direct_swap_delaySet time-lock for direct swaps
AddToken (14)add_tokenAdd new token or edit oracle config
UpdateWeights (15)update_weightsChange token target weights
MakeDirectSwap (16)make_direct_swapExecute a direct swap within the vault

​
Settings Types

{ creator: string }

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

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

{
  symbol: string;
  name: string;
  uri: string;
  modification_delay: number;
}
Controls whether users can deposit into the vault. Always takes effect immediately (no modification delay).
{ enabled: boolean }
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
}
Controls whether custom rebalances (type VaultCustom) are allowed.
{
  enabled: boolean;
  modification_delay: number;  // seconds — time-lock for future changes to this setting
}

{ modification_delay: number }

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

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

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