> 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/governance-and-parameters.md). # Gobernanza y parámetros Quién puede hacer qué, qué no puede hacer la gobernanza y el valor de lanzamiento de cada parámetro del protocolo. Esta página dice sin rodeos quién puede hacer qué. El protocolo no tiene votación de tenedores de tokens. La autoridad está en roles con alcances estrechos, los sensibles detrás de una multisig y un timelock, y cada ejercicio de autoridad es un evento on-chain que cualquiera puede auditar. Lo que sí tienen los tenedores es contractual y no on-chain: los Términos y Condiciones exigen su consentimiento explícito para cualquier cambio que altere de fondo los tokens, y permiten a los tenedores de más de la mitad de una emisión instruir colectivamente a Suno sobre los remedios si Suno incumple. Esos derechos están descritos en [Estructura legal](/es/legal/legal-structure.md). ## El modelo de autoridad La autoridad se divide en dos niveles según su temperatura: * Las **llaves operativas** corren el ciclo diario del protocolo, y cada una hace exactamente un trabajo: el *atestador* escribe el reporte semanal de reservas (dentro de su banda por reporte); el *pagador de energía* enruta los pagos de ingresos hacia el reparto de rendimiento; el *keeper* empuja el espejo de precio hacia las redes secundarias; el *monitor* tiene un solo poder de una vía, pausar la emisión. Ninguna de estas llaves puede mintear libremente, repreciar la reserva fuera de su banda, cambiar configuración ni actualizar código. * Las **llaves de gobernanza**, en poder de una multisig y con las actualizaciones además detrás de un timelock, fijan la configuración de riesgo, administran roles, ejecutan operaciones de tesorería y autorizan actualizaciones de contratos. El timelock hace que la acción más poderosa, cambiar el código mismo, sea públicamente visible antes de surtir efecto. Las llaves calientes con radio de daño estrecho hacen el trabajo frecuente; las llaves frías y lentas hacen el trabajo raro y peligroso. ## Qué no puede hacer la gobernanza Varias restricciones atan a los propios administradores, en código: * **El precio del desk no es un parámetro.** Ningún rol puede mintear por encima de `min($1, C)` ni redimir por debajo. La ley de precios es estructural. * **El rendimiento no puede correr más rápido que el ingreso.** Una distribución nunca puede mintear más que el pago que la fondeó, y no puede mintear nada mientras el protocolo esté en la par o debajo. * **La configuración de riesgo debe ser autoconsistente.** Los cinco diales de riesgo se escriben atómicamente, cada uno dentro de un rango acotado, y la escritura revierte a menos que se cumpla la regla de dimensionamiento `C* ≥ 1 / (1 − shock de diseño × techo de energía)`: la gobernanza puede mover su apetito de riesgo, pero no puede declarar uno y configurar otro. * **Los diales de las propias guardas están acotados.** Las ventanas de vencimiento y las bandas de movimiento solo aceptan valores dentro de rangos fijos, y cada cambio emite un evento. Ensanchar un margen de seguridad es posible; deshabilitarlo en silencio no. * **Los reportes de reservas van por banda.** Ni siquiera la vía de atestación puede repreciar el sistema de un solo golpe; las correcciones más allá de la banda exigen una acción de gobernanza acompañada de una pausa. ## Parámetros El comportamiento del protocolo lo fija un número pequeño de diales. Los valores de abajo son la configuración de lanzamiento. Cada uno es ajustable por gobernanza dentro de su rango acotado, se espera que evolucione con el portafolio (una Reserva joven y concentrada amerita otros valores que una diversificada y madura), y cada cambio queda registrado on-chain. | Parámetro | Qué fija | Al lanzamiento | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------ | | Objetivo de colateralización `C*` | El nivel de sobrecolateralización al que revierte el reparto de rendimiento | 1.15 | | Piso de recapitalización | El `C` más bajo al que el minteo bajo par sigue abierto; en 1.0 el desk opera solo a la par | 1.0 (ventana cerrada) | | Techo de concentración en energía | Porción máxima de la Reserva en activos de energía que las adquisiciones no pueden cruzar | dial; \~70/30 energía-a-líquido es el objetivo de composición de trabajo | | Piso líquido | Tramo de liquidez mínimo que las salidas de operadores deben preservar | dial, emparejado con el anterior | | Shock de diseño | La revaluación combinada declarada que la postura debe absorber, el insumo de la regla de dimensionamiento | 10% | | Comisión de redención | Cobrada a la salida; estrictamente mayor que la banda de reporte para que montarse sobre un reporte no dé ganancia | 0.5% | | Límite diario de redención | El ritmo de la cola que convierte un pico de redenciones en una secuencia ordenada | 1% del suministro por día | | Arranque del rendimiento | El ratio de colateralización en el que se encienden las distribuciones a stakers | la par | | Ventana de vesting de recompensas | El período sobre el que cada distribución se libera a los stakers | 30 días | | Cadencia y banda de atestación | Cada cuánto se reporta el valor de la reserva y el movimiento máximo de rutina por reporte | semanal · 0.3% | | Precio de swap `P` | El precio de reconocimiento por proyecto que divide la valorización entre inversionistas y buffer | se fija por proyecto | ## Verificabilidad Las afirmaciones del protocolo son verificables. Los contratos son públicos, y sus direcciones están en [Designaciones vigentes](/es/legal/current-designations.md); la configuración se puede leer on-chain en cualquier momento; cada cambio de parámetro, reporte, pausa y actualización emite un evento; las valuaciones se publican con snapshots inmutables y versionados bajo una metodología documentada; y la correspondencia de la reserva con tenencias reales la atesta un tercero independiente. Donde una garantía la impone el código, estas páginas lo dicen; y donde descansa en la gestión o en la práctica de custodia, también lo dicen. --- # 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/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.