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

# PT / YT Tokenization

> Splitting a yield-bearing position into principal and yield legs.

Kimia's `split-engine` takes any vault share and breaks it into two transferable SPL
tokens:

* **PT, Principal Token.** Redeems 1:1 for the underlying vault share at maturity.
* **YT, Yield Token.** Captures all yield accrued between mint and maturity.

The split is conservation-preserving: `PT_supply = YT_supply = escrowed_vault_shares`.

## Why split?

<CardGroup cols={2}>
  <Card title="Fixed income" icon="lock">
    Buying PT at a discount locks the yield-to-maturity as a fixed APY. You know
    exactly what you'll get back.
  </Card>

  <Card title="Leveraged yield" icon="arrow-trend-up">
    Buying YT is pure exposure to funding. A small principal buys a claim on all
    future yield until maturity.
  </Card>

  <Card title="LP routing" icon="arrow-right-arrow-left">
    PT/underlying pools (yield-amm) make the market: price PT = discounted future
    value of 1 share.
  </Card>

  <Card title="Composable receipts" icon="cubes">
    PT and YT are normal SPL tokens. They can be lent, used as collateral, or
    routed through kUSD.
  </Card>
</CardGroup>

## MasterChef-style yield accounting

The engine tracks yield per YT held using the classic `reward_per_share` pattern:

```
global:
  reward_per_share   // cumulative yield per YT, 9-decimal fixed point

per user:
  yt_balance         // YT owned
  reward_debt        // reward_per_share × yt_balance at last interaction

pending = yt_balance × reward_per_share - reward_debt
```

When a user joins or leaves:

1. The engine auto-claims `pending` into the user's account.
2. `yt_balance` is updated.
3. `reward_debt = yt_balance × reward_per_share` is reset.

This guarantees every YT holder only earns yield that accrued **while they held**.

## Syncing with the vault

`reward_per_share` is driven by the vault's share price. Anyone can call
`update_rewards` (a permissionless crank), which:

1. Reads `vault.share_price()`
2. Computes `delta = share_price - last_vault_share_price`
3. Increments `reward_per_share += delta` (scaled by supply)
4. Updates `last_vault_share_price`

Because the vault's share price only moves on `claim_funding`, the crank cadence
matches funding cadence (hourly).

## Maturity and redemption

A split-engine market is parameterized by a `maturity` unix timestamp.

* **Before maturity:** PT trades on the yield-AMM at a discount to 1:1. Holders
  can `claim_yield` (if they also hold YT).
* **At maturity:** `redeem_pt` becomes available, PT burns 1:1 for vault shares.
* **Early exit:** Burn matched PT+YT pairs (via `early_exit`) to recover vault
  shares minus a 0.3% protocol fee, any time.

## Worked example

A user with 1,000 vault shares enters a 30-day market:

```
initial:          1,000 vault shares
split:            +1,000 PT, +1,000 YT in the user's wallet
                  1,000 vault shares escrowed
sell YT:          −1,000 YT → 25 USDC (yield-AMM discount)
hold PT:          1,000 PT
at maturity:      redeem_pt → 1,000 vault shares returned
```

The 25 USDC is the **prepaid yield**, fixed and known at sale time.

## Read next

<CardGroup cols={2}>
  <Card title="Yield-AMM" icon="arrow-right-arrow-left" href="/concepts/yield-amm">
    The yield-space invariant that prices PT vs underlying.
  </Card>

  <Card title="Fixed-rate intents" icon="route" href="/concepts/fixed-rate-intents">
    Putting the pieces together into one session.
  </Card>

  <Card title="split-engine reference" icon="book" href="/programs/split-engine">
    Instructions, accounts, errors.
  </Card>
</CardGroup>