> For the complete documentation index, see [llms.txt](https://docs.pye.fi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.pye.fi/how-pye-works.md).
# How Pye Works
## Yield Splitter
The Yield Splitter separates staking capital from it's principal. When a staker deposits, the stake is locked up for a defined duration and the position is split into two tokens:
* A **Principal Token (PT):** representing the underlying SOL, redeemable 1:1 at maturity
* A **Reward Token (RT):** representing all staking rewards generated by that position until maturity
These two tokens are SPLs that can be held and redeemed at maturity, traded, collateralized in DeFi, or sold independently.
{% hint style="info" %}
**How are PTs and RTs on Pye different from Pendle?**
Unlike price discovery protocols like Pendle, PTs on Pye are 1:1 redeemable for SOL and do not accrue fixed rewards.
{% endhint %}
#### Principal Tokens (PT)
PTs represent the "principal only" side of a staked position. At maturity, every PT redeems 1:1 for SOL regardless of which validator it originated from.
**Minting PTs**
PTs are minted 1:1 to the number of tokens deposited:
$$N\_{PT} = P \cdot 1$$
Where $$N\_{PT}$$ is the number of principal tokens to mint and `P` is the principal amount in SOL.
**Redeeming PTs**
At maturity, PT token holders can redeem their tokens for the underlying principal pro rata. To calculate the repayment we use:
$$
RedeemPrincipal(p)= \frac{p}{N\_{PT}} \cdot P
$$
where:
* $$p$$ is the number of PT the holder redeems,
* $$P$$ is the total principal backing the pool,
* $$N\_{PT}$$ is the total supply of PTs outstanding.
***
#### Reward Tokens (RT)
RTs represent the rewards-only side of a staked position, the right to receive all staking rewards generated until maturity, including inflation, MEV, and priority fees.
RT pricing is based on SOL accrued to date, projected forward on an epoch-by-epoch basis from deposit to maturity. Inflation is the most stable component and forms the baseline. MEV and priority fees are more volatile and can increase an RT's value significantly depending on network conditions and how much a validator shares back to stakers.
**Minting RTs**
To create a functional rewards curve, RTs need to reflect both how much capital is staked and how long it will generate rewards. The protocol achieves this through a continuous, time-weighted minting formula. A single RT is not a fixed unit of SOL. It is a pro-rata claim on the remaining rewards of a specific lockup duration for a validator. Two RTs from different lockups, or even the same lockup at different deposit times, represent different economic exposures. The time-weighted, minting ensures that every RT holder's claim is proportional to the capital and duration they actually committed.
**The Formula**
When you deposit into a time-based lockup, the program calculates your RT allocation based on the fraction of the lockup’s total duration that remains:
$$\text{RTs} = \text{SOL Deposited} \times \frac{\text{Time Remaining}}{\text{Total Lockup Duration}}$$
At issuance (day 1), you receive 1 RT per SOL: the maximum allocation. As the lockup progresses toward maturity, new depositors receive proportionally fewer RTs, because they are entitled to fewer remaining epochs of rewards. This creates a natural pricing mechanism: **earlier commitment = larger rewards claim**.
We can formalize the initial value (backing) to be:
$$
S\_0=P
$$
where:
* $$s\_0$$ is the initial deposit
* $$P$$ is the principal deposit amount in SOL.
At the end of each epoch $$t$$, the stake account grows by the effective staking reward rate $$r\_t$$. The value after $$t$$ epochs is:
$$
S\_t=S\_{t−1}⋅(1+r\_t), ;;;;;;; t=1,2,…,T
$$
After $$T$$ epochs (maturity), the stake account balance is:
$$
S\_T = S\_0 \cdot \prod\_{t=1}^{T} (1 + r\_t)
$$
where:
* $$S\_0=P$$ = initial deposit
* $$r\_t$$ already accounts for validator commission, inflation rate, MEV, etc.
The rewards is the difference between the maturity value and the initial deposit:
$$
R = S\_T - P
$$
Therefore:
* PT holders redeem their tokens for exactly $$P$$ units of SOL, independent of reward.
* RT holders redeem their tokens for the residual rewards $$R$$, distributed pro rata to the number of RT tokens they hold.
**Why Time-Weighting Matters**
Consider a 12-month lockup. A depositor on day 1 is entitled to a full year of staking rewards. A depositor at the 9-month mark is only entitled to the final 3 months. Minting the same number of RTs to both would dilute the early depositor's claim. The time-weighted formula prevents this, each RT always represents an equal share of the lockup's remaining production.
**Example: Same deposit amount, different lockup durations (deposited at issuance)**
| Deposit Timing | Time Remaining | Fraction | PTs Minted | RTs Minted |
| -------------- | -------------- | -------- | ---------- | ---------- |
| At issuance | 12 months | 100% | 10 PT | 10 RT |
| 3 months in | 9 months | 75% | 10 PT | 7.5 RT |
| 6 months in | 6 months | 50% | 10 PT | 5 RT |
| 9 months in | 3 months | 25% | 10 PT | 2.5 RT |
**Example: RT value at maturity by lockup duration (assuming \~7% APY)**
| SOL Deposited | Lockup Duration | PTs Minted | RTs Minted | RT Value at Maturity |
| ------------- | --------------- | ---------- | ---------- | -------------------- |
| 1 SOL | 3 months | 1 PT | 1 RT | 0.018 SOL |
| 10 SOL | 6 months | 10 PT | 10 RT | 0.035 SOL |
| 10 SOL | 12 months | 10 PT | 10 RT | 0.070 SOL |
| 100 SOL | 12 months | 100 PT | 100 RT | 0.070 SOL |
*Illustrative example assuming \~7% APY. Actual value depends on validator performance and commissions.*
{% hint style="info" %}
When depositing at issuance, the lockup duration doesn't change the RT count, you always get 1 RT per SOL. What changes is what each RT is worth. An RT on a 12-month lockup represents a claim on 12 months of validator production, while an RT on a 3-month lockup represents only 3 months.
{% endhint %}
***
## Orderbook
The orderbook allows for markets to be created around trading stake accounts and rewards. Principal Tokens and Reward Tokens can be traded, matched and settled on Pye's on-chain orderbook. There are two types of orders supported:
* **Limit orders:** orders placed against a specific validator market at a target discount rate. Fills when a matching seller appears.
* **Market orders:** fills immediately at the best available rate in a given market.
#### Fixed Maturities
All markets on the orderbook settle at fixed 3-month maturities aligned to end-of-quarter dates. Shared maturities mean liquidity concentrates rather than fragments across arbitrary timeframes. It also means buyers can set universal orders across every market on the platform simultaneously, a single order that fills against any validator offering a matching discount rate.
#### Trading on the Orderbook
PTs earn no rewards but can be traded at a discount to par because they are future assets being priced today. The reason PTs trade at a discount is that the buyer is purchasing a locked version of SOL.
For buyers, purchasing a PT at a discount is equivalent to locking in a fixed return on SOL. The position is straightforward: buy below par today, redeem at par at maturity.
For buyers, RTs are a way to gain direct exposure to Solana staking rewards without holding the underlying SOL.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.pye.fi/how-pye-works.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.