> 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/risk-management.md). # Gestión de riesgo Riesgo a nivel de activos y de protocolo, las reglas de ingeniería que contienen las fallas y qué verifican terceros independientes. El riesgo del protocolo vive en dos altitudes. Bajo la línea de flotación están los activos: infraestructura real, en mercados reales, con clima, contrapartes y equipos. Encima está el protocolo: el código y el proceso que convierten esos activos en un token redimible. Gestionar lo primero es trabajo de portafolio; gestionar lo segundo es ingeniería. Esta página cubre ambos, en ese orden, y cierra con lo que verifican terceros distintos de Suno. ## Riesgo a nivel de activos El retorno de la Reserva lo generan proyectos físicos, y cada una de las formas en que un proyecto puede quedarse corto tiene un dueño con nombre dentro del proceso: * **Riesgo de producción.** La generación solar varía con el clima y se degrada con la edad. Los proyectos se suscriben sobre telemetría medida y no sobre promesas de placa, los supuestos de producción mezclan historia real con valores de diseño, y el [análisis de sensibilidad](/es/financial-model/sensitivity-analysis.md) publicado con cada valuación cuantifica el impacto de déficits de producción calibrados con la propia historia operativa del portafolio. * **Riesgo de ingresos.** La electricidad se vende bajo contratos de largo plazo y tarifas reguladas, la mayoría indexados a medidas de inflación. Los compradores de energía pasan evaluación de crédito en la originación; los contratos llevan cláusulas de penalidad y terminación; la mora acumula intereses. * **Riesgo de costos y equipos.** Cada valuación carga un calendario explícito de reposiciones futuras de equipos (probabilístico, ajustado por escalación, con contingencias) en lugar de una provisión plana de mantenimiento. Las plantas operan bajo contratos de O\&M preventivo y correctivo y seguros apropiados a cada sitio. * **Riesgo cambiario y macro.** Los proyectos ganan en monedas locales contra un token denominado en USD. Las valuaciones proyectan los tipos de cambio desde supuestos macro explícitos, y el conjunto de sensibilidad incluye escenarios de devaluación calibrados con la historia propia de la moneda en cuestión. * **Riesgo de concentración.** Un portafolio joven es el más expuesto a cualquier activo, geografía o tecnología individual. El buffer de sobrecolateralización está dimensionado contra este caso, un shock declarado sobre la concentración máxima en energía, y la trayectoria es que la diversificación y el buffer intercambien lugares gradualmente: más proyectos, más mercados, más tecnologías de energía y estructuras de compra, con los diales de concentración ajustándose a medida que crece el número de activos. El filtro de originación importa tanto como la gestión: el mismo modelo de valuación que precia la Reserva decide qué entra a ella. Un proyecto cuya economía ajustada por riesgo no supera la prueba de viabilidad del swap descrita en [El pWatt](/es/protocol/the-pwatt.md) no se origina. ## Riesgo a nivel de protocolo La ingeniería sigue un puñado de reglas aplicadas en todas partes. **Cerrar en falla.** Todo contrato que consume un precio o un reporte de reservas verifica su frescura y revierte si está vencido. No hay ruta de código en la que el protocolo opere sobre un número que nadie respalda. Las propias ventanas de vencimiento están acotadas por rango, así que ninguna transacción individual puede ensanchar una compuerta hasta el infinito sin hacer ruido. **Acotar cada escritura.** Los reportes de reservas de rutina se mueven como máximo una banda estrecha por reporte; las correcciones mayores exigen una acción de gobernanza acompañada de una pausa. La configuración de riesgo se escribe atómicamente como un todo y se rechaza si es internamente inconsistente. Las actualizaciones de oráculos en redes secundarias pasan tres guardas independientes. **Contener cada falla.** La autoridad de minteo está topada por contrato. El suministro puenteado está limitado en tasa por transporte. La cola de redención mide las salidas a un ritmo diario. **Vigilar lo que el código no puede rechazar.** Las guardas on-chain revierten transacciones, pero algunas brechas llegan sin una: una revaluación que empuja la concentración en energía sobre su techo, o una ola de redenciones que adelgaza el tramo de liquidez. Un monitor de reconciliación independiente recomputa continuamente la contabilidad del protocolo contra el estado on-chain: conservación de valor, recomputación de oráculos, custodia contra saldos implicados por eventos, deriva de postura, niveles de liquidez. Sus chequeos más críticos tienen un poder de una sola vía: pueden pausar la emisión, y nada más. Las alertas que un externo podría disparar a propósito, por ejemplo redimiendo lo suficiente para adelgazar el tramo de liquidez, se mantienen como advertencia solamente, para que nadie pueda convertir el sistema de seguridad en un arma de denegación de servicio. **Bajo deterioro, las pérdidas se comparten.** Si la Reserva llega a caer por debajo del suministro, el desk precia ambas direcciones al valor deteriorado `C`: cada salida asume el mismo recorte pro-rata y llegar primero no sirve de nada. La ventana de recapitalización (mintear bajo la par, que agrega respaldo y suministro en la proporción que deja `C` sin cambio) permite que capital externo restaure el protocolo a ese mismo valor, con el rescatista compensado únicamente por la recuperación. La ventana está acotada por un piso de gobernanza y sale cerrada: al lanzamiento el desk opera solo a la par. Abrirla después es una sola transacción de gobernanza on-chain; recuperarse de una apertura prematura no lo es, porque un minteo bajo la par vale lo que valga el reporte de reservas detrás y los tokens ya minteados no se pueden deshacer. ## Aseguramiento externo Tres verificaciones corren por vías separadas del equipo que opera el protocolo: los contratos inteligentes, listados en [Designaciones vigentes](/es/legal/current-designations.md), pasan por auditoría de seguridad independiente, resumida en [Auditoría de seguridad](/es/protocol/security-audits.md); la correspondencia entre el valor reportado on-chain de la Reserva y sus tenencias reales la verifica de forma continua un atestador independiente de prueba de reservas; y la metodología de valuación está publicada completa (modelo, insumos, sensibilidad, snapshots versionados) en [El Modelo Financiero](/es/financial-model/overview.md), de modo que el número del que depende todo lo demás puede recomputarlo cualquiera. --- # 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/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.