# Welcome!

This is your starting point to explore everything you need to know about Suno

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Suno Overview</strong></td><td>What Suno is, the problem it solves, and how the system works.</td><td><a href="https://3441843488-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0mAdAaPJz7EXU4NB6Mq1%2Fuploads%2Fgit-blob-13dc222c158a5c1da7891dc46051af682db158e4%2FUruaco%20(1)%20(1).png?alt=media">Uruaco (1) (1).png</a></td><td><a href="/overview/welcome">Welcome to Suno</a></td></tr><tr><td><strong>The Suno Protocol</strong></td><td>The technical reference: instruments, pricing, risk, and governance.</td><td><a href="https://3441843488-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0mAdAaPJz7EXU4NB6Mq1%2Fuploads%2Fgit-blob-34911e31ffe93163c1097b392cb813ce97f4cb72%2Fprotocol.png?alt=media">protocol.png</a></td><td><a href="/protocol/introduction">Introduction</a></td></tr><tr><td><strong>The Financial Model</strong></td><td>The methodology that turns a solar plant into an auditable value.</td><td><a href="https://3441843488-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0mAdAaPJz7EXU4NB6Mq1%2Fuploads%2Fgit-blob-fbf9bc9001413861a7f61df171fcb88609505d61%2FFAQ_cover_suno.png?alt=media">FAQ_cover_suno.png</a></td><td><a href="/financial-model/overview">Overview</a></td></tr><tr><td><strong>Check out our communities</strong></td><td>Join the movement. See what’s happening at Suno.</td><td><a href="https://3441843488-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0mAdAaPJz7EXU4NB6Mq1%2Fuploads%2Fgit-blob-4c3b816b6b4c3744242bad3d349ac5bcd7d8743c%2Fcommunity_suno.png?alt=media">community_suno.png</a></td><td><a href="/misc/community">Suno communities</a></td></tr><tr><td></td><td></td><td></td><td></td></tr></tbody></table>


# Welcome to Suno

Suno builds and finances solar energy projects, and turns the resulting portfolio into digital assets: one for holding the value the operating plants produce, and one for financing new ones.

The plants are real. They sit near the communities they power, sell electricity under long-term contracts, and send their production data to the systems that value them. What Suno adds is the missing financial layer: a way for anyone, anywhere, to fund that infrastructure and hold a claim on what it earns, with the liquidity of a digital asset instead of the lock-up of a private investment.

## The system in three sentences

The **uWatt** is a digital dollar you can mint, redeem, and stake to earn the income of a solar portfolio. What backs it is the **Reserve**: a managed portfolio of operating solar plants plus a liquidity buffer, held at more value than the tokens issued against it. And the plants get there through the **pWatt**, the token that raises the capital to build each project and carries it into the Reserve once it starts producing.

Everything else in this documentation is detail on those three sentences.

## Where to go from here

* To understand the gap Suno exists to close, start with [The problem](/overview/the-problem) and [What Suno builds](/overview/what-suno-builds).
* To watch the system move, with numbers, read [How it works: follow the money](/overview/how-it-works).
* If you are evaluating an investment in a specific project, the technical page on [the pWatt](/protocol/the-pwatt) covers the terms and the economics.
* For the full technical reference, read [The Suno Protocol](/protocol/introduction) front to back.
* For the valuation methodology behind every number the system uses, see [The Financial Model](/financial-model/overview).
* And for the questions everyone asks, in short form: the [FAQ](/overview/faq).


# The problem

Clean energy is short of capital, and the shortage is worst exactly where solar works best.

