> 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-uwatt.md). # The uWatt How the desk prices minting and redemption at min($1, C), pays redemptions from the liquidity sleeve, and what the $1 covers. 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 desk uWatt is created and destroyed at a single venue: the protocol's desk. A user deposits stablecoins and receives uWatt; a holder returns uWatt and receives stablecoins. Both sides are normally open. The mint side, which the legal documents call the Deposit Window, may be suspended when the liquidity sleeve approaches its target share of the Reserve, since every mint adds to the sleeve; suspension and reopening are announced on the platform, and the conditions are in the [uWatt offering document](/legal/uwatt-offering-document.md). 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.md), 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 (capped at 0.5%, and set at the cap 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.md). ## Redemption liquidity The desk pays redemptions from the Reserve's liquidity 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 liquidity 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.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-uwatt.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.