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

# Fixed-Rate Intents

> A single session that turns USDC into a guaranteed fixed APY.

<style>
  {`
      .katex-display {
        overflow-x: auto;
        overflow-y: hidden;
        scrollbar-width: none;
        -ms-overflow-style: none;
      }
      .katex-display::-webkit-scrollbar {
        display: none;
        height: 0;
        width: 0;
      }
      `}
</style>

An **intent** in Kimia is a small state machine that records a user's goal
"deposit 1,000 USDC and lock at least 25% APY for 30 days", and verifies, after
the fact, that the underlying multi-step flow achieved it.

The intent-router does not execute the trades. It only watches and attests. This
is deliberate: transaction size limits on Solana make it hard to do the whole
flow atomically, so Kimia splits it across three transactions and uses the
session account to guarantee the end-to-end invariant.

## The session state machine

<img
  src="https://mintcdn.com/kimia/eZh9Dx07_tQazD2y/images/intent-session-state-machine.png?fit=max&auto=format&n=eZh9Dx07_tQazD2y&q=85&s=f49b0e4ef152ea5b9804002943fdff4f"
  alt="Intent session flow: Create Session leads through verification steps (vault share delivery, PT and YT minted, swap verified) to Session Completed when achieved rate meets target rate."
  style={{
maxWidth: '100%',
height: 'auto',
display: 'block',
margin: '24px auto',
borderRadius: '1rem',
}}
  width="1061"
  height="540"
  data-path="images/intent-session-state-machine.png"
/>

At any point, `close_session` returns rent and aborts the flow.

## What gets verified

Each `record_step*` instruction takes the pre/post balances of the relevant token
accounts and asserts:

* **Step 1:** The user received at least the vault shares the vault promised.
* **Step 2:** PT and YT were minted 1:1 against the escrowed shares.
* **Step 3:** The AMM swap actually sold PT for underlying, and the implied
  annualized rate clears the user's target.

The step-3 rate calculation is:

$$
\text{discount} = \text{pt\_sold} - \text{underlying\_received}
$$

$$
\text{achieved\_rate} = \frac{\text{discount} \times \text{ONE} \times \text{SECONDS\_PER\_YEAR}}{\text{underlying\_received} \times \text{duration}}
$$

The router then requires $\text{achieved\_rate} \geq \text{target\_rate}$, reverting otherwise.

If the AMM moved against the user between their first deposit and the swap, the
router will refuse to complete the session, the user keeps their tokens and can
choose to unwind manually.

## Why a separate program?

* **Client UX.** The frontend can walk the user through three wallet prompts
  without needing to batch everything into one compute-limited tx.
* **Safety.** A naïve "send three txs in order" flow gives no on-chain proof that
  all three succeeded. The session account is that proof, any integrator can
  read it and know the user's outcome.
* **Auditability.** Every intent emits `IntentCreated`, `IntentStep1Recorded`,
  `IntentStep2Recorded`, and `IntentFulfilled` events with the achieved rate.

## Read next

<CardGroup cols={2}>
  <Card title="intent-router reference" icon="book" href="/programs/intent-router">
    Accounts, instructions, rate formula.
  </Card>

  <Card title="Lock a fixed rate" icon="lock" href="/guides/lock-fixed-rate">
    End-to-end walkthrough with code.
  </Card>
</CardGroup>