> 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/protocol-overview.md).

# Protocol overview

The value circuit end to end, and the two commitments every mechanism serves.

The protocol is a circuit. Value moves in one direction, from capital through construction into a producing portfolio, and returns move back in the other. Everything in the following pages is a component of this circuit.

```mermaid
flowchart LR
    I["Investors"] -- "fund construction" --> P["pWatt<br/>(one token per project)"]
    P -- "full swap at<br/>commercial operation" --> R["The Reserve<br/>energy assets + liquidity sleeve"]
    D["The desk<br/>mint / redeem"] --- R
    H["uWatt holders"] <--> D
    R -- "energy revenue<br/>(stablecoin payments)" --> Y["Yield split"]
    Y -- "distributed" --> S["Stakers<br/>(c-uWatt)"]
    Y -- "retained" --> R
```

Reading it left to right:

1. **Financing.** A new solar project is tokenized as its own pWatt and sold to investors. The proceeds build the plant. During this phase the pWatt is the only claim on the project.
2. **Entry into the Reserve.** When the project reaches commercial operation (its first revenues confirm the asset works), the entire pWatt supply is swapped for newly minted uWatt. The project's appraised value is booked into the Reserve in the same transaction, so backing and supply move together. From this point on, no one holds project-specific exposure: the asset belongs to the portfolio, and its former financiers hold uWatt.
3. **Holding and redeeming.** uWatt is minted and redeemed directly against the protocol's desk. The desk quotes one price for both directions, and that price is capped at $1.
4. **Yield.** Electricity sales arrive as stablecoin payments. Each payment is split: a portion is retained in the Reserve to maintain its buffer, and the rest is distributed to uWatt stakers through a compounding vault.

## The two commitments

Every mechanism in the protocol serves one of two structural commitments.

### One price, capped at $1

Both minting and redemption price at

$$
\text{desk price} = \min($1,\ C), \qquad C = \frac{\text{Reserve value}}{\text{uWatt supply}}
$$

where `C` is the collateral ratio: dollars of measured backing per token. While the Reserve covers the supply (`C ≥ 1`), the price is $1 on both sides: an entrant cannot buy a token backed by more than a dollar for a dollar and walk away with the difference, and a redeemer cannot drain the buffer on the way out. If backing ever falls below supply, the same formula prices both sides at `C`: losses are shared pro-rata by everyone who chooses to exit, and there is no prize for redeeming first, which removes the classic incentive to run.

### The Reserve holds more than it owes

The protocol targets a collateral ratio above one: extra assets beyond the value of all uWatt in circulation. Energy assets are revalued as production data, prices and discount rates move, and those revaluations land on the buffer before they can touch holders. The target ratio is sized against a declared shock on the portfolio's energy concentration, and two flows keep it funded: part of every project's appreciation is retained when it enters the Reserve, and part of every revenue payment is retained before yield is paid. How the buffer is sized and rebuilt is covered in [The Reserve](/protocol/the-reserve.md) and [Yield and staking](/protocol/yield-and-staking.md).

## Who does what

The protocol is a hybrid of code and management, and the documentation keeps the boundary explicit.

* **Smart contracts** enforce pricing, issuance, redemption, the yield split, staking, and the cross-chain transport. No operator can mint above the capped price, pay yield the reserve report does not support, or move the risk configuration outside bounded ranges.
* **Suno**, as originator and operator, selects and develops projects, operates them, manages the Reserve's composition, and executes acquisitions and disposals, decisions the code constrains but does not make. Its legal role is that of Protocol Director, described in [Legal structure](/legal/legal-structure.md).
* **Independent parties** close the loop between the two: each project's value comes from a published valuation model with immutable, versioned snapshots, the reserve's holdings are verified by an external proof-of-reserve attestor, and the attested value is written on-chain through a reporter whose per-report movement is bounded. The desk consumes only that attested number, so every price the protocol quotes traces back to a value someone signed.

The pages that follow take each component in turn, starting with the asset itself.


---

# 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/protocol-overview.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.