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

# Configure fixed-rate allocations

> Add and manage allocations into fixed-rate reserves — UI, SDK, and CLI walkthroughs with FR-specific parameter choices

This guide is the focused walkthrough for adding a vault allocation into a fixed-rate reserve. The general allocation primitives (weights, caps, sync, the Standard vs. Conditional choice) live in [Concepts → Allocations](/curators/vaults/concepts/allocations) and [Configure allocations](/curators/vaults/guides/configure-allocations); the FR-specific application of those primitives is in [Fixed Rates → Allocations](/curators/vaults/fixed-rates/allocations). This page assumes you've read those and are ready to act.

## Before you start

You'll need:

* An existing vault for the deposit token of the FR reserve (e.g. a USDC vault to allocate into a `USDC 5.5% 3M` reserve).
* The address of the fixed-rate reserve. Find it via the Manage UI's reserve picker, or via [Markets → Fixed Rates](/curators/markets/fixed-rates) for the market manager who created it.
* A decision on Standard vs. Conditional (see below).
* For SDK or CLI: your admin keypair file path.

## Decide on Standard vs. Conditional

Both work for FR reserves. The choice is about capital efficiency vs. visibility, not technical compatibility.

| Pick                         | When                                                                                                                                                             |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Conditional**              | Default for most FR exposure. Capital stays in floating reserves earning variable yield until borrow demand triggers an atomic deployment into the FR reserve.   |
| **Standard**                 | When you want capital visibly committed and immediately available for direct borrows — typically for seeding a new FR reserve or anchoring a strategic position. |
| **Both on the same reserve** | A Standard base layer of visible liquidity plus Conditional capacity behind it.                                                                                  |