Developing economies need more than [$1.7 trillion a year](https://unctad.org/news/unctad-calls-urgent-support-developing-countries-attract-massive-investment-clean-energy) of climate-related investment; less than $0.7 trillion arrives. The capital that does flow concentrates in developed markets, while emerging economies, home to two thirds of the world's population and much of the planet's best solar resource, receive roughly 15% of climate finance. The sun is in one place and the money is in another.

## The missing middle

Look closer and the gap has a shape. Very large projects (utility-scale farms in the hundreds of millions) can afford the bankers, lawyers, and year-long structuring that traditional project finance demands. Very small ones (a rooftop here, a rooftop there) fit inside consumer lending. The middle is stranded.

Mid-scale solar plants, roughly $500 thousand to $2 million each, are the natural unit of distributed generation. They are built close to the consumers they serve, they connect quickly, and in many markets they sell energy under long-term contracts or regulated tariffs. As businesses they are boring in the best sense: predictable production, contracted revenue, decades of useful life.

And yet they go unfunded, because the machinery of project finance was never built for their size. Transaction and advisory costs do not shrink with the ticket, structuring takes months a small developer cannot carry, and lenders want bundled portfolios that local developers have no way to assemble. The result is a class of productive, cash-generating assets that global capital has no instrument to reach.

## Capital without a vehicle

The other side of the gap is just as real. There is broad, growing demand for investments that pay a sustainable return and mean something, from retail savers to institutions with climate mandates. What that demand lacks is a vehicle: something liquid, accessible from anywhere, transparent about what backs it, that channels money into this stranded middle of the energy transition.

Building that vehicle is what the rest of this documentation describes. The short version is next, in [What Suno builds](/overview/what-suno-builds).


# What Suno builds

Suno's answer to the financing gap is one system with three pieces. Each piece does a different job, and each one hands off to the next.

## The pWatt: money becomes a plant

Every new project is financed through its own token, the pWatt. Buying pWatts funds the construction of one specific plant, with the money released as installation milestones are met. Investors who commit earlier, when more can still go wrong, enter at a discount.

The pWatt has a bounded job. It carries the project from fundraising to the day the plant proves itself with its first revenues, and then it hands off: the whole project moves into the Reserve, and pWatt investors receive uWatt worth more than they put in. The gain reflects a simple fact about infrastructure: a producing plant is worth more than a construction plan, and whoever carried the construction risk earns a share of that difference. How the gain is split, and why part of it stays in the system, is on the technical page for [the pWatt](/protocol/the-pwatt).

## The Reserve: plants become a portfolio

Operating plants pool into the Reserve, the balance sheet of the whole system. It holds two kinds of assets: the energy projects themselves, valued by a published methodology and verified by independent parties, and a liquidity buffer of stable instruments that keeps money available on demand.

The Reserve's defining property is that it holds more value than the tokens issued against it. That extra margin is a shock absorber: solar production varies with weather, energy prices move, equipment ages, and all of that lands on the margin before it can touch a holder. No single plant matters too much, because the portfolio absorbs what any one project does. The full mechanics are in [The Reserve](/protocol/the-reserve).

## The uWatt: a portfolio becomes a digital dollar

The uWatt is the asset the public holds, and the simplest way to understand it is as a share in that over-collateralized portfolio with a fixed unit value of $1. You can mint it with stablecoins, redeem it back through the protocol, or hold it as a stable unit.

Holding uWatt keeps your value stable; staking it puts your value to work. Staked uWatt (called c-uWatt) receives the portfolio's energy income: as plants sell electricity, part of each payment flows to stakers and the rest reinforces the Reserve's margin. The return is variable because it comes from real operations, and the target is a double-digit annual yield. The pricing rules, the redemption guarantees, and their exact limits are in [The uWatt](/protocol/the-uwatt) and [Yield and staking](/protocol/yield-and-staking).

## What holds it together

Three habits run through everything above, and they are what makes the system checkable:

* **Every number is measured.** Plants report their production; valuations come from a published model with frozen, versioned snapshots; an independent attestor verifies that the Reserve holds what it claims.
* **The margin is maintained.** Part of every project's appreciation and part of every revenue payment stay in the Reserve, so the cushion that protects holders is rebuilt continuously.
* **The rules are code.** Prices, redemption limits, and the yield split are enforced by smart contracts that operators cannot override.

To see all three pieces move together, follow a dollar through the system: [How it works](/overview/how-it-works).


# How it works: follow the money

The fastest way to understand the system is to watch money move through it. Two journeys cover everything: a dollar that builds a plant, and a dollar that holds the result. The numbers below are illustrative, chosen round for readability; the exact rules behind each step live in the linked pages.

## The building dollar

A developer brings Suno a project: a 1 MW plant with a signed energy contract, needing **$1,000,000** to build.

1. **The raise.** The project is tokenized as its own pWatt and investors fund it, with proceeds released against installation milestones. Early backers enter at a discount for carrying more of the construction timeline.
2. **Construction and proof.** The plant is built, connected, and starts selling electricity. Its first revenues are the proof that the asset works as designed.
3. **The swap.** The plant is appraised at **$1,200,000** (a producing asset is worth more than a construction plan) and the entire project moves into the Reserve. Investors receive uWatt worth about **$1,100,000**: a **10% return** for having carried construction. The remaining **\~$100,000** of appreciation stays in the Reserve, reinforcing the margin that protects everyone downstream. ([The pWatt](/protocol/the-pwatt) has the exact split rule.)

The investors now hold a liquid asset backed by the whole portfolio, and their exposure to that single plant is over. Capital is free to fund the next project.

## The holding dollar

Now take the other side: you arrive with **$100** in stablecoins.

1. **Mint.** You deposit $100 at the protocol's desk and receive **100 uWatt**. Your stablecoins join the Reserve's liquidity buffer. Behind each of your tokens sits more than a dollar of assets; the margin above par belongs to the system, not to any single entrant. ([The uWatt](/protocol/the-uwatt))
2. **Stake.** You deposit your 100 uWatt in the staking vault and receive **c-uWatt**, a share whose value in uWatt grows as income arrives. No lockup; you can unstake at any time. ([Yield and staking](/protocol/yield-and-staking))
3. **A month passes.** The Reserve's plants collect, say, **$10,000** from electricity sales. Each payment is split by a rule that reads the health of the Reserve: when the margin is at its target, most of the payment (roughly ninety cents of each dollar) becomes staker yield, and the rest stays in the Reserve. When the margin is below target, the split shifts automatically toward rebuilding it. Your c-uWatt is now worth slightly more uWatt than you deposited.
4. **Months compound.** Each payment repeats the cycle. Your yield is variable, because it is the cash performance of real plants, and it arrives without any action on your part: the share price of c-uWatt simply rises as distributions vest.
5. **Exit.** You unstake (c-uWatt converts back to uWatt at the going rate) and redeem at the desk: $1 per uWatt, minus a small redemption fee, paid from the liquidity buffer. On days of unusually heavy redemptions, a daily queue spaces exits out so the portfolio never has to fire-sale a plant. ([The uWatt](/protocol/the-uwatt) covers the guarantees and their limits.)

## The loop

Put the two journeys together and the system is a loop: capital builds plants, plants join the portfolio, the portfolio backs a digital dollar, electricity revenue pays the dollar's holders, and freed capital funds the next plant. Every step is enforced by contracts, priced from audited valuations, and visible on-chain.

The pages in [The Suno Protocol](/protocol/introduction) specify each step with the precision an auditor would want.


# Vision

The energy transition will be financed or it will not happen, and most of the financing gap sits in places and project sizes that traditional capital markets do not reach. Suno's purpose is to give that stranded middle a direct line to global capital: make a mid-scale solar plant in an emerging market as investable as a treasury bill, without asking either side to compromise. The saver gets liquidity, transparency, and a return paid by real electricity; the plant gets built.

The near arc is widening the portfolio. More plants, then more geographies, then more energy technologies and contract structures, so that the Reserve's protection comes less from its margin and more from the diversification itself. A portfolio spread across many assets, markets, and revenue structures is the destination, and the over-collateralization buffer is what carries holders safely along the way.

The longer arc is what a growing Reserve makes possible: an energy-backed digital dollar that is useful beyond holding it. A unit that people save in, price in, and build on, whose backing is productive infrastructure, and whose yield traces to sunlight hitting panels that someone, somewhere, decided to fund.

Two things stay constant at any scale. Every claim remains checkable: measured production, published valuations, independent attestation, rules in code. And the purpose stays physical: behind every token, a plant; behind every yield payment, electricity that was generated and sold. The protocol exists so that financing clean energy is a good deal on both ends, and that alignment, more than any mechanism, is what the system is built to protect.


# FAQ

The short answers. Each one links to the page that carries the full mechanics.

## About the uWatt

<details>

<summary>What backs the uWatt, and how can I check it?</summary>

Every uWatt is backed by the Reserve: operating solar plants plus a liquidity buffer, together worth more than all the uWatt in circulation. The value is checkable link by link. The plants are valued by a published model with frozen, versioned snapshots, an independent attestor verifies that the holdings are real, and the attested number is written on-chain, where the protocol's desk reads it. [The Reserve](/protocol/the-reserve) walks through the whole chain.

</details>

<details>

<summary>Is the uWatt a stablecoin?</summary>

It is an asset-backed token with a $1 target, closer to a share in an income fund with a fixed unit value than to a payments stablecoin. A payments stablecoin promises instant 1:1 redemption of its whole supply against fully liquid backing. The uWatt's backing is mostly productive infrastructure, so instant redemption is guaranteed up to the liquidity buffer, and converting the rest takes time. [The uWatt](/protocol/the-uwatt) draws the exact boundaries of the promise.

</details>

<details>

<summary>Can I lose money holding uWatt?</summary>

While the Reserve is worth at least as much as the supply, every uWatt redeems at $1, and the protocol maintains a margin above that line so that swings in the plants' value land on the margin first. If a large enough shock ever pushed the backing below the supply, the token would be worth exactly the backing per token, and everyone who exits during the impairment takes the same pro-rata haircut. The margin exists so ordinary swings never reach holders; the pro-rata rule exists so an extraordinary one is shared fairly instead of falling on whoever redeems last. The numbers behind both are in [The uWatt](/protocol/the-uwatt) and [The Reserve](/protocol/the-reserve).

</details>

<details>

<summary>Can I always redeem? What are the limits?</summary>

Redemption is open against the liquidity buffer, at $1 per uWatt minus a small fee. Two mechanisms protect the portfolio while keeping the door open: when the buffer's cash runs short, liquid instruments convert automatically to cover the payout, and a daily queue spaces out unusually heavy days so a plant never has to be sold in a hurry. [The uWatt](/protocol/the-uwatt) covers the guarantees and their limits.

</details>

<details>

<summary>What happens if everyone redeems at once?</summary>

The queue turns the spike into an ordered line, with everyone paid the same price. Heavy redemption also sets a counterweight in motion: exits drain the lowest-yielding part of the Reserve and spread the same energy income over fewer tokens, so the staking yield rises, and a higher yield attracts fresh minting that rebuilds the buffer. The full dynamic is in [The uWatt](/protocol/the-uwatt).

</details>

## About the yield

<details>

<summary>Where does the yield come from?</summary>

Electricity. The Reserve's plants sell energy under long-term contracts, the payments arrive as stablecoins, and each payment is split between stakers and the Reserve's margin. If revenue does not arrive, nothing is distributed: the protocol never mints yield against a projection. [Yield and staking](/protocol/yield-and-staking) has the split rule.

</details>

<details>

<summary>What rate should I expect, and why is it variable?</summary>

The protocol targets a double-digit annual yield for stakers, and no fixed rate exists anywhere in the system. What you receive is the cash performance of real plants, shaped by weather, energy prices, the Reserve's composition, and how much of the supply is staked alongside yours. [Yield and staking](/protocol/yield-and-staking) explains each factor.

</details>

<details>

<summary>What is c-uWatt, and how does staking work?</summary>

c-uWatt (Compounding uWatt) is what you receive for depositing uWatt in the staking vault: a share whose value in uWatt grows as income vests. There is no lockup and nothing to claim; you unstake at any time at the going rate, and your yield arrives as the share simply becoming worth more. [Yield and staking](/protocol/yield-and-staking) covers the vault and its vesting.

</details>

<details>

<summary>Do I have to stake?</summary>

No. Unstaked uWatt is the stable unit: it holds its $1 target and works for payments, liquidity pools, and pricing. The portfolio's income goes to those who opt in by staking, so holding without staking means choosing stability without the return.

</details>

## About pWatts and the projects

<details>

<summary>What does buying pWatts mean, and what do I earn?</summary>

You finance the construction of one specific plant. When it reaches commercial operation, you receive uWatt worth more than you put in: your reward is a share of the value created by carrying the project through construction. The illustrative journey in [How it works](/overview/how-it-works) shows a $1.0M raise returning about 10% at the swap, and [the pWatt](/protocol/the-pwatt) has the exact rule that divides the gain.

</details>

<details>

<summary>What happens to my pWatts when the plant starts operating?</summary>

The project's entire pWatt supply is exchanged for uWatt in one operation, and the pWatts themselves stay in the Reserve as the on-chain certificate of the project it now owns. From then on you hold uWatt: liquid, diversified across the whole portfolio, and stakeable. [The pWatt](/protocol/the-pwatt) explains why the swap is total.

</details>

<details>

<summary>What risks do I take during construction?</summary>

The risks of building: schedule delays, equipment procurement, connection and commissioning. Funds are released against installation milestones, and the discount for entering early is the compensation for carrying more of that timeline. pWatts can be transferred person to person, though the protocol does not operate a secondary market for them; the instrument exists to be held to commercial operation. [The pWatt](/protocol/the-pwatt) covers the terms.

</details>

<details>

<summary>How does Suno decide which projects to finance?</summary>

Every candidate is valued with the same published model that prices the Reserve: measured production expectations, contracted revenue, audited costs, explicit risk premiums. A project whose economics cannot both reward its investors and sustain the Reserve's margin does not get originated. The filter is described in [Risk management](/protocol/risk-management), and the methodology in [The Financial Model](/financial-model/overview).

</details>

## About trust and control

<details>

<summary>Who controls the protocol? Can Suno change the rules?</summary>

Daily operations run on narrow keys that can each do exactly one job. Configuration and upgrades sit behind a multisig and a timelock, and every change is a public on-chain event. Some rules bind the administrators themselves: no role can mint above the capped price, pay yield that revenue does not support, or write an internally inconsistent risk configuration. There is no token-holder voting. [Governance and parameters](/protocol/governance-and-parameters) has the full authority map.

</details>

<details>

<summary>Who verifies that the Reserve is real?</summary>

Three parties outside the operating team. An independent proof-of-reserve attestor continuously verifies that the value reported on-chain matches real holdings; the smart contracts undergo independent security audit; and the valuation methodology is published in full, so anyone can recompute the numbers behind the backing. [Risk management](/protocol/risk-management) and [The Financial Model](/financial-model/overview) are the places to start checking.

</details>


# Introduction

Suno turns operating solar infrastructure into a digital asset that anyone can hold, redeem against the protocol, and earn from. This section is the protocol reference: what the instruments are, how value enters and leaves the system, and which guarantees are enforced by code, which by collateral, and which by management. The purpose behind the system, and the financing gap it exists to close, are covered in [Suno Overview](/overview/welcome); these pages assume you want the mechanics.

## What Suno does

Suno originates these projects, finances their construction, operates them, and converts the resulting portfolio into on-chain instruments with different jobs:

* The **pWatt** is a per-project token that raises the capital to build. It carries the project from fundraising to commercial operation; when the project starts producing revenue, the entire pWatt supply is exchanged for uWatt, and the pWatts themselves are deposited in the Reserve as the on-chain certificate of the project it now owns.
* The **Reserve** is the protocol's balance sheet: a managed portfolio of operating energy assets plus a sleeve of liquid reserves, kept worth more than the tokens issued against it.
* The **uWatt** is the asset the public holds: an ERC-20 backed by the Reserve, mintable and redeemable directly against the protocol at a target price of $1. Staking it produces **c-uWatt** (Compounding uWatt), the form that accrues the portfolio's energy revenue as yield.

Each piece has its own page. The short version of how they fit: capital buys pWatts and builds a plant; the plant proves itself and its appraised value moves into the Reserve; the Reserve backs uWatt; electricity sales flow back as stablecoin payments, part retained to strengthen the backing and part distributed to stakers.

## What kind of asset the uWatt is

uWatt is an asset-backed, yield-bearing token: a real-world-asset (RWA) instrument, not a payments stablecoin. A payments stablecoin promises fully liquid backing and instant 1:1 redemption of the whole supply. Most of the uWatt's backing is illiquid, because energy infrastructure is what generates the return, so instant redemption is guaranteed only up to the liquid portion of the Reserve. The $1 rests on backing: while the Reserve is worth at least as much as the supply, every token is redeemable at $1, and the protocol holds a buffer above that line that protects investors from fluctuations in the value of the underlying assets. The closest traditional analogue is a share in an over-collateralized income fund with a fixed unit value, where returns are paid out rather than priced in.

## How this section reads

[Protocol overview](/protocol/protocol-overview) draws the full value circuit and the two commitments everything else follows from. [The uWatt](/protocol/the-uwatt) and [The Reserve](/protocol/the-reserve) cover the asset and its backing; [The pWatt](/protocol/the-pwatt) covers project financing and the economics of the swap into the Reserve; [Yield and staking](/protocol/yield-and-staking) covers how energy revenue becomes staker yield; [Risk management](/protocol/risk-management) and [Governance and parameters](/protocol/governance-and-parameters) cover what can go wrong and who can change what.

The valuation methodology behind every number the Reserve books, from a solar plant to an auditable net present value, is documented in full in [The Financial Model](/financial-model/overview).


# Protocol overview

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 + liquid sleeve"]
    D["Cash 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 cash 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) and [Yield and staking](/protocol/yield-and-staking).

## 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 asset manager, selects and develops projects, operates them, manages the Reserve's composition, and executes acquisitions and disposals — decisions the code constrains but does not make.
* **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.


# The uWatt

The uWatt is an ERC-20 token backed by the Reserve. It targets a price of $1 and enforces the target at the source: the protocol's own desk, where every uWatt is created and redeemed at the value of its backing, up to $1. A target enforced at issuance needs no market interventions to defend it — as long as the backing is there, the price is too.

## The cash desk

uWatt is created and destroyed at a single venue: the protocol's cash desk. A user deposits stablecoins and receives uWatt; a holder returns uWatt and receives stablecoins. Both operations quote the same price:

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

The desk reads the Reserve value from the on-chain attestation described in [The Reserve](/protocol/the-reserve), and refuses to trade at all if that attestation is stale: a protocol that has lost sight of its backing stops quoting.

**While the Reserve covers the supply (`C ≥ 1`)**, the price is $1 in both directions:

* A mint at $1 adds a dollar of assets and a dollar of liabilities. The buyer gets what they paid for, a fully backed token, and none of the buffer above it. Whatever surplus the Reserve holds belongs to the system and, through the yield mechanism, to stakers; it cannot be bought at par.
* A redemption at $1 pays the holder in full, minus a redemption fee (0.5% at launch), and leaves the buffer untouched.

**If backing falls below supply (`C < 1`)**, the same formula prices both sides at `C`:

* Redemptions pay the honest, impaired value. Everyone who exits during the impairment takes the same pro-rata haircut, so there is nothing to gain by racing to the exit: the classic run dynamic, where early redeemers are made whole at the expense of late ones, cannot start.
* Minting *below* par is the **recapitalization window**: fresh capital can enter at the depressed price, which adds backing and supply in the ratio that leaves `C` unchanged. The rescuer's return comes only if the Reserve recovers above their entry price. This window is bounded by a governance floor and ships closed at launch (the desk is par-only); opening it is a governance decision in its own right, discussed in [Risk management](/protocol/risk-management).

## Redemption liquidity

The desk pays redemptions from the Reserve's liquid sleeve: stablecoins plus tokenized short-duration instruments that unwind on demand. When the cash portion runs short, the desk automatically unwinds liquid instruments to cover the payout; if even that is insufficient, the redemption reverts rather than paying late or partially.

Redemptions are additionally metered by a daily limit (1% of supply per day at launch). The limit works as a queue rather than a cap: it spreads a redemption spike into an orderly sequence, giving the portfolio time to convert assets without forced sales. Combined with pro-rata pricing under impairment, it turns a stressed day into a line of people receiving the same price.

One detail closes an arbitrage seam: the redemption fee is kept strictly larger than the per-report movement band of the reserve attestation, so straddling a report (redeeming just before a value increase and re-minting just after, or the reverse) cannot turn a profit.

Heavy redemption also sets its own counterweight in motion. Exits are paid from the liquid side, the lowest-yielding part of the Reserve, so a wave of redemptions leaves the remaining backing more concentrated in energy assets and spreads the same energy revenue over a smaller supply, and the staking yield rises. A higher yield attracts new minting, and new minting arrives as stablecoins that rebuild the liquid side. The composition regulates itself: the flow that drains liquidity raises the return that brings liquidity back.

## What the $1 covers

The promise has three parts:

* Every uWatt is redeemable at $1 while `C ≥ 1`, a condition the protocol maintains with its over-collateralization buffer.
* Redemption at any moment is guaranteed **up to the liquid sleeve**; the rest of the backing is productive infrastructure that takes time to convert. The daily queue exists to bridge exactly that timing gap.
* Below `C = 1`, the token is worth `C` and the desk says so. No mechanism pays anyone more than the assets are worth.

This is the profile of an over-collateralized, asset-backed instrument, functionally closer to a fixed-unit-value share in an income fund than to a payments stablecoin. Holders who want the fund's return stake their uWatt; the unstaked token is the stable unit, and the staked form is where the portfolio's earnings accrue. That split is the subject of [Yield and staking](/protocol/yield-and-staking).


# The Reserve

The Reserve is the protocol's balance sheet: everything the uWatt is redeemable against. It is a managed portfolio with two sides, productive energy assets that generate the return and liquid reserves that make the desk's promises immediate, held at more value than the tokens issued against it.

## Composition

The Reserve holds two classes of assets:

* **Energy assets.** Tokenized operating solar projects, held by the protocol on-chain and valued at their audited net present value. These are the reason the system exists: they produce electricity, revenue, and the yield the protocol distributes.
* **Liquid reserves.** Stablecoins and tokenized short-duration instruments (treasury-backed savings instruments in the current configuration). They earn a modest baseline return, and their job is availability: funding redemptions on demand and settling portfolio operations without touching the productive side.

The target composition is around **70% energy assets and 30% liquid reserves**. The target is managerial: it adapts to portfolio size, redemption behavior, and market conditions. What the protocol enforces on-chain are the outer guardrails: a governance-set ceiling on energy concentration and a floor on the liquid sleeve, which operator transactions cannot cross. Acquisitions that would over-concentrate the portfolio revert; treasury movements that would drain the liquid tranche below its floor revert. The dials themselves are bounded and every change is recorded on-chain; see [Governance and parameters](/protocol/governance-and-parameters).

The mix also sets the return. The Reserve's gross yield blends its two sides: the cash return of the energy assets on roughly 70% of the portfolio and money-market rates on the rest. Each uWatt is backed by more than a dollar of that earning mix while `C` holds above one, and how much of the income reaches stakers versus how much is retained to keep `C` near its target is decided payment by payment in [Yield and staking](/protocol/yield-and-staking).

## Why over-collateralized

The protocol targets a collateral ratio above one:

$$
C = \frac{\text{Reserve value}}{\text{uWatt supply}} \ \longrightarrow\ C^\* > 1
$$

The gap between `C` and 1 is the buffer, and the buffer is what stands between holders and the movement of asset values. Energy assets are living valuations: production varies with weather, energy prices move with their indexation, discount rates shift, equipment ages. Every revaluation lands on the buffer first, and holders feel none of it until the buffer is exhausted.

The size of the target follows a rule. Governance declares a **design shock**, the combined revaluation the posture must absorb, and the contract enforces at the configuration level:

$$
C^\* \geq 1 + \text{design shock} \times \text{energy concentration ceiling}
$$

A posture that declares a 10% shock tolerance on an 80% energy ceiling cannot set a target below 1.08; the working target sits above that line with margin: 1.15 at launch. The rule is checked in the contract whenever the risk configuration changes: governance can move any dial, but cannot write a combination that contradicts its own declared risk appetite.

Two flows keep the buffer funded. When a project enters the Reserve, part of its appreciation over construction cost is retained rather than issued as uWatt ([The pWatt](/protocol/the-pwatt)). And when energy revenue arrives, part of each payment is retained rather than distributed ([Yield and staking](/protocol/yield-and-staking)), with the retained share growing automatically whenever `C` sits below target. Between the two flows, the buffer is rebuilt continuously.

## Where the numbers come from

A promise of over-collateralization is only as good as the valuation behind it. The chain from a solar plant to the number the desk trades on has four links, each independently checkable:

1. **The valuation model.** Every project is valued by the protocol's published financial model (measured telemetry, contracted prices, audited costs, an explicit discount build-up), with each published valuation frozen as an immutable, versioned snapshot. The methodology is documented in full in [The Financial Model](/financial-model/overview).
2. **Independent attestation.** That the Reserve's claimed holdings and values correspond to reality is verified by an external proof-of-reserve attestor, on a separate track from the protocol's own reporting.
3. **The on-chain report.** The attested value is written on-chain through a reporter contract on a weekly cadence. Routine reports are bounded: a single report cannot move the reserve value more than a narrow band, so no single reporting key can reprice the system. Larger corrections require a governance action paired with a protocol pause, making them loud by construction.
4. **Fail-closed consumption.** Every contract that reads the reserve value checks its freshness. A stale report does not degrade gracefully into an old price; it halts the paths that depend on it until reporting resumes.

## Managing the portfolio

The Reserve is actively managed through a narrow surface. Acquisitions and disposals of energy assets settle value-neutrally: the asset's audited value and the matching cash movement are booked in the same transaction, so portfolio operations never move `C`. Idle liquid reserves are deployed into short-duration instruments and unwound on demand. A project that reaches the end of its useful life leaves quietly: by then its audited value has amortized to zero, so its exit removes nothing from the backing. For the other cases (a project sold, replaced, or withdrawn for operational or commercial reasons while still productive), the protocol carries an exit path that burns uWatt against the outgoing asset at its audited value: a portfolio-management tool, not a user-facing function.

Over time the portfolio widens: more projects, more geographies, additional energy technologies and offtake structures. Concentration limits that are appropriate for a young, solar-heavy portfolio are expected to tighten per-asset and relax per-class as the asset count grows. The buffer protects against what diversification has not yet absorbed, and the two trade places gradually. The risk view of this trajectory is developed in [Risk management](/protocol/risk-management).


# The pWatt

The pWatt is how new infrastructure gets built. It is a financing instrument with a deliberately bounded life: it exists to raise the capital for one specific project, carry its investors through construction, and pass into the Reserve the moment the project proves itself. At commercial operation its investors move on to uWatt; the pWatt itself stays in the Reserve as the on-chain certificate of the project it financed.

## One token per project

Each project is tokenized as its own ERC-20 with a fixed supply proportional to installed capacity, priced so that one pWatt reflects the cost of originating one watt of generation. Investors who fund the project earlier, carrying more construction timeline and more uncertainty, enter at a discount to those who join closer to the operation date. The raise funds the build directly, with proceeds released against installation milestones.

## The swap at commercial operation

When the project starts producing (its first revenues confirm the asset works as designed), the entire pWatt supply is swapped for newly minted uWatt. The swap is total: no pWatt exposure survives commercial operation. The purpose is to strengthen the aggregate. Individual projects carry risks of their own that a portfolio absorbs; bringing every operating asset into the Reserve, rather than leaving some investors exposed to single projects, is what makes the Reserve's diversification real and the uWatt's backing homogeneous.

The swap is executed by the protocol in batches across all holders, each holder settled exactly once, and it is value-neutral for the system: the project's audited value enters the Reserve in the same transaction that mints the corresponding uWatt.

## The economics: who earns the appreciation

A project that survives construction is worth more than it cost: financing risk has been retired and revenue is flowing. Call the margin between the audited net present value `V` and the construction capital `K` the project's appreciation `g`:

$$
V = K \cdot (1 + g)
$$

The swap decides how that appreciation is divided, through a single lever, the **swap price** `P`: the price per uWatt at which the incoming project is recognized. The Reserve books the full audited value `V`; the investors collectively receive `V / P` uWatt. Since each uWatt is worth $1 at the desk, the investor return over the construction period is:

$$
r\_p = \frac{1 + g}{P} - 1
$$

and everything not issued stays in the Reserve as retained appreciation:

$$
\theta = \frac{V - V/P}{V - K} \quad \text{(the fraction of the uplift retained)}
$$

* At `P = $1`, investors capture the entire uplift and the swap adds backing and supply one-for-one, and the Reserve's ratio dilutes toward 1 with every project.
* At `P = C` (the current collateral ratio), the swap is exactly ratio-neutral: the retained share is precisely what keeps `C` unchanged.
* In general, a constant swap price `P` makes the collateral ratio converge to `P` over successive swaps: the swap price *is* the long-run collateralization the entry mechanism sustains.

The protocol sets `P` per project, between par and the ratio-neutral level, balancing two obligations that pull in opposite directions: rewarding the investors who carried construction risk, and funding the buffer that protects everyone who holds the result. A floor on `P` comes from economics: the pWatt return must beat what the same capital would have earned holding staked uWatt over the construction period, plus a premium for the added risk. A project whose expected uplift cannot clear that bar at a buffer-sustaining swap price does not get originated, so the viability test doubles as an origination filter.

**A worked example.** A project raises `K` = $1.0M and reaches commercial operation appraised at `V` = $1.20M (`g` = 20%). Swapped at `P` = $1.09, investors receive 1,100,917 uWatt, worth $1.10M at the desk: a 10.1% return over the construction period. The Reserve books $1.20M of assets against $1.10M of new liabilities: $99k of the $200k uplift (`θ` ≈ 0.5) stays in the buffer. Both sides are paid from the same appreciation, and the division is explicit, on-chain, and decided before the swap executes.

After the swap, the investor holds the most liquid form of the same underlying exposure: uWatt they can redeem at the desk, hold as a stable unit, or stake to keep earning the portfolio's yield, now diversified across every project in the Reserve instead of concentrated in one.


# Yield and staking

The Reserve earns money two ways: its projects sell electricity, and its liquid 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 liquid 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.


# Risk management

The protocol's risk lives at two altitudes. Below the waterline are the assets: real infrastructure, in real markets, with weather, counterparties, and equipment. Above it is the protocol: the code and process that turn those assets into a redeemable token. Managing the first is portfolio work; managing the second is engineering. This page covers both, in that order, and ends with what is verified by parties other than Suno.

## Asset-level risk

The Reserve's return is generated by physical projects, and each of the ways a project can disappoint has a named owner in the process:

* **Production risk.** Solar output varies with weather and degrades with age. Projects are underwritten on measured telemetry rather than nameplate promises, production assumptions blend actual history with design values, and the [sensitivity analysis](/financial-model/sensitivity-analysis) published with every valuation quantifies the impact of production shortfalls calibrated from the portfolio's own operating history.
* **Revenue risk.** Electricity is sold under long-term contracts and regulated tariffs, most indexed to inflation measures. Offtakers are credit-assessed at origination; contracts carry penalty and termination clauses; late payment accrues interest.
* **Cost and equipment risk.** Every valuation carries an explicit schedule of future equipment replacements (probabilistic, escalation-adjusted, with contingencies) instead of a flat maintenance allowance. Plants operate under preventive and corrective O\&M contracts and insurance appropriate to each site.
* **Currency and macro risk.** Projects earn in local currencies against a USD-denominated token. Valuations project exchange rates from explicit macro assumptions, and the sensitivity set includes devaluation scenarios calibrated from the relevant currency's own history.
* **Concentration risk.** A young portfolio is the most exposed to any single asset, geography, or technology. The over-collateralization buffer is sized against this case, a declared shock on the maximum energy concentration, and the trajectory is for diversification and the buffer to trade places gradually: more projects, more markets, more energy technologies and offtake structures, with concentration dials adjusted as the asset count grows.

The origination filter matters as much as the management: the same valuation model that prices the Reserve decides what enters it. A project whose risk-adjusted economics cannot clear the swap viability test described in [The pWatt](/protocol/the-pwatt) does not get originated.

## Protocol-level risk

The engineering follows a small number of rules applied everywhere.

**Fail closed.** Every contract that consumes a price or a reserve report checks its freshness and reverts if it is stale. There is no code path where the protocol trades on a number nobody stands behind. The staleness windows themselves are range-bounded, so no single transaction can quietly widen a gate to infinity.

**Bound every write.** Routine reserve reports move at most a narrow band per report; larger corrections require a governance action paired with a pause. The risk configuration is written atomically as a whole and rejected if internally inconsistent. Oracle updates on secondary networks pass three independent guards.

**Contain every failure.** Minting authority is capped per contract. Bridged supply is rate-limited per transport. The redemption queue meters exits at a daily rate.

**Watch what code cannot reject.** On-chain guards can revert transactions, but some breaches arrive without one: a revaluation that pushes energy concentration over its ceiling, or a redemption wave that thins the liquid sleeve. An independent reconciliation monitor recomputes the protocol's accounting continuously against on-chain state: value conservation, oracle recomputation, custody versus event-implied balances, posture drift, liquidity levels. Its most critical checks hold a one-way power: they can pause issuance, and nothing else. Alerts that an outsider could trigger on purpose, for instance by redeeming enough to thin the sleeve, are kept warning-only, so no one can weaponize the safety system into a denial of service.

**Under impairment, losses are shared.** If the Reserve ever falls below the supply, the desk prices both directions at the impaired value `C`: every exit takes the same pro-rata haircut and being first buys nothing. The recapitalization window (minting below par, which adds backing and supply in a ratio that leaves `C` unchanged) lets outside capital restore the protocol at that same value, with the rescuer compensated only by recovery itself. The window is gated by a governance floor and ships closed: at launch the desk is par-only. Opening the window later is a single on-chain governance transaction; recovering from a premature opening is not, because a sub-par mint is only as sound as the reserve report behind it and minted tokens cannot be recalled.

## External assurance

Three verifications run on separate tracks from the team that operates the protocol: the smart contracts undergo independent security audit; the correspondence between the Reserve's on-chain reported value and its real holdings is verified by an independent proof-of-reserve attestor on a continuing basis; and the valuation methodology itself is published in full (model, inputs, sensitivity, versioned snapshots) in [The Financial Model](/financial-model/overview), so the one number everything depends on can be recomputed by anyone.


# Governance and parameters

This page states plainly who can do what. The protocol has no token-holder voting. Authority is held by named roles with narrow scopes, the sensitive ones behind a multisig and a timelock, and every exercise of authority is an on-chain event anyone can audit.

## The authority model

Authority is split into two tiers by temperature:

* **Operational keys** run the protocol's daily loop, and each can do exactly one job: the *attestor* writes the weekly reserve report (inside its per-report band); the *energy payer* routes revenue payments into the yield split; the *keeper* pushes the price mirror to secondary networks; the *monitor* holds a single one-way power, pausing issuance. None of these keys can mint freely, reprice the reserve outside its band, change configuration, or upgrade code.
* **Governance keys**, held by a multisig with upgrades additionally behind a timelock, set the risk configuration, manage roles, execute treasury operations, and authorize contract upgrades. The timelock makes the most powerful action, changing the code itself, publicly visible before it takes effect.

Hot keys with a narrow blast radius do the frequent work; cold, slow keys do the rare and dangerous work.

## What governance cannot do

Several constraints bind the administrators themselves, in code:

* **The desk price is not a parameter.** No role can mint above `min($1, C)` or redeem below it. The pricing law is structural.
* **Yield cannot outrun revenue.** A distribution can never mint more than the payment that funded it, and cannot mint at all while the protocol is at or below par.
* **The risk configuration must be self-consistent.** The five risk dials are written atomically, each within a bounded range, and the write reverts unless the sizing rule `C* ≥ 1 + design shock × energy ceiling` holds: governance can move its risk appetite, but cannot declare one and configure another.
* **The guards' own dials are bounded.** Staleness windows and movement bands accept values only within fixed ranges, and every change emits an event. Widening a safety margin is possible; disabling one silently is not.
* **Reserve reports are banded.** Even the attestation path cannot reprice the system in one step; corrections beyond the band require a governance action paired with a pause.

## Parameters

The protocol's behavior is set by a small number of dials. The values below are the launch configuration. Each is governance-adjustable within its bounded range, expected to evolve with the portfolio (a young, concentrated Reserve warrants different settings than a diversified, mature one), and every change is recorded on-chain.

| Parameter                    | What it sets                                                                                 | At launch                                                        |
| ---------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| Collateral target `C*`       | The over-collateralization level the yield split mean-reverts to                             | 1.15                                                             |
| Recapitalization floor       | The lowest `C` at which sub-par minting stays open; at 1.0 the desk is par-only              | 1.0 — window closed                                              |
| Energy concentration ceiling | Maximum share of the Reserve in energy assets that acquisitions may not cross                | dial; \~70/30 energy-to-liquid is the working composition target |
| Liquid floor                 | Minimum liquid sleeve that operator outflows must preserve                                   | dial, paired with the above                                      |
| Design shock                 | The declared combined revaluation the posture must absorb — the input to the sizing rule     | 10%                                                              |
| Redemption fee               | Charged on exit; strictly above the report band so straddling a report is unprofitable       | 0.5%                                                             |
| Daily redemption limit       | The queue rate that converts a redemption spike into an orderly sequence                     | 1% of supply per day                                             |
| Yield start                  | The collateral ratio at which staker distributions switch on                                 | par                                                              |
| Reward vesting window        | The period over which each distribution vests to stakers                                     | 30 days                                                          |
| Attestation cadence and band | How often the reserve value is reported, and the maximum routine move per report             | weekly · 0.3%                                                    |
| Swap price `P`               | The per-project recognition price that divides appreciation between investors and the buffer | set per project                                                  |

## Verifiability

The protocol's claims are checkable. The contracts are public; the configuration is readable on-chain at any time; every parameter change, report, pause, and upgrade emits an event; valuations are published with immutable versioned snapshots under a documented methodology; and the reserve's correspondence to real holdings is attested by an independent party. Where a guarantee is enforced by code, these pages say so; where it rests on management or custody practice, they say that instead.


# Overview

The Suno Financial Model computes the Net Present Value (NPV) of each operating project in the portfolio and, from it, the Net Asset Value (NAV) per pWatt: the price at which project fractions are recognized by the protocol.

Most of the protocol's economics run through this number. When pWatt holders contribute their tokens to the Reserve, the uWatts they receive are issued against the project's NPV, and the published valuations of the portfolio are what stand behind the uWatt. The model is documented here in full, formulas and calibrations included, so that anyone can examine how the numbers that back the protocol are produced.

The methodology itself evolves. Improvements are adopted over time, following industry practice, and every methodological change is versioned and documented. Published valuations, on the other hand, never change: each one permanently keeps the inputs, method, and results it was produced with (see [Governance and auditability](/financial-model/governance-and-auditability)).

#### What the model computes

For each project, the model projects the remaining life of the asset, typically 20 to 30 years, one year at a time:

* Revenue: energy production anchored to metered history, contracted energy prices, and renewable energy certificates.
* Costs: operating expenses anchored to validated invoices, scheduled equipment replacements, and the protocol fee.
* Cash flows in local currency, converted to USD along a projected exchange-rate path and discounted with a year-by-year rate.

Three figures result: the NPV of the project's net cash flows; the NPV after the withholding tax that applies when project income is distributed through the protocol's regulated structure; and the NAV per pWatt, which divides the post-withholding NPV by the project's pWatt supply (one pWatt per watt of installed DC capacity).

#### Design principles

1. **Measured over promised.** Where real operating data exists, the model uses it instead of design estimates, weighting it by how much of the operating cycle it has observed. Projections re-anchor as new invoices arrive.
2. **Deterministic.** The engine is a pure function: the same inputs produce the same valuation, to the last decimal. No hidden state, no manual overrides.
3. **Frozen once published.** A published valuation keeps its complete input snapshot forever and can be recomputed by anyone, at any time.
4. **Uncertainty comes with the number.** Every valuation ships with a sensitivity analysis, calibrated on data, that brackets the NAV under stated adverse and favorable conditions.
5. **Conventions on the record.** Where the methodology requires a choice, such as the discounting convention or a blending rule, the choice and its rationale are written down.

#### From data to published NAV

Inputs are assembled from live sources: project data, billing telemetry, versioned macroeconomic projections, the contracted price curve, and the project's risk assessment. The engine computes the full year-by-year table and the resulting NPV and NAV. This draft is recomputed on demand as data changes. Publication then freezes the draft into a numbered, immutable version, which is what token holders and the Reserve consume.

The rest of this section covers each stage: [inputs and data](/financial-model/inputs-and-data), the [valuation engine](/financial-model/valuation-engine), [equipment replacement](/financial-model/equipment-replacement), [discounting and NAV](/financial-model/discounting-and-nav), the [sensitivity analysis](/financial-model/sensitivity-analysis), [governance](/financial-model/governance-and-auditability), and the model's [assumptions and limitations](/financial-model/assumptions-and-limitations).


# Inputs and data

Real operating data takes precedence over design estimates throughout the model, and the weight given to a measurement grows with how much of the operating cycle it has observed. This page defines each input and the rules that govern it.

#### Project data

Each project contributes its physical identity: installed capacity `kWp` (DC), commissioning date, design specific production `P_design` (kWh/kWp/day from the engineering study), initial panel efficiency `η_0`, and linear yearly degradation `δ` in absolute efficiency points per year. These define the generation baseline before any measurement exists.

#### Production telemetry

Each validated invoice `i` yields a measured specific production over its billing window:

$$
p\_i = \frac{\text{kWh}\_i}{kWp \cdot \text{days}\_i}
$$

The model takes up to the last twelve billing periods and applies a 20% trimmed mean, discarding at least one observation from each tail from `n ≥ 3`, so a single anomalous month cannot distort the level. The trimmed mean is then blended with the design value using a coverage weight:

$$
w = \frac{\min(n, 12)}{12}, \qquad P\_{used} = w \cdot \overline{p}*{trim} + (1-w) \cdot P*{design}
$$

The weight is billing coverage rather than project age. A sample of three rainy-season months has observed only part of the seasonal cycle no matter how long the asset has operated; with twelve billed months the measurement stands on its own, and a mature project with sparse billing is still blended.

Measurements embed the degradation accumulated when they were taken, on average at the midpoint of the measurement window. With project age `a` in years and window length `w_y = min(n,12)/12`, the year-zero baseline is:

$$
P\_0 = \frac{\overline{p}\_{trim}}{\eta\_0 - \delta \cdot \max(a - w\_y/2,\ 0)}
$$

The engine's efficiency ladder then re-applies degradation year by year, so observed performance anchors the projection without degradation being counted twice.

#### OPEX telemetry

Monthly OPEX uses the same coverage-weighted structure, taking the simple mean of the maintenance charges in up to the last twelve validated invoices and blending it against the project's estimated OPEX:

$$
O\_{used} = w \cdot \overline{O}*{inv} + (1-w) \cdot O*{est}
$$

Two differences from production are worth noting. The OPEX mean is not trimmed, because annual charges such as insurance and land lease bill in specific months and are real costs rather than outliers. And it is exactly because those charges are lumpy that the coverage weight matters: an average over four invoices has probably not seen them yet.

#### Macroeconomic projection sets

Local CPI and PPI inflation, US inflation, the US policy-rate path, and the exchange rate come from versioned projection sets, typically quarterly bank research. Sets are immutable once referenced by a project and currency-checked against it. Indices follow the convention that the rate recorded for year `y` compounds the index into `y+1`. Three extension rules apply:

* Beyond the forecast horizon, rates hold at their last projected values and indices keep compounding.
* The exchange rate beyond the horizon drifts by the projected inflation differential (relative purchasing power parity),

$$
FX\_{y+1} = FX\_y \cdot \frac{1+\pi^{loc}}{1+\pi^{US}}
$$

which keeps the currency path consistent with the inflation assumptions that escalate the cash flows.

* Interior gaps in a series interpolate the exchange rate geometrically between the known points, while rates carry forward, so a sparse series cannot produce artificial real-FX jumps.

#### The contracted price curve (PPA)

The energy price comes from the project's power purchase agreement, entered as points `(y, c_y)` under two conventions:

* **Base-year money.** Every point is expressed in money of the curve's base year `y_b` and escalates to each target year with the project's indexation index `I` (PPI, CPI, or flat):

$$
p\_y = c\_{\langle y \rangle} \cdot \frac{I(y)}{I(y\_b)}
$$

where `c_⟨y⟩` is the most recent point at or before `y`. A contract quoting nominal prices per year is converted to base-year money before entry; loaded as-is, it would be indexed twice.

* **Anchor month.** Contracts whose 12-month price batches run off-calendar (April to March, say) declare an anchor month. A point `(y, c)` then denotes the batch starting that month of year `y`. Each batch is indexed to its own start year, so escalation happens at contract anniversaries, and each calendar year's price is the month-weighted blend of the two batches that overlap it. The [engine](/financial-model/valuation-engine) computes the blend over the exact fraction of the year each row covers.

#### Risk assessment

Each project is scored against a shared risk framework: dimensions `d` such as offtaker quality, regulatory exposure, or technical complexity, each with a weight `b_d` in basis points, scored `s_d ∈ [0, 2]` with 1 as the typical case. The project premium is:

$$
\pi\_{project} = \sum\_d \frac{b\_d \cdot s\_d}{10^4}
$$

`b_d` is the contribution per score point, so a dimension can contribute up to `2 b_d`. The premium feeds the [discount rate](/financial-model/discounting-and-nav).

#### Per-project assumptions

Each project also declares its scalar assumptions, all frozen into every published snapshot: asset lifetime, protocol fee rate, certificate price in USD/MWh, estimated monthly OPEX, an optional real OPEX escalator, indexation base years per curve, the PPA anchor month, and the withholding configuration (invested capital, repayment schedule, and rate).


# The valuation engine

The engine builds one row per calendar year, from the commissioning year to the end of the asset's useful life: `L + 1` rows for a lifetime of `L` years. Quantities within a year are treated as uniformly distributed in time, and partial years are handled through fractional time factors.

#### Time structure

Let `a` be the project age at the valuation date, in years of 365.2425 days, and `y_o` the fraction of the commissioning calendar year that follows the commissioning date. Row `n` carries:

$$
tf\_n = \min\big(\max(y\_o + n - a,\ 0),\ 1\big), \qquad tf\_L = \max\big(0,\ \min(L - a,\ 1 - y\_o)\big)
$$

Rows before the valuation date get `tf = 0` and produce no cash flow, since the valuation is strictly forward-looking. The row containing the valuation date gets the remaining fraction of that year, full years get 1, and the final row covers the head of its calendar year up to the end-of-life anniversary, net of anything already elapsed. The factors sum to the remaining life, `Σ_n tf_n = L - a`, and a valuation dated past end-of-life is rejected.

#### Generation

Panel efficiency follows a yearly degradation ladder. A calendar year straddles two panel-age steps whenever commissioning was mid-year, so row `n ≥ 1` uses the step average of the window it covers:

$$
\eta\_n = \eta\_0 - (n - 1 + y\_o),\delta
$$

with the commissioning row at full initial efficiency. Generation is:

$$
G\_n = P\_0 \cdot 365.2425 \cdot kWp \cdot \eta\_n \cdot tf\_n \cdot (1 - h\_n)
$$

where `P_0` is the year-zero baseline from [telemetry](/financial-model/inputs-and-data) and `h_n` is the expected downtime from any [equipment replacement](/financial-model/equipment-replacement) scheduled that year.

#### Energy revenue

`R^(energy)_n = G_n · p_n`, with `p_n` resolved from the PPA curve: base-year money escalated by the chosen index and, for anchored contracts, blended between the two overlapping 12-month batches. The blend weight is computed over the sub-window of the year the row actually covers, so for the valuation-year row only the remaining tail of the year participates and an expired batch cannot affect the price applied to future cash.

#### Certificates

$$
R^{REC}*n = \left\lfloor \frac{G\_n}{1000} \right\rfloor \cdot c^{REC}*{USD} \cdot \frac{U(y\_n)}{U(y\_{eval})} \cdot FX\_{y\_n}
$$

Certificate revenue counts whole MWh. The price is denominated in USD/MWh, the denomination of the I-REC market, escalates with the US CPI index `U`, and converts at each year's projected exchange rate. A legacy local-currency mode escalating with local CPI remains for projects not yet migrated; under the PPP-consistent FX path the two are close to equivalent in real USD terms.

#### Operating expenses

$$
C^{opex}*n = 12 \cdot O*{used} \cdot \frac{CPI(y\_n)}{CPI(y\_{eval})} \cdot (1 + \delta\_{opex})^{,y\_n - y\_{eval}} \cdot tf\_n
$$

The baseline `O_used` comes from [invoice telemetry](/financial-model/inputs-and-data) and is expressed in valuation-date money, hence the CPI escalation from the valuation year. The optional real escalator `δ_opex` (default 0; industry benchmarks run at CPI +0.5 to 1% for aging assets) captures recurring O\&M outpacing general inflation. Major replacements are excluded from this line; they live in the [discrete-event schedule](/financial-model/equipment-replacement), and the boundary between the two prevents double counting.

#### Protocol fee and additional income

The protocol fee is proportional to gross revenue: `C^(fee)_n = φ · (R^(energy)_n + R^(REC)_n + R^(add)_n)`. Additional income streams, such as tax benefits or ancillary revenues, enter per year in declared base-year money and escalate with CPI from their base.

#### Net cash flow and conversion

$$
F^{LC}\_n = R^{energy}\_n + R^{REC}\_n + R^{add}\_n - C^{opex}\_n - C^{equip}\_n - C^{fee}\_n, \qquad F^{USD}\_n = \frac{F^{LC}*n}{FX*{y\_n}}
$$

Within the forecast horizon `FX` comes directly from the macro set; beyond it, the PPP drift applies. USD-denominated projects skip conversion.

#### The published table

The full year-by-year table ships with every valuation: time factors, efficiency, generation, prices, each revenue and cost line, exchange rates, discount factors, and discounted flows. The discounted column sums to the NPV, so a published NAV can be verified line by line.

#### Warnings

When an input situation weakens a calculation, the engine says so. A truncated FX forecast without US inflation data, insufficient telemetry, or a replacement event falling in the valuation year each produce an explicit warning that travels with the draft and freezes into the published version.


# Equipment replacement

Solar assets do not run 30 years on their original components. Inverters get replaced or refurbished, tracker drives wear out, monitoring electronics become obsolete, and a rooftop array may need to come off and go back up if the roof itself requires work. Folding these costs into a blended percentage of CAPEX loses their timing and their economics, in particular the fact that power electronics get cheaper in real terms while field labor gets more expensive.

The model prices every replacement as a discrete event.

#### Event cost

Each event's ticket in base-year money is:

$$
C = Q \cdot c\_0 \cdot (1+\lambda)(1+\tau)(1+\kappa) \cdot P
$$

| Term  | Meaning                                      | Typical range                                                                                                      |
| ----- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| `Q`   | quantity (kWp, kVA, physical units)          | from design                                                                                                        |
| `c_0` | unit cost in base-year money                 | reference registers below                                                                                          |
| `λ`   | install / logistics / recommissioning uplift | 12–35% by site access                                                                                              |
| `τ`   | import duty + VAT                            | 0 where a renewable-energy import exemption applies (as in the current portfolio); its loss is a downside scenario |
| `κ`   | contingency                                  | 10–15%                                                                                                             |
| `P`   | probability, for uncertain events            | e.g. mid-life transformer at 25%                                                                                   |

#### Dual-currency escalation with a deflation floor

The ticket splits into a USD-denominated hardware share `s` and a local-currency share `1-s` covering installation labor, logistics, and permits (roughly 70/30 for utility-scale, 55/45 for rooftop). Each share escalates with its own index and a component-specific real delta `Δ`:

$$
C(y) = C \cdot s \cdot \frac{U(y)}{U(y\_b)} \cdot \rho\_{usd}(t) \cdot FX\_y ;+; C \cdot (1-s) \cdot \frac{CPI(y)}{CPI(y\_b)} \cdot \rho\_{loc}(t)
$$

where `t = y - y_b` and `ρ(t) = (1+Δ)^t`, floored at 0.6 cumulative for declines. Compounding a 3% real decline for 25 years would price hardware at 47% of today's cost, which supply-chain and commodity floors make implausible, so cumulative real decline is capped at 40%. Typical deltas: inverters and monitoring electronics decline 2 to 3% per year in real terms, copper-heavy gear like transformers runs at CPI or slightly above, and local labor runs 0.5 to 1.5% over CPI.

The USD share converts at the exchange rate of the event's year. Revenue is indexed in local currency while replacement hardware is dollar-denominated, and pricing that mismatch year by year keeps it visible instead of burying it in a blended escalator.

#### Downtime

Every replacement has downtime, and it lands in the same year as the cash outflow. Each event declares a generation haircut `h` (0.3 to 0.8% of annual yield for block-by-block utility swaps, 1 to 2% for a full rooftop shutdown), applied at expected value `P · h` to that year's generation and, through it, to energy revenue, certificates, and the fee.

#### Reference archetypes

The model ships component registers per archetype, instantiated against project capacity and editable per project:

| Archetype                                           | Key events                                                                                                                                                                                                                                                                          | Undiscounted total (≈ % of initial CAPEX) |
| --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------- |
| Utility ≥1 MWp, central inverters + trackers (30 y) | Inverter refurb yr 10, full replacement yr 19; tracker drives yr 15/27; SCADA, metering and security refresh yr 10/20; transformer yr 25 at `P=25%`                                                                                                                                 | \~19%                                     |
| Utility, string inverters + trackers (30 y)         | String replacement yr 13 (full) and yr 25 (partial, 60%); same balance of system                                                                                                                                                                                                    | \~23%                                     |
| Utility, fixed-tilt (30 y)                          | As central, without tracker rows                                                                                                                                                                                                                                                    | \~15%                                     |
| Rooftop self-consumption 50 kWp–1 MWp (20 y)        | Weighted monitoring refresh yr 10 (`P=50%`: half the range rides the inverter's integrated monitoring); bundled inverter replacement yr 11 (protections, connectors and meter included) with 0.8% downtime. No roof R\&R: the asset is handed over to the client at end of contract | \~12%                                     |
| Rooftop self-consumption 30–50 kWp (20 y)           | Simplified register, two events: bundled inverter replacement yr 11 (integrated monitoring included, no standalone datalogger) and a weighted electrical corrective yr 16 at `P=50%`                                                                                                | \~12%                                     |
| Rooftop self-consumption 50 kWp–1 MWp (30 y)        | Two inverter cycles (yr 11 and 22) and two weighted monitoring refreshes (yr 10/20), plus an electrical corrective yr 24 at `P=50%`. No roof R\&R                                                                                                                                   | \~30%                                     |

On 20-year horizons these totals annualize to roughly 0.5 to 0.8% of CAPEX per year; the 30-year rooftop register runs closer to 1% because two full replacement cycles compound three decades of price escalation. Industry experience puts a floor around 0.3% (below it, labor escalation or contingency is usually missing); totals well above these marks usually mean something is being double-counted against O\&M.

#### Timing convention

Events are scheduled by operating year. An event falling in the valuation year is prorated by the remaining year fraction, an expected-value convention that assumes uniform timing within the year. A scheduled event can deviate from that assumption in either direction, so the engine emits a warning whenever a valuation lands in an event year and that NAV gets reviewed.


# Discounting and NAV

The discount rate is the most sensitive parameter in the model: at a 30-year horizon, 100 basis points move the NPV by 7 to 9%. Its construction is set out here component by component.

#### The rate build-up

Each year carries its own nominal USD rate:

$$
r\_y = f\_y + \pi\_{country} + \pi\_{project}
$$

* `f_y` is the projected US policy-rate path from the macro set. Anchoring on the expected path treats the term structure under the expectations hypothesis, with a term premium near zero. This reading is consistent with the main empirical term-premium estimates of the past decade (ACM, Kim-Wright), and the ±100 bps [sensitivity](/financial-model/sensitivity-analysis) quantifies what rides on it.
* `π_country` is the risk premium of the country where the asset operates, maintained per country as a protocol-level catalog.
* `π_project` comes from the scored [risk framework](/financial-model/inputs-and-data): `π_project = Σ_d b_d s_d / 10^4`, with each dimension contributing its basis-point weight per score point.

Cash flows are nominal USD, converted along the PPP-consistent FX path and discounted at nominal USD rates, so currency, inflation, and discounting close consistently.

#### Liquidity and the discount rate

Private infrastructure equity ordinarily carries an illiquidity premium of 100 to 300 bps, which shows up equivalently as the 10 to 30% NAV discounts seen in fund secondaries. The model does not add one: the instrument carrying the exposure is a liquid token with functioning transfer and redemption paths, not a locked-up fund position.

That argument has a boundary worth drawing. Liquidity does not justify discounting long-duration cash flows at short rates. A 30-year Treasury trades in seconds and still yields the 30-year rate, because duration risk travels with the instrument: a holder who sells after rates rise sells at the fallen price. What a liquid instrument removes is the inability to exit, which is the specific risk the illiquidity premium compensates. Against the 9 to 12% USD cost of equity observed for illiquid operating solar in emerging markets, the model's typical all-in rate sits at the lower edge of the range, which is where removing the illiquidity component puts it.

#### Mid-year convention

Solar revenue arrives more or less continuously through monthly billing, so the center of gravity of a year's cash is mid-year rather than December 31. The discount divisor for row `n` compounds prior years in full and the row's own factor by half:

$$
D\_n = \left\[\prod\_{k\<n}(1 + r\_k \cdot tf\_k)\right]\cdot\left(1 + \tfrac{1}{2}, r\_n \cdot tf\_n\right), \qquad NPV = \sum\_n \frac{F^{USD}\_n}{D\_n}
$$

Rates enter scaled by time factors, so the partial valuation-year row discounts to the midpoint of its remaining window and pre-valuation rows are inert. An end-of-year convention would understate every valuation by about `(1+r)^(1/2) - 1 ≈ 4%` at typical rates. Since the NAV governs issuance and redemption, a biased NAV favors one side of every transaction; the convention is chosen to be unbiased rather than conservative.

#### Withholding on distributions

Distributions through the protocol's regulated structure bear withholding at rate `θ` on their gain portion, meaning the distribution minus the scheduled capital repayment under the project's declared curve. The capital shield is cumulative:

$$
S\_n = K \cdot q\_n \cdot tf\_n + carry\_{n-1}, \qquad W\_n = \theta \cdot \max(0,\ F^{USD}\_n - S\_n), \qquad carry\_n = \max(0,\ S\_n - \max(F^{USD}\_n, 0))
$$

with `K` the invested capital and `q_n` the scheduled repayment fraction. The carryforward follows investment contracts that impute distributions to capital until the cumulative schedule is met: scheduled capital unused in a low-cash year, such as an equipment-replacement year, is not forfeited, and negative years pay no tax.

#### From NPV to NAV per pWatt

$$
NAV\_{pWatt} = \frac{\sum\_n \left(F^{USD}\_n - W\_n\right)/D\_n}{1000 \cdot kWp}
$$

The post-withholding NPV divided by the project's pWatt supply, at one pWatt per watt DC. This is the figure the protocol publishes and the Reserve consumes, and every published instance carries the [sensitivity analysis](/financial-model/sensitivity-analysis) that brackets it.


# Sensitivity analysis

A NAV is a point inside a space of uncertainty. Every valuation therefore ships with a tornado analysis: the engine re-runs with one lever perturbed at a time, and the resulting deltas are published next to the base case. The tornado freezes into every published version, each row recording the exact perturbation it applied, so a valuation permanently declares the uncertainty known when it was issued.

The analysis answers three questions: which input moves the NAV most per unit of change (where model risk lives), what the NAV would be under stated alternative conditions, and what severe-but-plausible cases imply for protocol buffers and mechanism design.

#### Directionality

Each lever belongs to one of three types, which determines its justification and whether it runs in one direction or two.

Quantiles test both tails of an observable distribution, at empirically calibrated magnitudes that may come out asymmetric. Parameters test both ends of a defensible disagreement range, symmetric by construction. Scenarios test a discrete event in its single real direction, since a regime change has no meaningful mirror image.

#### Calibration of the quantile levers

**Production.** Monthly specific production across the portfolio (1,394 project-months, 30 projects, validated invoices) shows a pooled relative dispersion of `σ_month ≈ 20%`. Annualizing under bounds for the serial correlation of weather, `σ/√12` if independent and `σ/√6` under moderate autocorrelation, gives `σ_annual ≈ 5.7` to `8.1%`; the model uses 6%. The P90/P10 pair follows as `∓ 1.28σ ≈ ∓ 8%`, recalibrated annually as telemetry accumulates.

**Exchange rate.** FX quantiles are calibrated per portfolio currency against its official exchange-rate series. For the current portfolio (COP), rolling 12-month changes over the full available history (1991–2026, 405 windows) have quantiles `Q_10 = -12.1%`, `Q_50 = +4.8%`, `Q_90 = +24.4%`. The model's PPP path already carries the secular depreciation drift, which sits near the median, so the sensitivity shock is the quantile centered on the median: devaluation +20%, appreciation −17%. The asymmetry is in the data, not assumed: devaluations jump, with crisis episodes reaching +37% in a year, while appreciations crawl.

#### The lever set

| Lever                                 | Type      | Magnitude                                                 | Basis                                                                                     |
| ------------------------------------- | --------- | --------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Production P90 / P10                  | quantile  | −8% / +8%                                                 | Own-portfolio telemetry, `1.28σ`                                                          |
| FX devaluation P90 / appreciation P10 | quantile  | +20% / −17%                                               | Official exchange-rate series of the portfolio currency (COP: 1991–2026), median-centered |
| Discount rate                         | parameter | ±100 bps                                                  | Width of the defensible range on the rate build-up                                        |
| OPEX                                  | parameter | ±20%                                                      | Interim range, to be replaced by backtesting statistics                                   |
| Import tax on replacements            | scenario  | full local VAT + duty (19% + 5% in the current portfolio) | Loss of the renewable-energy import exemption                                             |
| Certificate price                     | scenario  | → 0                                                       | Collapse of the voluntary certificate market                                              |
| Combined adverse / favorable          | scenario  | production ∓8%, rate ±100 bps, OPEX ±20%                  | The three continuous levers stressed jointly, both directions                             |

#### Combined scenarios and the NAV range

The combined rows are full engine runs with all three perturbations applied at once, not sums of individual deltas. Interactions matter: a leaner cash flow bears the inflated OPEX proportionally harder, while a higher rate discounts flows that are already smaller. For a representative project, the individual adverse deltas of −11.2%, −7.4% and −7.8% sum to −26.3%, but the joint run yields −24.8%. Only the full run can say which way the interactions cut.

The pair brackets the NAV in a declared range; the same representative project, with a base NAV of 1.096, brackets to \[0.824, 1.416]. The adverse bound informs buffer sizing, the favorable bound completes the picture for both sides of issuance and redemption. Discrete events stay out of both combinations, since stacking regime changes onto a bad year stops being a stress test, and FX is reported alone because its correlation with the other levers is ambiguous: devaluation episodes in the portfolio's markets tend to coincide with local inflation that the PPA re-indexes.

Symmetric inputs still produce asymmetric outputs. Present value is convex in the discount rate, so −100 bps gains more (+8.5% in the representative case) than +100 bps loses (−7.4%). Publishing both sides makes the convexity visible.

#### What this analysis is not

The tornado is not a confidence interval on the NAV. A joint interval would need a correlation structure across all inputs that no available data supports. Per-lever quantiles, calibrated on observable data and individually checkable, say more than a simulated distribution built on correlations nobody can verify.


# Governance and auditability

The engine is a pure function: the same inputs produce the same valuation, with no hidden state, randomness, or manual adjustment. Everything in this page builds on that property, because it makes a strong guarantee possible: any published valuation can be recomputed exactly, from its own stored inputs, by anyone, at any time.

#### Published versions

A valuation becomes official by being published as a numbered version. Publication freezes:

* the complete input snapshot: every number the engine consumed, including project data, telemetry series, macro projections, price curve points, risk scores, scalar assumptions, and the equipment event schedule;
* the full year-by-year table, intermediate columns included;
* the sensitivity tornado as calibrated at that moment, each row carrying the perturbation magnitudes it applied;
* any engine warnings active at publication;
* the publisher's identity and timestamp.

Published versions are never edited or deleted. Corrections happen by publishing a new version.

#### Self-describing snapshots

Snapshots carry a schema version, incremented with every change to the snapshot format and documented against its predecessor. Because sensitivity rows embed their own applied magnitudes, annual recalibrations do not orphan history: a version published under an earlier calibration still states exactly what it used. Interpreting an old valuation takes the snapshot and this documentation, nothing else.

The engine's arithmetic is protected the same way. A golden-master regression pins a complete reference valuation, every intermediate column included, inside a suite of over 1,500 automated tests. An unintended change to the arithmetic fails the build; an intended methodology change re-pins the golden master with the value delta recorded in the fixture's changelog. The result is a running, quantified history of how the model's output has evolved and why, which is the concrete mechanism behind the rule that methodology improves over time while published valuations stay put.

#### The active version and rollback

Exactly one published version per project is active at a time; it is the one token holders and the Reserve consume. Publication normally activates the new version, but a version can be staged without activating it, and the pointer can be rolled back to a previous version if a problem is found. Every pointer movement lands in an append-only activation log with author, timestamp, and reason. The consumed NAV changes only by moving a pointer between immutable objects.

#### Drafts and diffs

Before publication, the draft valuation recomputes live against current data, and the interface diffs the draft's inputs against the active version: which assumptions changed, which telemetry moved. A publisher sees why the number changed before freezing it. Engine warnings surface in the draft and freeze with the version, so data-quality caveats stay attached to the number they qualify.

#### Recalibration

The empirical calibrations behind the [sensitivity analysis](/financial-model/sensitivity-analysis), production variability from portfolio telemetry and FX quantiles from the official exchange-rate series, are refreshed annually with computation dates and sources on record. As operating history grows, backtesting of modeled against realized generation and OPEX, per project and per year, will replace the interim benchmark ranges with the protocol's own measured forecast errors.


# Assumptions and limitations

This page states what the model assumes, what it simplifies, and what is on its roadmap.

#### Assumptions

* **One central projection.** The model produces a single deterministic path, a central estimate anchored to measured data, with uncertainty carried by the calibrated [sensitivity analysis](/financial-model/sensitivity-analysis) rather than by probabilistic simulation. Per-lever quantiles can be checked individually; a joint simulation would rest on correlation assumptions the available data cannot support.
* **Scope.** The model values the cash flows that reach the investor through the protocol's structure, net of the protocol fee and of the withholding that applies along the distribution path.
* **Certificate prices hold their real USD value.** Certificate markets have their own supply and demand dynamics; the sensitivity set includes a complete collapse of the certificate price.
* **Recurring OPEX escalates at CPI by default.** The optional real escalator (industry benchmarks run at CPI +0.5 to 1% for aging assets) is applied per project where justified. Major replacements are modeled separately as [discrete events](/financial-model/equipment-replacement), with the boundary drawn so the two cannot double-count.
* **The import-tax exemption holds in the base case.** Equipment costs assume the renewable-energy import exemption of the asset's jurisdiction; its loss, at that jurisdiction's full VAT and duty rates, is a standing sensitivity scenario.
* **No terminal value.** The asset carries no value beyond its declared useful life, positive or negative, except where a contractual salvage credit is scheduled in the equipment register. End-of-life economics are an active area of refinement as contractual evidence accumulates.
* **Expected-value event timing.** A replacement scheduled in the valuation year is prorated by the remaining year fraction, with an engine warning for manual review, since a scheduled event near year-end is closer to a full pending liability than to its prorated fraction.

#### Limitations

* **Young-portfolio calibration.** Production variability is estimated from about four years of portfolio telemetry: enough for a first empirical quantile, not for full climate-cycle coverage, since an ENSO cycle spans several years and La Niña years cluster low-irradiance outcomes. The OPEX ±20% range is an interim benchmark pending backtesting history.
* **Seasonality in short samples.** Coverage weighting bounds the influence of partial-year samples but does not deseasonalize them against a site-specific irradiance profile, so a short sample keeps its seasonal bias within its reduced weight.
* **Availability is embedded.** Measured production already contains real downtime and soiling, and projected years inherit whatever availability the history embeds. There is no separate forward-looking availability parameter.
* **Annual granularity.** Intra-year working-capital timing, payment lags, and settlement mechanics are below the model's resolution.
* **Term-premium stance.** Anchoring the discount rate on the expected policy-rate path puts the term premium near zero, a reading supported by recent empirical estimates but a stance nonetheless. The ±100 bps sensitivity bounds its consequence.

#### Roadmap

In order of expected impact:

1. **Backtesting**: yearly reconciliation of modeled against realized generation and OPEX per project, with stored forecast errors, progressively replacing interim ranges with measured accuracy.
2. **Site-specific seasonal profiles** for deseasonalizing short telemetry samples.
3. **Explicit terminal-value treatment**, whether salvage, repowering optionality, or decommissioning liability, as contractual evidence accumulates.
4. **Continuous recalibration** of the production and FX quantiles as portfolio history and market data grow.

Any published valuation can be placed, through its frozen snapshot and this page's version history, within the exact vintage of the methodology that produced it.


# Suno communities

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Twitter (X)</strong></td><td>The latest from Suno, one post at a time</td><td><a href="https://3441843488-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0mAdAaPJz7EXU4NB6Mq1%2Fuploads%2Fgit-blob-041707a8af1966ad615d4f3340c2fc9f5b3a25c8%2FX_logo.jpg?alt=media">X_logo.jpg</a></td><td><a href="https://x.com/unergyio">https://x.com/unergyio</a></td></tr><tr><td><strong>Discord</strong></td><td>Real-time prices, marketplace alerts, and direct access to the Suno team.</td><td><a href="https://3441843488-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0mAdAaPJz7EXU4NB6Mq1%2Fuploads%2Fgit-blob-cdde192316dfc12c5d17b0575a179988df633f9c%2Fdiscord.avif?alt=media">discord.avif</a></td><td><a href="https://discord.gg/jTNQHqaauZ">https://discord.gg/jTNQHqaauZ</a></td></tr><tr><td><strong>LinkedIn</strong></td><td>Stay informed on our growth, partnerships, and impact.</td><td><a href="https://3441843488-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0mAdAaPJz7EXU4NB6Mq1%2Fuploads%2Fgit-blob-8c25e41cc43edf6c280ca67692f2dfe8143950eb%2Flinkedin.png?alt=media">linkedin.png</a></td><td><a href="https://www.linkedin.com/company/suno-finance/">https://www.linkedin.com/company/suno-finance/</a></td></tr></tbody></table>


# Cross-chain availability

Everything that defines the protocol (the desk, the Reserve, staking, the yield split) lives on one home chain. Availability on other networks is distribution: a mirror of the staked asset, designed so that everything that crosses is either locked collateral or a price computed at home.

## What travels: the staked share

The canonical cross-chain asset is **c-uWatt**, the staked share rather than raw uWatt, because the staked share is the self-contained form of the asset. Its value already compounds the yield, so it needs no vault, no distribution mechanism, and no desk on the destination network; it is a single number that grows. Raw uWatt stays home, where the desk enforces its pricing.

The transport is conservative:

* **A 1:1 lockbox.** Every share that circulates on a secondary network is matched by a share locked in the protocol's lockbox on the home chain. Burning the mirror releases the original, so every unit in circulation elsewhere has a locked counterpart at home.
* **A single transport in v1.** One audited interoperability layer carries the messages, with per-bridge mint and burn rate limits capping how fast any transport failure could propagate. One transport trades redundancy for a single dependency to audit and operate. If it halts, bridged transfers pause while the canonical shares remain locked and safe on the home chain. Additional transports can be added by governance later.

## The price mirror

Secondary-network liquidity pools need a reference price for c-uWatt. That number is composed on the home chain, the desk's capped uWatt price multiplied by the vault's share price:

$$
\text{c-uWatt mark} = \min($1,\ C) \times \text{(uWatt per share)}
$$

A keeper carries it across, and only carries it: every input to the number is computed at home. The cap on the uWatt leg matters because pricing the share off the raw collateral ratio would let the buffer, which reaches stakers only through the yield mechanism, be sold into secondary pools, and would count the same surplus twice. The mirrored mark is what the home desk would pay. Below par the cap is inactive, so impairment passes through at full weight.

The receiving oracle treats its own keeper as a potential adversary. Three independent on-chain guards bound what any single update can do (a minimum interval between updates, a cumulative deviation band around a rolling anchor, and absolute price bounds), and a dual staleness circuit breaker halts consumption if either the pushes stop or the underlying home-chain inputs age out. A compromised keeper key can therefore delay the mirror, but cannot teleport its price.