> 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/risk-management.md). # Risk management Asset-level and protocol-level risk, the engineering rules that contain failures, and what independent parties verify. 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.md) 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.md) 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 liquidity 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, listed in [Current designations](/legal/current-designations.md), undergo independent security audit, summarized on [Security audit](/protocol/security-audits.md); 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.md), so the one number everything depends on can be recomputed by anyone. --- # 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/risk-management.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.