> 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 How asset, valuation, liquidity, and administrative risks reach holders, and what each control can and cannot contain. Suno manages risk through a shared collateral buffer, a liquid allocation, transaction limits, and verification of the assets entering the Reserve. Each addresses a different part of the relationship between physical infrastructure and transferable tokens. This chapter explains those protections, their dependencies, and the exposures that remain. ## Project performance Solar production depends on weather, equipment condition, site access, and operating quality. Revenue also depends on tariffs, contract terms, and whether the offtaker pays. A plant can generate the expected electricity while collecting less cash than forecast. The valuation model uses measured production where available, explicit operating costs, equipment-replacement schedules, and project risk assumptions. Its [sensitivity analysis](/financial-model/sensitivity-analysis.md) shows how selected changes affect NAV. Insurance coverage and maintenance obligations are specific to each project and its agreements. Local-currency income introduces another source of variation against USD-denominated uWatt. Inflation-linked contracts can offset some changes, but the timing and size of currency moves can still reduce dollar cash flows. Diversification can reduce dependence on one project or counterparty. It offers less protection against shared exposures such as regional weather, regulation, exchange rates, or common service providers. The on-chain energy ceiling limits an asset class, not each country, offtaker, or individual project. ## Valuation and reporting The protocol can execute exactly as written and still use an inaccurate asset value. Discount rates, remaining useful life, future costs, and enforceable revenue rights all affect backing. A reproducible calculation establishes how a value was derived, not whether every input is correct. Freshness gates stop price-sensitive operations when data is too old. Aggregate-report bands limit individual routine updates. Neither proves accuracy: small reports can accumulate, per-project prices are not movement-banded, and administrators have an unbanded aggregate path. Reserve reconciliation must compare reported value with actual pWatt holdings and valuation versions, account for cash collections, and resolve pending instrument settlements. A timely report without that work can still overstate or understate backing. ## Liquidity and impairment The liquid allocation funds the [desk](/protocol/the-uwatt.md), while treasury-deployment limits preserve capacity for exits and daily limits pace outflows. Redemption requires transferable USDC, fresh inputs, and permitted execution. Available capacity can still fall short of demand even while recorded backing exceeds supply. The daily limit is a rate limit, not a queue with a guaranteed place or payout date. The liquidity floor constrains specified treasury actions; it does not stop holder redemptions from drawing down liquid assets. Supported instruments also depend on external exit routes. If NAV falls below $1, the reference price recognizes the impairment. The payout guard limits sudden upward recovery quotes. These rules reduce specific extraction opportunities; they do not eliminate runs, changing valuations, or the advantage of obtaining scarce liquidity sooner. Cash minting below par is optional and closed by the initializer's floor. Opening it can attract new cash at the impaired reference price, but proportional issuance alone does not restore the collateral ratio. A smaller supply may increase rewards per remaining staked token if revenue and other conditions hold. There is no guarantee that this will attract deposits or replenish the desk. ## Contract, custody, and administrative risk Software defects can affect accounting, minting, transfers, or exits. The [independent security review](/protocol/security-audits.md) tested the specified contract version and resulted in fixes and one mitigated finding. It does not insure assets or exclude undiscovered vulnerabilities. Per-minter allowances contain issuance by a given authorized contract. Price checks, atomic settlement, and concentration limits restrict particular operations. Administrators can change configuration, grant authority, or upgrade code, so key security and governance remain part of the safety model. Custody is another boundary. User wallets can be self-custodied while Reserve assets remain under a managed custody arrangement. A contract's withdrawal check is not a universal restriction on every action custody signers can authorize. USDC, Sky instruments, blockchain networks, and [cross-chain transport](/protocol/cross-chain.md) introduce external dependencies. Their failures need not coincide with poor solar performance. ## Monitoring and response The issuer and Reserve expose one-way pause functions for a monitor role. A monitor granted that role can stop configured operations after detecting an inconsistency; separate authority is needed to resume. The principal monitoring signals are Reserve-accounting discrepancies, unexpected minting, oracle disagreement, stale reports, liquidity depletion, and drift from the declared risk posture. The monitor role supplies the pause authority; detection and incident response depend on the service and personnel operating it. Pausing limits further activity while an incident is investigated. It can also prevent legitimate holders from transacting. Recovery may require corrected reports, restored liquidity, changed permissions, or an upgrade; there is no universal on-chain recovery deadline. ## Holder exposure The [legal risk disclosures](/legal/risk-disclosures.md) describe the contractual allocation of these risks, including possible total loss, conditional redemption, subordination, and limited recourse. A holder should evaluate both the technical controls and the rights available if those controls or the underlying assets fail. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` 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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.