> For the complete documentation index, see [llms.txt](https://docs.suno.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.suno.finance/protocol/yield-and-staking.md).

# Yield and staking

How energy revenue becomes staker yield through the α ramp, vesting, and c-uWatt.

The Reserve earns money two ways: its projects sell electricity, and its liquidity sleeve earns a baseline return. This page covers how that income becomes staking yield.

## Staking

Holders who want the portfolio's return deposit uWatt into the protocol's staking vault (an ERC-4626 vault) and receive **c-uWatt** (Compounding uWatt), a share whose value in uWatt grows as rewards accrue. There is no lockup and no reward claim to manage: yield arrives as an increase in what each share redeems for, and c-uWatt unwinds back into uWatt at the vault's current rate at any time. Since staking costs nothing beyond a transaction, most holders are expected to stake. Unstaked uWatt persists for a different reason: it is the constant-price form, the unit that payments, liquidity pools, and integrations price against, while the share's value moves as yield accrues.

## Where the yield comes from

Every distribution is funded by an actual payment. Electricity sales arrive as stablecoins and land in the Reserve's custody *before* any split is computed, so the reserve value already reflects the money when the decision is made. If revenue does not arrive, there is nothing to distribute: the protocol never mints yield against a projection or an unrealized mark, which is the failure mode of rebase designs.

## The split: the α ramp

Each payment `Y` is divided between stakers and the Reserve's buffer by a fraction `α` that depends on where the collateral ratio `C` stands relative to its target `C*`:

$$
\beta = \max!\left(\frac{C - C\_y}{C^{\*} - C\_y},\ 0\right), \qquad \alpha = \min!\left(\frac{\beta}{C},\ 1\right)
$$

$$
\text{to stakers: } \alpha \cdot Y \qquad\qquad \text{retained: } (1 - \alpha) \cdot Y
$$

`C_y` is the ratio at which yield switches on (par, in the launch configuration). The distributed portion is minted as uWatt directly into the staking vault; the retained portion simply stays in the Reserve, raising `C`.

The ramp's shape encodes the protocol's priorities:

```mermaid
%%{init: {"theme": "base", "themeVariables": {"xyChart": {"backgroundColor": "transparent", "titleColor": "#767676", "xAxisLabelColor": "#767676", "xAxisTitleColor": "#767676", "xAxisTickColor": "#767676", "xAxisLineColor": "#767676", "yAxisLabelColor": "#767676", "yAxisTitleColor": "#767676", "yAxisTickColor": "#767676", "yAxisLineColor": "#767676", "plotColorPalette": "#f59e0b"}}}}%%
xychart-beta
    title "Share of each payment distributed to stakers (C* = 1.15)"
    x-axis "collateral ratio C" [0.95, 1.00, 1.05, 1.10, 1.15, 1.20, 1.25]
    y-axis "to stakers (%)" 0 --> 100
    line [0, 0, 32, 61, 87, 100, 100]
```

|                          `C` |        share of each payment to stakers |
| ---------------------------: | --------------------------------------: |
|             at or below 1.00 |        0%: all revenue rebuilds backing |
|                         1.05 |                                   \~32% |
|                         1.10 |                                   \~61% |
| 1.15 (= `C*`, launch target) |                                   \~87% |
|                 above \~1.18 | 100%: pure surplus is fully distributed |

Three properties follow from the formula:

* **Below par, stakers earn nothing.** Solvency outranks yield, with no discretion involved: the floor is hard-coded, so an under-backed protocol devotes every incoming dollar to restoring backing.
* **Inside the band, both sides win.** The formula satisfies `α < 1/C` strictly, which is the condition for `C` to keep rising after a distribution. Stakers are paid on every payment while the buffer still climbs; nobody waits for a fully rebuilt buffer before yield begins.
* **`C*` is an attractor, not a wall.** Below target, the split favors retention; above it, distribution, approaching 100% when the surplus is large. The ratio mean-reverts to its target through the yield split itself, with no separate rebalancing mechanism. All rounding in the split truncates in the buffer's favor.

## Vesting

Distributed rewards do not hit the share price at once. The vault releases each distribution linearly over a vesting window (30 days at launch), which closes the obvious timing exploit: depositing just before a distribution and leaving right after captures nothing, because a new deposit sees the pre-distribution price and earns only what vests while it stays. Successive distributions merge into a single extended schedule rather than stacking.

## What rate to expect

The staking rate is variable: it is the cash performance of a real portfolio, net of what the buffer retains, spread over the staked supply. The protocol targets a **double-digit annual yield** for stakers, and the composition explains both the level and its bounds: energy assets are the high-yielding side, while the liquidity sleeve earns money-market rates, the price paid for redemption liquidity. The realized rate depends on the performance of the underlying assets, the Reserve's composition, where `C` stands on the ramp, and the share of supply staked. No fixed rate is promised anywhere in the protocol, and none should be inferred from this page.


---

# 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.suno.finance/protocol/yield-and-staking.md?ask=<question>&goal=<endgoal>
```

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