> 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/governance-and-parameters.md). # Governance and parameters Who can do what, what governance cannot do, and the launch value of every protocol parameter. 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. What holders do have is contractual rather than on-chain: the Terms and Conditions require their explicit consent for any change that would fundamentally alter the tokens, and let holders of more than half of an issuance instruct Suno collectively on remedies if Suno defaults. Those rights are described in [Legal structure](/legal/legal-structure.md). ## 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 / (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 liquidity 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, and their addresses are listed in [Current designations](/legal/current-designations.md); 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. --- # 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/governance-and-parameters.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.