Skip to main content

Vault capital is deployed through a policy model where every strategy action must match an approved onchain policy before it can proceed. This is one of the core design principles of Exponent Strategy Vaults. At a high level, vault strategy execution works like this:
  1. the vault has defined roles
  2. the vault adds support for one or more policies
  3. the authorized Allocator role builds a supported strategy action
  4. the action is wrapped into a vault sync transaction
  5. the transaction executes only if it matches an approved policy

What Policies Do

Policies define what the vault is allowed to do. In practice, they gate:
  • which programs the vault can interact with
  • which instructions are allowed
  • which assets can be used
  • which accounts or protocol contexts are valid for execution
If a strategy action does not match an installed policy, the transaction is rejected.

Strategy Execution Flow

A typical strategy interaction follows this pattern:
1

Choose the protocol

Select the protocol interface the vault strategy will interact with, such as Exponent Core, Exponent CLMM, Exponent Order Book, Kamino Lend, or Titan.
2

Add the corresponding policy

The vault must already authorize that action type onchain before the strategy can execute it.
3

Build the action descriptor

Use the protocol-specific action builder to define the strategy action you want the vault to perform.
4

Wrap it in a vault sync transaction

This resolves the required accounts and produces the executable instruction set for the vault.
5

Execute through the vault

Submit the transaction through the vault’s policy-gated control model.

Supported Strategy Interfaces

Exponent Strategy Vaults currently support multiple strategy interfaces.

Exponent Core

Use Exponent Core when the vault needs to interact directly with yield stripping mechanics. Typical uses include:
  • stripping base assets into PT and YT
  • merging PT and YT back into base
  • building fixed-rate or variable-yield strategies directly on top of Exponent’s issuance layer

Exponent CLMM

Use the Exponent CLMM when the vault strategy needs to provide concentrated liquidity or direct PT / YT trading through the CLMM venue. Typical uses include:
  • providing PT / SY concentrated liquidity
  • buying or selling PT
  • buying or selling YT through the CLMM routing path
  • collecting fee and emission flows tied to LP positions

Exponent Order Book

Use the Exponent Order Book when the strategy needs precise rate execution or passive quoting through offers. Typical uses include:
  • posting offers
  • taking liquidity
  • removing offers
  • withdrawing settled funds

Kamino Lend

Use Kamino Lend when the strategy needs to allocate capital into lending, borrowing, or loop-based position management on Kamino. Typical uses include:
  • deposit
  • withdraw
  • borrow
  • repay

Titan

Use Titan when the strategy needs swap routing through the Titan DEX aggregator. Typical uses include:
  • spot swaps required to rebalance a vault strategy
  • asset routing between strategy legs
  • handling execution paths outside native Exponent venues

Policy Builders

Each supported integration typically has a policy builder that helps define the allowed action surface before execution. These builders are used to create the policy configuration that the vault installs onchain before the strategy is allowed to run. As a result, there are two distinct steps:
  1. define what is allowed
  2. execute an action within that allowed set
Installing an instruction builder alone is not enough. The corresponding policy must also exist.

Before and After AUM

Policy management matters around the vault’s AUM lifecycle. Before the vault holds depositor funds, policy setup is more flexible and should be finalized as much as possible. Once the vault has AUM, changes to the strategy surface become more sensitive and may require governed change flows depending on the setting being modified. Therefore, strategy and policy design should be treated as part of vault setup, not as something to postpone until after launch.

To Summarize

  • Policies define what the vault may do
  • Action builders define what the strategy wants to do
  • Vault sync transactions turn the Allocator’s actions into executable transactions

Where to Go Next