For the full reasoning, see [Fixed Rates → Allocations → Why Conditional is the default for FR](/curators/vaults/fixed-rates/allocations#why-conditional-is-the-default-for-fr).

## Parameter cheat sheet

Four parameter choices change for FR reserves vs. floating ones:

| Parameter           | Conditional                                                                                     | Standard                                                                                                                  |
| ------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `allocation-type`   | `Conditional`                                                                                   | `Standard`                                                                                                                |
| `allocation-weight` | `0` (weight is ignored)                                                                         | Relative integer like any other Standard allocation                                                                       |
| `allocation-cap`    | The **binding limit** — maximum the vault will deploy if matched                                | Hard ceiling on top of weight                                                                                             |
| `priority`          | `0` (default) — only set if you want this Conditional fill to draw from higher-priority sources | `0` (default) — raise to protect this Standard allocation from being drawn down by Conditional fills on other FR reserves |

For the priority rule and worked examples, see [Concepts → Allocations → Priority](/curators/vaults/concepts/allocations#priority).

## Walkthrough

<Tabs>
  <Tab title="UI">
    <Steps>
      <Step title="Open the Allocations tab">
        Navigate to your vault on `manage.kamino.com` and open the **Allocations** tab.
      </Step>

      <Step title="Click Add Reserve">
        Opens the allocation configuration form.
      </Step>

      <Step title="Select the market">
        Pick the market that hosts the fixed-rate reserve (e.g. Main Market).
      </Step>

      <Step title="Select the fixed-rate reserve">
        The reserve picker lists floating and fixed-rate reserves side by side. Fixed-rate reserves are tagged with their rate, term, and reserve type — for example `USDC 5.5% 3M`. Pick the cell of the rate grid you're targeting.
      </Step>

      <Step title="Toggle Conditional Allocation">
        On for Conditional (capital stays in floating until matched). Off for Standard (capital deploys immediately).
      </Step>

      <Step title="Set the cap">
        The maximum tokens the vault is willing to deploy into this reserve. For Conditional, this is the binding limit. For Standard, a hard ceiling.
      </Step>

      <Step title="Set weight (Standard only)">
        Skip for Conditional — the field is ignored. For Standard, set the relative weight against your other Standard allocations.
      </Step>

      <Step title="Set priority">
        Default `0`. Only adjust if you're using priority to protect specific source reserves (see Parameter cheat sheet above).
      </Step>

      <Step title="Submit">
        Sign with your admin wallet, or generate a Squads proposal if the vault is multisig-controlled.
      </Step>
    </Steps>
  </Tab>

  <Tab title="SDK">
    ```typescript theme={null}
    import {
      createSolanaRpc,
      createSolanaRpcSubscriptions,
      address,
      pipe,
      createTransactionMessage,
      setTransactionMessageFeePayerSigner,
      setTransactionMessageLifetimeUsingBlockhash,
      appendTransactionMessageInstructions,
      signTransactionMessageWithSigners,
      sendAndConfirmTransactionFactory,
    } from '@solana/kit';
    import {
      KaminoManager,
      KaminoVault,
      Reserve,
      ReserveAllocationConfig,
      ReserveType,
      getMedianSlotDurationInMsFromLastEpochs,
    } from '@kamino-finance/klend-sdk';
    import { parseKeypairFile } from '@kamino-finance/klend-sdk/dist/utils/signer.js';
    import { Decimal } from 'decimal.js';

    const adminSigner = await parseKeypairFile('/path/to/your/keypair.json');
    const rpc = createSolanaRpc('https://api.mainnet-beta.solana.com');
    const rpcSubscriptions = createSolanaRpcSubscriptions('wss://api.mainnet-beta.solana.com');
    const slotDuration = await getMedianSlotDurationInMsFromLastEpochs();
    const kaminoManager = new KaminoManager(rpc, slotDuration);

    const vault = new KaminoVault(rpc, address('<VAULT_ADDRESS>'));
    const fixedRateReserveAddress = address('<FIXED_RATE_RESERVE_ADDRESS>');

    const reserveState = await Reserve.fetch(rpc, fixedRateReserveAddress);
    const reserveWithAddress = { address: fixedRateReserveAddress, state: reserveState! };

    // Conditional — default for FR
    const conditionalConfig = new ReserveAllocationConfig(
      reserveWithAddress,
      0,                              // weight ignored for Conditional
      new Decimal('10000000'),        // cap — binding limit (10M tokens)
      new ReserveType.Conditional(),
      0,                              // priority
    );

    // OR — Standard, when you want visible committed liquidity
    const standardConfig = new ReserveAllocationConfig(
      reserveWithAddress,
      100,                            // weight relative to other Standard allocations
      new Decimal('5000000'),         // cap — hard ceiling on top of weight
      new ReserveType.Standard(),
      0,                              // priority
    );

    const { updateReserveAllocationIx } =
      await kaminoManager.updateVaultReserveAllocationIxs(vault, conditionalConfig, adminSigner);

    const { value: blockhash } = await rpc.getLatestBlockhash({ commitment: 'finalized' }).send();
    const signed = await signTransactionMessageWithSigners(
      pipe(
        createTransactionMessage({ version: 0 }),
        tx => setTransactionMessageFeePayerSigner(adminSigner, tx),
        tx => setTransactionMessageLifetimeUsingBlockhash(blockhash, tx),
        tx => appendTransactionMessageInstructions([updateReserveAllocationIx], tx),
      ),
    );
    await sendAndConfirmTransactionFactory({ rpc, rpcSubscriptions })(signed, {
      commitment: 'confirmed',
      skipPreflight: true,
    });
    ```

    The same `updateVaultReserveAllocationIxs` method handles both **adding a new reserve** and **updating an existing one** — the SDK detects the difference. To **mix Standard + Conditional on the same reserve**, call the method twice with the two configs.
  </Tab>

  <Tab title="CLI">
    <Note>
      Complete the [CLI installation guide](/build/cli/installation-setup) first. Commands require `.env` with `ADMIN` and `RPC` configured.
    </Note>

    **Conditional allocation** (recommended default for FR):

    ```bash theme={null}
    yarn kamino-manager update-vault-reserve-allocation \
      --vault <VAULT_ADDRESS> \
      --reserve <FIXED_RATE_RESERVE_ADDRESS> \
      --allocation-weight 0 \
      --allocation-cap 10000000 \
      --allocation-type Conditional \
      --priority 0 \
      --mode simulate
    ```

    **Standard allocation** (for visible committed liquidity):

    ```bash theme={null}
    yarn kamino-manager update-vault-reserve-allocation \
      --vault <VAULT_ADDRESS> \
      --reserve <FIXED_RATE_RESERVE_ADDRESS> \
      --allocation-weight 100 \
      --allocation-cap 5000000 \
      --allocation-type Standard \
      --priority 0 \
      --mode simulate
    ```

    Always run `--mode simulate` first to inspect the resulting state. Then re-run with `--mode execute`, or `--mode multisig --multisig <MULTISIG_PUBKEY>` to emit a Base58 payload for [Squads](https://squads.so).

    **Mixing Standard + Conditional on the same reserve**: run the command twice with the two `--allocation-type` values. The vault will hold both allocations against the same reserve.
  </Tab>
</Tabs>

## Verify

After submission lands:

* **UI.** The new allocation appears in the Allocations tab with the reserve name, type tag (Standard / Conditional), cap, weight, and priority.
* **SDK.** `vault.getVaultAllocations()` returns a map that includes the new reserve. See [Configure allocations → Read current allocations](/curators/vaults/guides/configure-allocations#read-current-allocations).
* **API.** `GET /kvaults/vaults/{pubkey}` includes the allocation strategy. See [Allocation data](/curators/data/allocation-data).

A Conditional allocation won't show capital deployed into the FR reserve until borrow demand triggers a fill — that's expected. The vault's actual position lives in your Standard floating allocations until then.

## After it lands

* **Watch for fills.** If the FR reserve attracts demand, your Conditional cap may be drawn down to satisfy it. The fill is atomic — see [Lifecycle → The fill](/curators/vaults/fixed-rates/lifecycle#the-fill).
* **Adjust caps responsively.** Raise to expose more capital, lower to commit less. Conditional caps can be dropped to `0` to disable the signal entirely.
* **Plan exits ahead of maturity.** Once a Conditional fill lands and is committed to a borrow, exits go through the [withdrawal queue](/curators/vaults/concepts/liquidity-and-withdrawals#the-withdrawal-queue). Queue early if you want predictable exit timing — see [Lifecycle → Exiting via the withdrawal queue](/curators/vaults/fixed-rates/lifecycle#exiting-via-the-withdrawal-queue).

## What's next

<CardGroup cols={2}>
  <Card title="Fixed Rates → Allocations" icon="chart-pie" href="/curators/vaults/fixed-rates/allocations">
    The FR-specific application of Standard vs. Conditional with priority worked examples.
  </Card>

  <Card title="Fixed Rates → Lifecycle" icon="timeline" href="/curators/vaults/fixed-rates/lifecycle">
    What your capital experiences from fill through term, rollover, and queued exits.
  </Card>

  <Card title="Fixed Rates → Strategy" icon="chess-knight" href="/curators/vaults/fixed-rates/strategy">
    Postures, sizing, monitoring, and a worked \$100M vault example.
  </Card>

  <Card title="Configure allocations" icon="sliders" href="/curators/vaults/guides/configure-allocations">
    The general allocation workflow (floating reserves and the unallocated buffer).
  </Card>
</CardGroup>