> For the complete documentation index, see [llms.txt](https://docs.suno.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.suno.finance/protocol/the-reserve.md). # The Reserve The protocol's balance sheet: composition, why it is over-collateralized, where its numbers come from, and how it is managed. 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 a liquidity sleeve that makes 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. * **The liquidity sleeve.** Stablecoins and tokenized short-duration instruments (treasury-backed savings instruments in the current configuration); the legal documents call these Treasury Assets and Permitted Stablecoins. The sleeve earns a modest baseline return, and its 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% liquidity sleeve**. 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 liquidity sleeve, which operator transactions cannot cross. Acquisitions that would over-concentrate the portfolio revert; treasury movements that would drain the sleeve below its floor revert. The dials themselves are bounded and every change is recorded on-chain; see [Governance and parameters](/protocol/governance-and-parameters.md). 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.md). ## 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 \frac{1}{1 - \text{design shock} \times \text{energy concentration ceiling}} $$ The form follows from requiring the Reserve to still cover the supply after the declared shock hits the largest energy share the ceiling allows; the ceiling is a share of the Reserve rather than of the supply, so the loss it can produce scales with the ratio itself. A posture that declares a 10% shock tolerance on an 80% energy ceiling cannot set a target below about 1.09; the working target sits above that line with margin: 1.15 at launch. The rule took this form after the independent [security review](/protocol/security-audits.md). 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.md)). And when energy revenue arrives, part of each payment is retained rather than distributed ([Yield and staking](/protocol/yield-and-staking.md)), 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.md). 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 sleeve balances 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.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.suno.finance/protocol/the-reserve.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.