> 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/es/protocol/protocol-overview.md).

# Visión general del protocolo

El circuito completo del valor y los dos compromisos a los que sirve cada mecanismo.

El protocolo es un circuito. El valor se mueve en una dirección, del capital a la construcción y de ahí a un portafolio en producción, y los retornos se mueven de vuelta en la otra. Todo lo que sigue en estas páginas es un componente de este circuito.

```mermaid
flowchart LR
    I["Inversionistas"] -- "financian la construcción" --> P["pWatt<br/>(un token por proyecto)"]
    P -- "swap total al entrar<br/>en operación comercial" --> R["La Reserva<br/>activos de energía + tramo de liquidez"]
    D["Desk<br/>minteo / redención"] --- R
    H["Tenedores de uWatt"] <--> D
    R -- "ingresos de energía<br/>(pagos en stablecoins)" --> Y["Reparto del rendimiento"]
    Y -- "distribuido" --> S["Stakers<br/>(c-uWatt)"]
    Y -- "retenido" --> R
```

Leyéndolo de izquierda a derecha:

1. **Financiación.** Un proyecto solar nuevo se tokeniza como su propio pWatt y se vende a inversionistas. Lo recaudado construye la planta. Durante esta fase el pWatt es el único derecho sobre el proyecto.
2. **Entrada a la Reserva.** Cuando el proyecto alcanza la operación comercial (sus primeros ingresos confirman que el activo funciona), la totalidad del suministro de pWatts se intercambia por uWatt recién minteado. El valor tasado del proyecto se contabiliza en la Reserva en la misma transacción, así que respaldo y suministro se mueven juntos. De ahí en adelante nadie conserva exposición a un proyecto individual: el activo pertenece al portafolio y sus antiguos financiadores tienen uWatt.
3. **Tenencia y redención.** El uWatt se mintea y se redime directamente contra el desk del protocolo. El desk cotiza un solo precio para ambas direcciones, y ese precio está topado en $1.
4. **Rendimiento.** Las ventas de electricidad llegan como pagos en stablecoins. Cada pago se reparte: una porción se retiene en la Reserva para mantener su buffer y el resto se distribuye a los stakers de uWatt a través de una bóveda de acumulación.

## Los dos compromisos

Cada mecanismo del protocolo sirve a uno de dos compromisos estructurales.

### Un solo precio, con tope en $1

Minteo y redención precian ambos a

$$
\text{precio del desk} = \min($1,\ C), \qquad C = \frac{\text{valor de la Reserva}}{\text{suministro de uWatt}}
$$

donde `C` es el ratio de colateralización: dólares de respaldo medido por token. Mientras la Reserva cubre el suministro (`C ≥ 1`), el precio es $1 en ambos lados: quien entra no puede comprar por un dólar un token respaldado por más de un dólar y llevarse la diferencia, y quien redime no puede drenar el buffer a la salida. Si el respaldo llega a caer por debajo del suministro, la misma fórmula precia ambos lados a `C`: las pérdidas se reparten pro-rata entre quienes deciden salir, y no hay premio por redimir primero, lo que elimina el incentivo clásico a la corrida.

### La Reserva tiene más de lo que debe

El protocolo apunta a un ratio de colateralización mayor que uno: activos adicionales más allá del valor de todos los uWatt en circulación. Los activos de energía se revalúan a medida que se mueven los datos de producción, los precios y las tasas de descuento, y esas revaluaciones caen sobre el buffer antes de poder tocar a los tenedores. El tamaño del ratio objetivo se dimensiona contra un shock declarado sobre la concentración de energía del portafolio, y dos flujos lo mantienen fondeado: parte de la valorización de cada proyecto se retiene cuando entra a la Reserva, y parte de cada pago de ingresos se retiene antes de pagar rendimiento. Cómo se dimensiona y se reconstruye el buffer está en [La Reserva](/es/protocol/the-reserve.md) y [Rendimiento y staking](/es/protocol/yield-and-staking.md).

## Quién hace qué

El protocolo es un híbrido de código y gestión, y esta documentación mantiene esa frontera explícita.

* Los **contratos inteligentes** imponen el precio, la emisión, la redención, el reparto del rendimiento, el staking y el transporte cross-chain. Ningún operador puede mintear por encima del precio topado, pagar un rendimiento que el reporte de reservas no sustente, ni mover la configuración de riesgo fuera de sus rangos acotados.
* **Suno**, como originador y operador, selecciona y desarrolla los proyectos, los opera, gestiona la composición de la Reserva y ejecuta adquisiciones y ventas: decisiones que el código acota pero no toma. Su papel legal es el de Director del Protocolo, descrito en [Estructura legal](/es/legal/legal-structure.md).
* Los **terceros independientes** cierran el circuito entre los dos: el valor de cada proyecto sale de un modelo de valuación publicado con snapshots inmutables y versionados, las tenencias de la Reserva las verifica un atestador externo de prueba de reservas, y el valor atestado se escribe on-chain a través de un reporter cuyo movimiento por reporte está acotado. El desk consume únicamente ese número atestado, así que cada precio que el protocolo cotiza se remonta a un valor que alguien firmó.

Las páginas que siguen toman cada componente por turno, empezando por el activo.


---

# 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/es/protocol/protocol-overview.md?ask=<question>&goal=<endgoal>
```

`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.