# Traducción al español de la Constitución del Ecosistema Cardano **URL:** \ **Category:** Educación\ **Created:** [1 August 2026 08:25 UTC](https://forum.cardano.org/t/traduccion-al-espanol-de-la-constitucion-del-ecosistema-cardano/156049 "2026-08-01T08:25:24Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Rodrigoi](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/rodrigoi/32/23640_2.png) [@Rodrigoi](https://forum.cardano.org/u/Rodrigoi)\ **Post date:** [1 August 2026 08:25 UTC](https://forum.cardano.org/t/traduccion-al-espanol-de-la-constitucion-del-ecosistema-cardano/156049/1 "2026-08-01T08:25:24Z")
Comparto una traducción al castellano de la **Cardano Blockchain Ecosystem Constitution** , vigente desde la época 609. La traducción fue realizada con asistencia de inteligencia artificial mediante **Google Gemini**. Mi objetivo es facilitar el acceso al documento para la comunidad hispanohablante, no crear una versión oficial ni realizar una interpretación jurídica del texto. Aunque revisaré el contenido para detectar errores evidentes, pueden existir imprecisiones, diferencias terminológicas o matices perdidos durante la traducción. En caso de duda o discrepancia, debe considerarse siempre como referencia el documento original en inglés. Las correcciones, observaciones y sugerencias de la comunidad son bienvenidas. # **CONSTITUCIÓN DEL ECOSISTEMA DE LA BLOCKCHAIN DE CARDANO** ## **PREÁMBULO** Cardano es un ecosistema descentralizado de tecnología blockchain, contratos inteligentes y gobernanza comunitaria, comprometido con la mejora de los sistemas económicos, políticos y sociales para todas las personas, en todas partes. Al ofrecer esta infraestructura fundamental, Cardano empodera a las personas y a las comunidades para que gestionen su identidad, valor y gobernanza, fomentando el surgimiento de aplicaciones descentralizadas, empresas y estados red. A través del procesamiento imparcial de datos inmutables, nosotros, los participantes de la Comunidad de Cardano, conformada por individuos, organizaciones, contribuyentes y otros, elegimos seguir los pasos de los pioneros de Internet y de las criptomonedas, quienes forjaron por primera vez los lazos de comunidad a través de tecnologías digitales. Nos guían nuestros principios y dogmas compartidos mientras ejercemos nuestro autogobierno equilibrando la toma de decisiones descentralizada con la rendición de cuentas y salvaguardando la seguridad de la Blockchain de Cardano. Reconociendo la necesidad de un marco de gobernanza más robusto y dinámico, que no se base ni dependa de los sistemas de gobernanza tradicionales de los estados-nación, sino que se base en el autogobierno de la Comunidad de Cardano, utilizando, siempre que sea posible y beneficioso, la tecnología blockchain en el proceso de gobernanza, establecemos por la presente esta Constitución de Cardano para gobernar el ecosistema de la Blockchain de Cardano, garantizar la continuidad de la Blockchain de Cardano y proteger los derechos de quienes la utilizan y los derechos de los propietarios de ada. Con estos propósitos en mente, nosotros, la Comunidad de Cardano, afirmamos nuestra intención de acatar esta Constitución para poder participar en la gobernanza del ecosistema de la Blockchain de Cardano. Invitamos a todos los que comparten nuestros valores a unirse a nosotros durante el tiempo que deseen, respetando siempre la libertad de tomar otro camino. ## **TÉRMINOS DEFINIDOS** 1. **Stake de Votación Activo (Active Voting Stake):** La cantidad total de lovelace que está delegada a DReps o SPOs activos. Este _stake_ (participación) se utiliza como base para calcular los umbrales de votación y juzgar los resultados de las acciones de gobernanza propuestas. Excluye el _stake_ delegado a DReps inactivos, la opción de voto de abstención predefinida, el _stake_ no registrado y el _stake_ registrado no delegado. 2. **Comunidad de Cardano:** El grupo colectivo de todas las personas y organizaciones que, al adoptar los principios y objetivos compartidos establecidos en la Constitución del Ecosistema de la Blockchain de Cardano, poseen ada, desarrollan, construyen, apoyan, mantienen, contribuyen a y utilizan la Blockchain de Cardano. 3. **Miembro de la Comunidad de Cardano:** Cualquier participante, individuo u organización en la Comunidad de Cardano, incluyendo el CC. 4. **Comité Constitucional (CC):** El órgano rector y sus escaños elegidos encargados de garantizar que las acciones de gobernanza aplicables entren en vigor en la Blockchain de Cardano solo si están alineadas con los principios y disposiciones establecidos en la Constitución del Ecosistema de la Blockchain de Cardano. 5. **Miembro del Comité Constitucional (Miembro del CC):** Una persona, ya sea un individuo u organización, que sirve como miembro del Comité Constitucional. 6. **Representante Delegado (DRep):** El individuo o entidad registrada para votar con respecto a acciones de gobernanza _on-chain_ en su propio nombre o en nombre de otros propietarios de ada. 7. **Límite de Cambio Neto (Net Change Limit):** La cantidad o porcentaje máximo permitido de lovelace que puede retirarse del Tesoro de Cardano en un período determinado. 8. **Operador de Stake Pool (SPO):** Un individuo o entidad que controla la(s) clave(s) en frío de un nodo productor de bloques de un _Stake Pool_. 9. **Stake Pool:** El nodo productor de bloques de un Operador de Stake Pool, identificado por un ID de Stake Pool único, que agrega el _stake_ de los Delegadores aplicables, forja y valida Bloques, y facilita las contribuciones del SPO a la seguridad, descentralización, mecanismo de consenso y proceso de gobernanza de la Blockchain de Cardano. 10. **Receptor de Retiros del Tesoro:** Una persona o entidad que se indica como el receptor de ada del Tesoro de Cardano en la acción relevante de “Retiros del Tesoro” (_Treasury Withdrawals_). ## **ARTÍCULO I. DOGMAS Y GUARDRAILS DE LA BLOCKCHAIN DE CARDANO** ### **Sección 1: Dogmas Rectores** Los siguientes Dogmas guiarán a todos los miembros de la Comunidad de Cardano y las acciones de gobernanza propuestas se evaluarán de acuerdo con estos Dogmas. El orden en que aparecen los Dogmas a continuación no pretende representar una prioridad entre ellos. - **DOGMA 1:** Las transacciones en la Blockchain de Cardano no serán ralentizadas ni censuradas y se procesarán de manera expedita para su propósito previsto. - **DOGMA 2:** El costo de las transacciones en la Blockchain de Cardano será predecible y no irrazonable. - **DOGMA 3:** Cualquier persona que desee desarrollar e implementar aplicaciones en la Blockchain de Cardano no se le impedirá irrazonablemente desarrollar e implementar dichas aplicaciones según lo previsto. - **DOGMA 4:** Las contribuciones de la Comunidad de Cardano en la Blockchain de Cardano serán reconocidas, registradas y evaluadas de manera justa a través del reparto de recompensas con los SPOs, compensación potencial a los DReps y miembros del CC, y una _tokenomics_ apropiada. - **DOGMA 5:** La Blockchain de Cardano no bloqueará el valor ni los datos de un propietario de ada sin su consentimiento. - **DOGMA 6:** La Blockchain de Cardano no impedirá irrazonablemente la interoperabilidad. - **DOGMA 7:** La Blockchain de Cardano preservará de manera segura cualquier valor e información almacenados en ella. - **DOGMA 8:** La Blockchain de Cardano no gastará recursos de manera irrazonable. - **DOGMA 9:** Todos los usuarios de la Blockchain de Cardano serán tratados de manera justa e imparcial, teniendo en cuenta los deseos colectivos de la Comunidad de Cardano, en consonancia con la sostenibilidad y viabilidad a largo plazo de la Blockchain. - **DOGMA 10:** El sistema monetario de la Blockchain de Cardano promoverá la estabilidad financiera. Esto incluirá buscar preservar el valor y la utilidad de ada como medio de intercambio, reserva de valor y unidad de cuenta. El suministro total de ada no superará los 45.000.000.000 (45.000.000.000.000.000 lovelace). ### **Sección 2: Implementación de los Guardrails (Límites de Seguridad)** 1. La Blockchain de Cardano operará de acuerdo con el Apéndice de Guardrails de la Blockchain de Cardano adjunto a esta Constitución. La Comunidad de Cardano puede codificar digitalmente ciertos Guardrails de modo que se programen e implementen directamente en la Blockchain de Cardano utilizando un Script de Guardrails _on-chain_ o reglas de libro mayor (_ledger_) incorporadas. 2. En caso de que existan inconsistencias entre un Guardrail tal como se establece en el Apéndice de Guardrails y cualquier Guardrail que haya sido programado e implementado en la Blockchain de Cardano, prevalecerá la versión de dicho Guardrail que se haya implementado directamente en la Blockchain de Cardano a menos y hasta que sea reemplazada o revisada de conformidad con una acción de gobernanza _on-chain_. El CC buscará conciliar dichas inconsistencias fomentando una acción de gobernanza _on-chain_ apropiada. ## **ARTÍCULO II. COMUNIDAD Y GOBERNANZA** ### **Sección 1: La Comunidad de Cardano** 1. No se requerirá membresía formal para usar, participar y beneficiarse de la Blockchain de Cardano. Los miembros de la Comunidad de Cardano tienen derecho a los derechos, privilegios y protecciones de esta Constitución, y en consecuencia se espera que apoyen y defiendan esta Constitución, mantengan la integridad del ecosistema, participen en la gobernanza y resuelvan las disputas de manera transparente. 2. Se anima a los miembros de la Comunidad de Cardano a colaborar en el desarrollo de aplicaciones y a formar organizaciones que apoyen a la Blockchain de Cardano y a su Comunidad. ### **Sección 2: Derechos de Participación de los propietarios de ada** 1. Los propietarios de ada tienen derecho a acceder y participar en los procesos de toma de decisiones _on-chain_ del ecosistema de la Blockchain de Cardano, lo que incluye votar, proponer cambios a la estructura de gobernanza de acuerdo con los Guardrails, y participar de otras maneras en las acciones de gobernanza _on-chain_. 2. Los propietarios de ada pueden participar directamente en las acciones de gobernanza registrándose ellos mismos como DReps o delegando sus derechos de voto a otros DReps registrados. 3. A cualquier propietario de ada se le permitirá registrarse como DRep. Un DRep puede actuar en interés de uno o más propietarios de ada. 4. A cualquier propietario de ada se le permitirá delegar su _stake_ de votación a uno o más DReps registrados, incluidos ellos mismos. 5. A los propietarios de ada se les permitirá cambiar la delegación de su _stake_ de votación en cualquier momento. 6. Los propietarios de ada que utilizan custodios de terceros u otros designados para mantener sus ada pueden autorizar, o pueden retener la autorización, para que dichos terceros voten en su nombre y deleguen los derechos de voto del propietario de ada a DReps registrados en nombre del propietario. 7. Los propietarios de ada tienen derecho a un proceso para participar, enviar y votar acciones de gobernanza _on-chain_ que sea abierto, transparente y esté protegido contra influencias indebidas y manipulación. ### **Sección 3: Marco de Gobernanza Descentralizada** 1. La Blockchain de Cardano se rige por un modelo descentralizado y _on-chain_ que, donde es beneficioso, utiliza contratos inteligentes y otras herramientas blockchain para facilitar la toma de decisiones y garantizar la transparencia. 2. Tres cuerpos de votación independientes (DReps, SPOs y el CC) participan en la votación _on-chain_; cualquier persona que tenga múltiples roles debe revelar públicamente dichas superposiciones antes de participar en cualquier acción de gobernanza _on-chain_. ### **Sección 4: Representantes Delegados (DReps)** 1. Los DReps tienen un poder de voto igual al número de lovelace delegados a ellos. 2. Los DReps pueden votar en todos los tipos de acciones de gobernanza. 3. Los DReps deberán garantizar que cualquier compensación recibida en relación con sus actividades como DRep se divulgue públicamente de manera oportuna a través de los canales de comunicación de gobernanza relevantes. 4. Los DReps no ofrecerán ni proporcionarán compensación a un propietario de ada a cambio de ser designados como DRep o por votar en su nombre. ### **Sección 5: Operadores de Stake Pool (SPOs)** 1. Los SPOs votarán sobre las siguientes acciones de gobernanza: “Falta de Confianza” (_No Confidence_), “Actualizar Comité” (_Update Committee_), “Iniciación de Hard Fork” (_Hard Fork Initiation_), “Actualización de Parámetros” (_Parameter Update_) que afecten a parámetros relevantes para la seguridad, y acciones de “Info”. ### **Sección 6: Estándares de las Acciones de Gobernanza** 1. Para garantizar la transparencia en la gobernanza _on-chain_, las acciones de gobernanza propuestas deberán seguir un formato estandarizado y legible antes de registrarse o promulgarse _on-chain_. Este formato incluirá una URL que aloje un documento que describa contexto adicional para la acción de gobernanza propuesta, y el hash de este documento. El documento alojado en dicha URL deberá ser inmutable e incapaz de ser alterado después de su presentación, y el contenido de toda Acción de Gobernanza _on-chain_ debe ser idéntico a la versión final _off-chain_ de la acción propuesta. 2. Cada propuesta deberá proporcionar una justificación suficiente, incluyendo como mínimo: un título, resumen, justificación y materiales de apoyo relevantes. 3. Las acciones de “Iniciación de Hard Fork” y “Actualización de Parámetros” se someterán a suficiente revisión técnica y escrutinio según lo ordenado por los Guardrails para garantizar que la acción de gobernanza no ponga en peligro la seguridad, funcionalidad, rendimiento o sostenibilidad a largo plazo de la Blockchain de Cardano. ### **Sección 7: Estándares para las Acciones de “Retiros del Tesoro”** Una acción de “Retiros del Tesoro” (_Treasury Withdrawals_) debe, además de los requisitos de la Sección 6, cumplir con todos los siguientes requisitos: 1. Las acciones de “Retiros del Tesoro” deben especificar los términos del retiro. Esto incluirá: el propósito del retiro, el período de entrega de las actividades propuestas para las que se utilizará el retiro, los costos y gastos relevantes de las actividades propuestas, y las circunstancias bajo las cuales el retiro podría ser reembolsado al Tesoro de Cardano. 2. Las acciones de “Retiros del Tesoro” divulgarán si el posible receptor de la acción de “Retiros del Tesoro” ha recibido ada del Tesoro de Cardano en los últimos 24 meses. 3. Se debe establecer un Límite de Cambio Neto. Las acciones de “Retiros del Tesoro” no deben superar el Límite de Cambio Neto para ese período. 4. Las acciones de “Retiros del Tesoro” requerirán una asignación de ada como parte de dicha solicitud de financiamiento para cubrir el costo de auditorías independientes periódicas y la implementación de métricas de supervisión sobre el uso de dicho ada. 5. Las acciones de “Retiros del Tesoro” designarán a uno o más administradores responsables de monitorear cómo se utilizan los fondos y garantizar que se logren los entregables. 6. Cualquier ada recibido de un retiro del tesoro de la Blockchain de Cardano, siempre que dicho ada esté en manos de un administrador antes de su posterior desembolso al Receptor del Retiro del Tesoro, debe mantenerse en una o más cuentas separadas que puedan ser auditadas por la Comunidad de Cardano, y dichas cuentas no se delegarán a un SPO, sino que deben delegarse a la opción de voto de abstención predefinida. ## **ARTÍCULO III. COMITÉ CONSTITUCIONAL** ### **Sección 1: Rol y Alcance** 1. Se establecerá un CC como la rama del proceso de gobernanza _on-chain_ de Cardano que asegura que las acciones de gobernanza a promulgarse _on-chain_ sean consistentes con esta Constitución. 2. Cada miembro del CC tendrá un voto. 3. Ninguna acción de gobernanza (que no sea una acción de “Falta de Confianza” o “Actualizar Comité”) puede implementarse _on-chain_ sin la afirmación de un porcentaje requerido de los miembros del CC. 4. El CC se limitará a votar sobre la constitucionalidad de las acciones de gobernanza, incluidas las acciones propuestas o contempladas contenidas dentro de las acciones de “Info”. ### **Sección 2: Composición y Mandatos** 1. El CC estará compuesto por la cantidad de miembros y cumplirá mandatos de tal duración que sean suficientes para asegurar la integridad continua de la Blockchain de Cardano, según lo determinen periódicamente los propietarios de Ada. 2. Para asegurar la continuidad en la operación del CC, los mandatos de los miembros del CC estarán escalonados. ### **Sección 3: Proceso de Elección, Falta de Confianza y Remoción** 1. Se considerará que el CC se encuentra en uno de los siguientes dos estados en todo momento: un estado de confianza o un estado de falta de confianza. En un estado de falta de confianza, los miembros del CC vigente deben ser reinstalados o reemplazados utilizando la acción de “Actualizar Comité” antes de que cualquier otra acción de gobernanza _on-chain_, aparte de las acciones de “Info”, pueda avanzar. 2. La Comunidad de Cardano establecerá y hará público un proceso periódico para la elección de los miembros del CC de acuerdo con los requisitos de los Guardrails. 3. En el caso de un voto de falta de confianza o la remoción de algunos miembros del CC mediante la acción de “Actualizar Comité”, se llevará a cabo una elección lo antes posible. ### **Sección 4: Transparencia y Conducta** 1. Los procesos del CC serán transparentes, y el CC publicará cada decisión. 2. Al votar que una acción de gobernanza que se propone ejecutar _on-chain_ es inconstitucional, cada miembro del CC que emita dicho voto expondrá las bases de su decisión haciendo referencia a los Artículos específicos de esta Constitución o a las disposiciones del Apéndice de Guardrails de la Blockchain de Cardano que estén en conflicto con una propuesta determinada. 3. Los miembros del CC pueden ser compensados por sus esfuerzos como miembros y se asegurarán de que cualquier compensación recibida en relación con dichas actividades sea divulgada de manera oportuna a través de los canales de comunicación de gobernanza relevantes. ## **ARTÍCULO IV. PROCESO DE ENMIENDA** ### **Sección 1: Reglas de Enmienda** Las enmiendas a esta Constitución, incluido el Apéndice de Guardrails de la Blockchain de Cardano, requerirán aprobación mediante una acción de gobernanza _on-chain_ respaldada por al menos el 65% del _stake_ de votación activo en ese momento, a menos que se estipule expresamente un umbral diferente en el Apéndice de Guardrails de la Blockchain de Cardano para la enmienda de un Guardrail en particular, en cuyo caso se aplicará ese umbral. _(Nota: A continuación sigue la traducción de los Apéndices I y II. Debido a la gran longitud del documento original, he traducido todo de forma continua manteniendo el máximo rigor técnico.)_ ## **APÉNDICE I. GUARDRAILS DE LA BLOCKCHAIN DE CARDANO** ### **1. Introducción** Para implementar la gobernanza _on-chain_ de la Blockchain de Cardano, es necesario establecer Guardrails sensatos que permitan a la Blockchain de Cardano continuar operando de manera segura y sostenible. Este Apéndice establece Guardrails que deben aplicarse a las acciones de gobernanza _on-chain_ de la Blockchain de Cardano, incluidos los cambios en los parámetros del protocolo y los límites sobre los retiros del tesoro. Estos Guardrails cubren tanto los límites esenciales e intrínsecos de las configuraciones como las recomendaciones basadas en experiencia, investigación, mediciones y objetivos de gobernanza. Estos Guardrails están diseñados para evitar problemas imprevistos y previsibles en la operación de la Blockchain de Cardano. Su intención es guiar la selección de configuraciones de parámetros sensatas y evitar posibles problemas con la seguridad, rendimiento, funcionalidad o sostenibilidad a largo plazo. Como se describe a continuación, algunos de estos Guardrails son automatizables y se aplicarán a través de un Script de Guardrails _on-chain_ o reglas de libro mayor incorporadas. Estos Guardrails se aplican únicamente al entorno de la red principal (_mainnet_) Capa 1 (Layer 1) de la Blockchain de Cardano. No están pensados para aplicarse a entornos de prueba (_testnets_) ni a otras blockchains que utilicen el software de la Blockchain de Cardano. No todos los parámetros para la Blockchain de Cardano pueden considerarse de manera independiente. Algunos interactúan con otras configuraciones de manera intrínseca. Donde son conocidas, estas interacciones se abordan en este Apéndice. Aunque los Guardrails en este Apéndice reflejan actualmente el estado actual del conocimiento técnico, este documento debe tratarse como un documento vivo. Las mejoras en la implementación, nuevas simulaciones o resultados de evaluaciones de rendimiento para la Blockchain de Cardano podrían permitir relajar o ajustar algunas de las restricciones contenidas aquí en el momento oportuno. También pueden necesitarse Guardrails adicionales cuando, por ejemplo, se introducen nuevos parámetros de protocolo o se eliminan los existentes. #### **Enmienda, Adición o Depreciación de Guardrails** Los Guardrails pueden ser modificados ocasionalmente mediante una acción de gobernanza _on-chain_ que cumpla con el umbral de votación aplicable. Toda enmienda a cualquier Guardrail requerirá y se considerará una enmienda a la Constitución misma. Cada Guardrail tiene una etiqueta única. Si se enmienda el texto de un Guardrail, el existente quedará obsoleto y se usará una nueva etiqueta. Del mismo modo, si se deprecia un Guardrail, su etiqueta nunca se reutilizará. En todos los casos, los Guardrails aplicables serán aquellos vigentes en el momento en que se envía la acción de gobernanza. #### **Terminología y Orientación** _(El texto define términos como Blockchain de Cardano, Bloque, Protocolo, Parámetros de Protocolo, Slot, Época (Epoch), lovelace, ada, Delegador, Stake de Producción de Bloques Activo, On-chain, Off-Chain, Acción de Gobernanza, Hard Fork, Guardrails, Script de Guardrails, y los distintos tipos de acciones de gobernanza. También define términos de rendimiento como Benchmarking, Análisis de rendimiento, Simulación, Monitoreo de rendimiento, Reversión de cambios y Niveles de gravedad, y términos de obligación como Esperado (Expected), Debería/No debería (Should/Should not) y Debe/No debe (Must/Must not).)_ #### **Verificación Automatizada (“Script de Guardrails”)** Un hash de script se asocia con el hash de la Constitución cuando se promulga una acción de gobernanza de Nueva Constitución o Script de Guardrails. El Script de Guardrails solo afecta dos tipos de acciones de gobernanza: “Actualización de Parámetros” y “Retiros del Tesoro”. Hay símbolos clave: - (y) El Script de Guardrails puede usarse para hacer cumplir el Guardrail. - (x) No puede usarse para hacer cumplir el Guardrail. - (~ - razón) No puede usarse por la razón dada, pero cambios futuros podrían habilitarlo. Si los Guardrails se superponen, se aplica el más restrictivo. Si un parámetro no se menciona explícitamente, el script no debe permitir ningún cambio. Si se menciona pero no hay guardrails verificables, el script no debe imponer restricciones. ### **2. Guardrails y Directrices sobre las acciones de “Actualización de Parámetros” (“Parameter Update”)** A continuación, se presentan los Guardrails y directrices para cambiar las configuraciones de los parámetros de protocolo actualizables mediante la acción de “Actualización de Parámetros” de manera que la Blockchain de Cardano nunca se encuentre en un estado irrecuperable como resultado de dichos cambios. Ten en cuenta que, para evitar ambigüedades, este Apéndice utiliza el nombre del parámetro que se emplea en las acciones de “Actualización de Parámetros” en lugar de cualquier otra convención. ##### **GUARDRAILS** - **PARAM-01 (y)** Cualquier parámetro de protocolo que no esté explícitamente nombrado en este documento no debe ser cambiado por una acción de “Actualización de Parámetros”. - **PARAM-02a (y)** Cuando un parámetro de protocolo se enumera explícitamente en este documento pero no se especifican Guardrails verificables, el Script de Guardrails no debe imponer ninguna restricción a los cambios en el parámetro. Los Guardrails verificables se indican con un (y). ### **2.1. Parámetros Críticos del Protocolo** Los siguientes parámetros de protocolo son críticos desde el punto de vista de la seguridad. #### **Parámetros Críticos para la Operación de la Blockchain** - _tamaño máximo del cuerpo del bloque_ (_maxBlockBodySize_) - _tamaño máximo de transacción_ (_maxTxSize_) - _tamaño máximo del encabezado del bloque_ (_maxBlockHeaderSize_) - _tamaño máximo de un valor de activo serializado_ (_maxValueSize_) - _unidades máximas de ejecución de script/memoria en un solo bloque_ (_maxBlockExecutionUnits[steps/memory]_) - _coeficiente de tarifa mínima_ (_txFeePerByte_) - _constante de tarifa mínima_ (_txFeeFixed_) - _tarifa mínima por byte para scripts de referencia_ (_minFeeRefScriptCoinsPerByte_) - _depósito mínimo de lovelace por byte de UTxO serializado_ (_utxoCostPerByte_) - _depósito de acción de gobernanza_ (_govDeposit_) ##### **GUARDRAILS** - **PARAM-03a (y)** Un parámetro que es crítico para la operación de la blockchain requiere el voto de un SPO además del voto de un DRep: Los SPOs deben decir “sí” con un respaldo colectivo de más del 50% de todo el stake de producción de bloques activo. Esto es aplicado por los Guardrails en el umbral de votación del stake pool. - **PARAM-04a (x)** Normalmente deben pasar al menos 90 días entre la publicación de una propuesta off-chain para cambiar un parámetro crítico para la operación de la blockchain y el envío de la correspondiente acción de gobernanza on-chain. Este Guardrail puede flexibilizarse en caso de un problema de red de Gravedad 1 o Gravedad 2 tras una cuidadosa discusión y evaluación técnica. #### **Parámetros Críticos para el Sistema de Gobernanza** - _depósito en lovelace de clave de delegación_ (_stakeAddressDeposit_) - _depósito en lovelace de registro de pool_ (_stakePoolDeposit_) - _corte fijo mínimo de recompensas para pools_ (_minPoolCost_) - _cantidad de depósito de DRep_ (_dRepDeposit_) - _tamaño mínimo del Comité Constitucional_ (_committeeMinSize_) - _duración máxima del mandato (en épocas) para los miembros del Comité Constitucional_ (_committeeMaxTermLength_) ##### **GUARDRAILS** - **PARAM-05a (y)** Los DReps deben votar “sí” con un apoyo colectivo de más del 50% de todo el stake de votación activo. Esto es aplicado por los Guardrails en los umbrales de votación de los DReps. - **PARAM-06a (x)** Normalmente deben pasar al menos 90 días entre la publicación de una propuesta off-chain para cambiar un parámetro crítico para el sistema de gobernanza y el envío de la correspondiente acción de gobernanza on-chain. Este Guardrail puede flexibilizarse en caso de un problema de red de Gravedad 1 o Gravedad 2 tras una cuidadosa discusión y evaluación técnica. ### **2.2. Parámetros Económicos** Los objetivos generales al gestionar los parámetros económicos son: 1. Permitir la sostenibilidad económica a largo plazo para la Blockchain de Cardano. 2. Garantizar que los stake pools sean recompensados adecuadamente por mantener la Blockchain de Cardano. 3. Garantizar que los propietarios de ada sean recompensados adecuadamente por utilizar el stake de manera constructiva, incluso al delegar ada para la producción de bloques. 4. Equilibrar los incentivos económicos para los diferentes interesados del ecosistema de la Blockchain de Cardano, incluidos, entre otros, los Operadores de Stake Pool, propietarios de ada, usuarios de DeFi, usuarios de infraestructura, desarrolladores (por ejemplo, DApps) e intermediarios financieros (por ejemplo, exchanges). #### **Desencadenantes de Cambio** 1. Cambios significativos en el valor fiduciario (fiat) de ada que resulten en problemas potenciales de seguridad, rendimiento, funcionalidad o sostenibilidad a largo plazo. 2. Cambios en los volúmenes o tipos de transacciones. 3. Solicitudes o sugerencias de la Comunidad. 4. Situaciones de emergencia que requieran cambios en los parámetros económicos. #### **Contraindicadores** Los cambios en los parámetros económicos no deben hacerse de forma aislada. Deben tener en cuenta: - Factores económicos externos. - Preocupaciones de seguridad de la red. #### **Métricas Principales** - Valor fiduciario de ada que resulte en problemas potenciales de seguridad, rendimiento, funcionalidad o sostenibilidad a largo plazo. - Volúmenes y tipos de transacciones. - Número y salud de los stake pools. - Factores económicos externos. #### **Cambios a Parámetros Económicos Específicos** **Tarifa de transacción por byte (txFeePerByte) y tarifa de transacción fija (txFeeFixed)** Define el costo para transacciones básicas en lovelace: _fee(tx) = txFeeFixed + txFeePerByte x nBytes(tx)_ ##### **GUARDRAILS** - **TFPB-01 (y)** _txFeePerByte_ no debe ser inferior a 30 (0.000030 ada). Esto protege contra ataques de denegación de servicio (DoS) de bajo costo. - **TFPB-02 (y)** _txFeePerByte_ no debe exceder 1,000 (0.001 ada). Esto garantiza que las transacciones puedan pagarse. - **TFPB-03 (y)** _txFeePerByte_ no debe ser negativo. - **TFF-01 (y)** _txFeeFixed_ no debe ser inferior a 100,000 (0.1 ada). Esto protege contra ataques DoS de bajo costo. - **TFF-02 (y)** _txFeeFixed_ no debe exceder 10,000,000 (10 ada). Esto garantiza que las transacciones puedan pagarse. - **TFF-03 (y)** _txFeeFixed_ no debe ser negativo. - **TFGEN-01 (x - “debería”)** Para mantener un nivel constante de protección contra ataques de denegación de servicio, _txFeeFixed_ y _txFeePerByte_ deberían ajustarse siempre que se ajusten los precios de Ejecución de Plutus (_executionUnitPrices[steps/memory]_). - **TFGEN-02 (x - “no cuantificable”)** Cualquier cambio en _txFeeFixed_ o _txFeePerByte_ debe considerar las implicaciones de reducir el costo de un ataque de denegación de servicio o aumentar la tarifa máxima de transacción para que resulte imposible construir una transacción. **Costo de UTxO por byte (utxoCostPerByte)** Define el depósito (en lovelace) que se cobra por cada byte de almacenamiento que se guarda en un UTxO. Este depósito se devuelve cuando el UTxO ya no está activo. - Establece un umbral mínimo de ada que se mantiene dentro de un solo UTxO. - Proporciona protección contra ataques de denegación de servicio de bajo costo en el almacenamiento de UTxO. La protección DoS disminuye en línea con la memoria libre del nodo (proporcional al crecimiento de UTxO). - Ayuda a reducir los costos de almacenamiento a largo plazo para los usuarios del nodo proporcionando un incentivo para devolver UTxOs cuando ya no se necesitan, o para fusionar UTxOs. ##### **GUARDRAILS** - **UCPB-01 (y)** _utxoCostPerByte_ no debe ser inferior a 3,000 (0.003 ada). - **UCPB-02 (y)** _utxoCostPerByte_ no debe exceder 6,500 (0.0065 ada). - **UCPB-03 (y)** _utxoCostPerByte_ no debe ser cero. - **UCPB-04 (y)** _utxoCostPerByte_ no debe ser negativo. - **UCPB-05a (x - “debería”)** Los cambios deberían tener en cuenta: **Depósito de dirección de stake (stakeAddressDeposit)** Asegura que las direcciones de stake se retiren cuando ya no se necesiten. - Ayuda a reducir los costos de almacenamiento a largo plazo. - Ayuda a limitar los costos de CPU y memoria en el libro mayor. La lógica del depósito es incentivar la devolución de recursos de memoria escasos cuando ya no son requeridos. Reducir el número de direcciones de stake activas también reduce los costos de procesamiento y memoria en el límite de la época al calcular capturas de pantalla (snapshots) del stake. ##### **GUARDRAILS** - **SAD-01 (y)** _stakeAddressDeposit_ no debe ser inferior a 1,000,000 (1 ada). - **SAD-02 (y)** _stakeAddressDeposit_ no debe exceder 5,000,000 (5 ada). - **SAD-03 (y)** _stakeAddressDeposit_ no debe ser negativo. **Depósito de stake pool (stakePoolDeposit)** Asegura que los stake pools sean retirados por el operador del stake pool cuando este ya no los necesite. - Ayuda a reducir los costos de almacenamiento a largo plazo. La lógica del depósito es incentivar la devolución de recursos de memoria escasos. Los cálculos de recompensas y de las instantáneas del stake también se ven afectados por la cantidad de stake pools activos. ##### **GUARDRAILS** - **SPD-01 (y)** _stakePoolDeposit_ no debe ser inferior a 250,000,000 (250 ada). - **SPD-02 (y)** _stakePoolDeposit_ no debe exceder 500,000,000 (500 ada). - **SPD-03 (y)** _stakePoolDeposit_ no debe ser negativo. **Costo mínimo del pool (minPoolCost)** Parte del mecanismo de recompensas. - El costo mínimo del pool se transfiere a la dirección de recompensas del pool antes de que se pague cualquier recompensa a los delegadores. ##### **GUARDRAILS** - **MPC-01 (y)** _minPoolCost_ no debe ser negativo. - **MPC-02 (y)** _minPoolCost_ no debe exceder 500,000,000 (500 ada). - **MPC-03 (x - “debería”)** _minPoolCost_ debería establecerse en línea con el costo económico de operar un pool. **Corte del tesoro (treasuryCut)** Parte del mecanismo de recompensas. - La porción de corte del tesoro proveniente de la expansión monetaria se transfiere al tesoro antes de pagar cualquier recompensa del pool. - Se puede establecer en el rango 0.0-1.0 (0%-100%). ##### **GUARDRAILS** - **TC-01 (y)** _treasuryCut_ no debe ser inferior a 0.1 (10%). - **TC-02 (y)** _treasuryCut_ no debe exceder 0.3 (30%). - **TC-03 (y)** _treasuryCut_ no debe ser negativo. - **TC-04 (y)** _treasuryCut_ no debe exceder 1.0 (100%). - **TC-05 (~ - sin acceso al historial de cambios)** _treasuryCut_ no debe cambiarse más de una vez en ningún período de 36 épocas (aproximadamente 6 meses). **Tasa de expansión monetaria (monetaryExpansion)** Parte del mecanismo de recompensas. - La expansión monetaria controla la cantidad de reservas que se utilizan para recompensas cada época. Gobierna la sostenibilidad a largo plazo de la Blockchain de Cardano. - Las reservas se agotan gradualmente hasta que no se suministran más recompensas. ##### **GUARDRAILS** - **ME-01 (y)** _monetaryExpansion_ no debe exceder 0.005. - **ME-02 (y)** _monetaryExpansion_ no debe ser inferior a 0.001. - **ME-03 (y)** _monetaryExpansion_ no debe ser negativo. - **ME-04 (x - “debería”)** _monetaryExpansion_ no debería variar más de +/- 10% en ningún período de 73 épocas (aproximadamente 12 meses). - **ME-05 (x - “debería”)** _monetaryExpansion_ no debería cambiarse más de una vez en ningún período de 36 épocas (aproximadamente 6 meses). **Precios de Ejecución de Scripts Plutus (executionUnitPrices[priceSteps/priceMemory])** Definen las tarifas por ejecutar scripts Plutus. - Ofrece un retorno económico por la ejecución de scripts Plutus. - Proporciona seguridad contra ataques DoS de bajo costo. ##### **GUARDRAILS** - **EIUP-PS-01 (y)** _executionUnitPrices[priceSteps]_ no debe exceder 2,000 / 10,000,000. - **EIUP-PS-02 (y)** _executionUnitPrices[priceSteps]_ no debe ser inferior a 500 / 10,000,000. - **EIUP-PM-01 (y)** _executionUnitPrices[priceMemory]_ no debe exceder 2,000 / 10,000. - **EIUP-PM-02 (y)** _executionUnitPrices[priceMemory]_ no debe ser inferior a 400 / 10,000. - **EIUP-GEN-01 (x - “similar a”)** Los precios de ejecución deben configurarse para que: - **EIUP-GEN-02 (x - “debería”)** Los precios de ejecución deberían ajustarse siempre que se ajusten las tarifas de transacción (_txFeeFixed/txFeePerByte_). El objetivo es asegurar que el retraso en el procesamiento sea similar para las transacciones “llenas”, sin importar su tipo. Esto ayuda a garantizar que se cumplan los requisitos en los tiempos de difusión/propagación de bloques. **Tarifa de transacción por byte para un script de referencia (minFeeRefScriptCoinsPerByte)** Define el costo en lovelace de usar scripts de referencia Plutus. ##### **GUARDRAILS** - **MFRS-01 (y)** _minFeeRefScriptCoinsPerByte_ no debe exceder 1,000 (0.001 ada). - **MFRS-02 (y)** _minFeeRefScriptCoinsPerByte_ no debe ser negativo. - **MFRS-03 (x - “debería”)** Para mantener un nivel consistente de protección contra ataques de denegación de servicio, _minFeeRefScriptCoinsPerByte_ debería ajustarse siempre que se ajusten los precios de ejecución de Plutus (_executionUnitPrices[steps/memory]_) y siempre que se ajuste _txFeeFixed_. - **MFRS-04 (x - “no cuantificable”)** Cualquier cambio en _minFeeRefScriptCoinsPerByte_ debe considerar las implicaciones de reducir el costo de un ataque DoS o de aumentar la tarifa máxima de transacción. ### **2.3. Parámetros de Red** Los objetivos generales al gestionar los parámetros de la red de la Blockchain de Cardano son: 1. Adaptar la capacidad de red disponible de la Capa 1 a las demandas de tráfico actuales o futuras, incluidas las transacciones de pago, las DApps de capa 1, la gestión de cadenas laterales (sidechains) y las necesidades de gobernanza. 2. Equilibrar las demandas de tráfico para diferentes grupos de usuarios, incluidas transacciones de pago, mineros de Tokens Fungibles/No Fungibles, scripts Plutus, desarrolladores de DeFi, Operadores de Stake Pool y transacciones de votación. #### **Desencadenantes de Cambio** Los cambios a los parámetros de red pueden ser desencadenados por: 1. Cambios medidos en las demandas de tráfico durante un período de 2 épocas (10 días). 2. Cambios anticipados en las demandas de tráfico. 3. Solicitudes de la Comunidad de Cardano. #### **Contraindicadores** Los cambios pueden necesitar ser revertidos y/o no deberían promulgarse en caso de: - Retrasos excesivos en la propagación de bloques. - Stake pools que no pueden manejar el volumen de tráfico. - Scripts que no pueden completar su ejecución. #### **Métricas Principales** Todas las decisiones sobre cambios de parámetros deben informarse mediante: - El perfil de retraso en la propagación de bloques. - El volumen de tráfico (tamaño de bloque a lo largo del tiempo). - El volumen de scripts (tamaño de los scripts y unidades de ejecución). - Benchmarks de los costos de ejecución de scripts. - Benchmarks de retraso en la propagación/difusión de bloques. Se requieren resultados detallados de benchmarking para confirmar el efecto de cualquier cambio en el rendimiento o comportamiento de la mainnet antes de su promulgación. Se deben analizar los efectos de diferentes combinaciones de transacciones, incluidas las normales, los scripts Plutus y las acciones de gobernanza. ##### **GUARDRAILS** - **NETWORK-01 (x - “debería”)** Ningún parámetro de red individual debería cambiar más de una vez por cada dos épocas. - **NETWORK-02 (x - “debería”)** Solo debería cambiarse un parámetro de red por época a menos que estén directamente correlacionados, por ejemplo, los límites de unidades de memoria por transacción y por bloque. #### **Cambios a Parámetros de Red Específicos** **Tamaño del bloque (maxBlockBodySize)** El tamaño máximo de un bloque, en bytes. ##### **GUARDRAILS** - **MBBS-01 (y)** _maxBlockBodySize_ no debe exceder 122,880 bytes (120KB). - **MBBS-02 (y)** _maxBlockBodySize_ no debe ser inferior a 24,576 bytes (24KB). - **MBBS-03a (x - circunstancias excepcionales)** _maxBlockBodySize_ no debe disminuirse, salvo en circunstancias excepcionales donde haya problemas potenciales con la seguridad, el rendimiento, la funcionalidad o la sostenibilidad a largo plazo. - **MBBS-04 (~ - sin acceso a valores de parámetros existentes)** _maxBlockBodySize_ debe ser lo suficientemente grande como para incluir al menos una transacción (es decir, _maxBlockBodySize_ debe ser al menos _maxTxSize_). - **MBBS-05 (x - “debería”)** _maxBlockBodySize_ debería cambiarse como máximo en 10,240 bytes (10KB) por época (5 días), y preferiblemente en 8,192 bytes (8KB) o menos por época. - **MBBS-06 (x - “debería”)** El tamaño del bloque no debería inducir un viaje de ida y vuelta adicional del Protocolo de Control de Transmisión (TCP). Cualquier aumento más allá de esto debe estar respaldado por un análisis de rendimiento, simulación y benchmarking. - **MBBS-07 (x - “no cuantificable”)** El impacto de cualquier cambio en _maxBlockBodySize_ debe ser confirmado mediante benchmarking/simulación detallados y no exceder los requisitos de los presupuestos de tiempo de propagación/difusión de bloques. Cualquier aumento también debe considerar los futuros requerimientos para la ejecución de scripts Plutus frente al objetivo total de difusión de bloques de 3s con un 95% de propagación en 5s. **Tamaño de transacción (maxTxSize)** El tamaño máximo de una transacción, en bytes. ##### **GUARDRAILS** - **MTS-01 (y)** _maxTxSize_ no debe exceder 32,768 bytes (32KB). - **MTS-02 (y)** _maxTxSize_ no debe ser negativo. - **MTS-03 (~ - sin acceso a valores de parámetros existentes)** _maxTxSize_ no debe disminuirse. - **MTS-04 (~ - sin acceso a valores de parámetros existentes)** _maxTxSize_ no debe exceder _maxBlockBodySize_. - **MTS-05 (x - “debería”)** _maxTxSize_ no debería incrementarse en más de 2,560 bytes (2.5KB) en cualquier época, y preferiblemente debería incrementarse en 2,048 bytes (2KB) o menos por época. - **MTS-06 (x - “debería”)** _maxTxSize_ no debería superar 1/4 del tamaño del bloque. **Límites de Unidades de Memoria (maxBlockExecutionUnits[memory], maxTxExecutionUnits[memory])** El límite en el número máximo de unidades de memoria que pueden utilizar los scripts Plutus, ya sea por transacción o por bloque. ##### **GUARDRAILS** - **MTEU-M-01 (y)** _maxTxExecutionUnits[memory]_ no debe exceder los 40,000,000 unidades. - **MTEU-M-02 (y)** _maxTxExecutionUnits[memory]_ no debe ser negativo. - **MTEU-M-03 (~ - sin acceso a valores de parámetros existentes)** _maxTxExecutionUnits[memory]_ no debe disminuirse. - **MTEU-M-04 (x - “debería”)** _maxTxExecutionUnits[memory]_ no debería aumentarse en más de 2,500,000 unidades en ninguna época. - **MBEU-M-01 (y)** _maxBlockExecutionUnits[memory]_ no debe exceder los 120,000,000 unidades. - **MBEU-M-02 (y)** _maxBlockExecutionUnits[memory]_ no debe ser negativo. - **MBEU-M-03 (x - “debería”)** _maxBlockExecutionUnits[memory]_ no debería cambiarse (aumentarse o disminuirse) en más de 10,000,000 unidades en CUALQUIER época. - **MBEU-M-04a (x - “no cuantificable”)** El impacto de cualquier cambio debe ser confirmado mediante benchmarking/simulación y no exceder los requerimientos de propagación. Cualquier aumento debe considerar el límite de difusión de 3s/5s y requerimientos futuros. - **MEU-M-01 (~ - sin acceso a valores de parámetros existentes)** _maxBlockExecutionUnits[memory]_ no debe ser inferior a _maxTxExecutionUnits[memory]_. **Límites de Unidades CPU (maxBlockExecutionUnits[steps], maxTxExecutionUnits[steps])** El límite en el número máximo de pasos de CPU que pueden usar los scripts Plutus. ##### **GUARDRAILS** - **MTEU-S-01 (y)** _maxTxExecutionUnits[steps]_ no debe exceder 15,000,000,000 (15Bn) unidades. - **MTEU-S-02 (y)** _maxTxExecutionUnits[steps]_ no debe ser negativo. - **MTEU-S-03 (~ - sin acceso a parámetros existentes)** _maxTxExecutionUnits[steps]_ no debe disminuirse. - **MTEU-S-04 (x - “debería”)** _maxTxExecutionUnits[steps]_ no debería aumentarse en más de 500,000,000 (500M) unidades en cualquier época (5 días). - **MBEU-S-01 (y)** _maxBlockExecutionUnits[steps]_ no debe exceder 40,000,000,000 (40Bn) unidades. - **MBEU-S-02 (y)** _maxBlockExecutionUnits[steps]_ no debe ser negativo. - **MBEU-S-03 (x - “debería”)** _maxBlockExecutionUnits[steps]_ no debería cambiarse por más de 2,000,000,000 (2Bn) unidades en cualquier época. - **MBEU-S-04a (x - “no cuantificable”)** El impacto del cambio debe confirmarse por benchmarking para no exceder presupuestos de tiempo de difusión/propagación (3s, 95% en 5s). - **MEU-S-01 (~ - sin acceso a parámetros existentes)** _maxBlockExecutionUnits[steps]_ no debe ser menor a _maxTxExecutionUnits[steps]_. **Tamaño del encabezado de bloque (maxBlockHeaderSize)** El tamaño del encabezado del bloque. ##### **GUARDRAILS** - **MBHS-01 (y)** _maxBlockHeaderSize_ no debe exceder 5,000 bytes. - **MBHS-02 (y)** _maxBlockHeaderSize_ no debe ser negativo. - **MBHS-03 (x - el encabezado válido más grande está sujeto a cambio)** _maxBlockHeaderSize_ debe ser lo suficientemente grande para el encabezado válido más grande. - **MBHS-04 (x - “debería”)** _maxBlockHeaderSize_ normalmente solo debería incrementarse si el protocolo cambia. - **MBHS-05 (x - “debería”)** _maxBlockHeaderSize_ debería estar dentro de la ventana de congestión inicial de TCP (3 o 10 MTUs). ### **2.4. Parámetros Técnicos/de Seguridad** Los objetivos generales al gestionar los parámetros técnicos/de seguridad son: 1. Garantizar la seguridad de la red en términos de descentralización y protección contra acciones adversas. 2. Permitir cambios en el lenguaje Plutus. #### **Desencadenantes de Cambio** 1. Cambios en el número de SPOs activos. 2. Cambios al lenguaje Plutus. 3. Amenazas de seguridad. 4. Solicitudes de la Comunidad de Cardano. #### **Contraindicadores** - Preocupaciones económicas, por ejemplo, al cambiar el número de stake pools. #### **Métricas Principales** - Número de stake pools. - Nivel de descentralización. #### **Cambios a Parámetros Técnicos/de Seguridad Específicos** **Número Objetivo de Stake Pools (stakePoolTargetNum)** Establece el número objetivo de stake pools. - El número esperado cuando la red está en equilibrio. - Parámetro de seguridad principalmente, garantizando descentralización. - Grandes cambios provocarán eventos masivos de re-delegación. ##### **GUARDRAILS** - **SPTN-01 (y)** _stakePoolTargetNum_ no debe ser inferior a 250. - **SPTN-02 (y)** _stakePoolTargetNum_ no debe exceder 2,000. - **SPTN-03 (y)** _stakePoolTargetNum_ no debe ser negativo. - **SPTN-04 (y)** _stakePoolTargetNum_ no debe ser cero. **Factor de Influencia de Promesa (poolPledgeInfluence)** Habilita el mecanismo de protección del “pledge” (promesa). Protege contra ataques Sybil. ##### **GUARDRAILS** - **PPI-01 (y)** _poolPledgeInfluence_ no debe ser inferior a 0.1. - **PPI-02 (y)** _poolPledgeInfluence_ no debe exceder 1.0. - **PPI-03 (y)** _poolPledgeInfluence_ no debe ser negativo. - **PPI-04 (x - “debería”)** _poolPledgeInfluence_ no debería variar en más de +/- 10% en un período de 18 épocas (aprox. 3 meses). **Ventana de Retiro del Pool (poolRetireMaxEpoch)** El número máximo de épocas de anticipación que un pool puede dar al planear su retiro. ##### **GUARDRAILS** - **PRME-01 (y)** _poolRetireMaxEpoch_ no debe ser negativo. - **PRME-02 (x - “debería”)** _poolRetireMaxEpoch_ no debería ser menor a 1. **Porcentaje de Colateral (collateralPercentage)** Define cuánto colateral debe proporcionarse al ejecutar un script Plutus como porcentaje del costo normal de ejecución. ##### **GUARDRAILS** - **CP-01 (y)** _collateralPercentage_ no debe ser inferior a 100. - **CP-02 (y)** _collateralPercentage_ no debe exceder 200. - **CP-03 (y)** _collateralPercentage_ no debe ser negativo. - **CP-04 (y)** _collateralPercentage_ no debe ser cero. **Número máximo de entradas de colateral (maxCollateralInputs)** Define el número máximo de entradas (inputs) que pueden usarse para colateral al ejecutar un script Plutus. ##### **GUARDRAILS** - **MCI-01 (y)** _maxCollateralInputs_ no debe ser menor a 1. **Tamaño de Valor Máximo (maxValueSize)** El límite en el tamaño serializado del Valor (Value) en cada salida (output). ##### **GUARDRAILS** - **MVS-01 (y)** _maxValueSize_ no debe exceder 12,288 bytes (12KB). - **MVS-02 (y)** _maxValueSize_ no debe ser negativo. - **MVS-03 (~ - sin acceso a parámetros existentes)** _maxValueSize_ debe ser menor que _maxTxSize_. - **MVS-04 (~ - sin acceso a parámetros existentes)** _maxValueSize_ no debe reducirse. - **MVS-05 (x - sujeto a interpretación)** _maxValueSize_ debe ser lo bastante grande para permitir salidas sensatas. **Modelos de Costos Plutus (costModels)** Definen los costos base para cada primitiva Plutus en CPU y memoria. ##### **GUARDRAILS** - **PCM-01 (x - “no cuantificable”)** Los valores deben establecerse mediante benchmarking en una arquitectura de referencia. - **PCM-02 (x)** El modelo de costos debe actualizarse si se introducen nuevas primitivas o versiones de Plutus. - **PCM-03a (~)** Los valores normalmente no deberían ser negativos. - **PCM-04 (~)** Debe suministrarse un modelo de costos para cada versión de Plutus que soporte el protocolo. ### **2.5. Parámetros de Gobernanza** Los objetivos generales: 1. Garantizar la estabilidad de la gobernanza. 2. Mantener una forma representativa de gobernanza. #### **Desencadenantes de Cambio** 1. Solicitudes de la comunidad. 2. Requisitos regulatorios. 3. Resultados de gobernanza inesperados. 4. Entrar en un estado de falta de confianza. #### **Contraindicadores** - Efectos inesperados en la gobernanza. - Carga excesiva de Capa 1 por votación o exceso de acciones. #### **Métricas Principales** - Niveles de participación. - Comportamientos y patrones. - Consideraciones regulatorias. - Confianza en el sistema. #### **Cambios a Parámetros de Gobernanza Específicos** **Depósito para Acciones de Gobernanza (govDeposit)** El depósito cobrado al enviar una acción. ##### **GUARDRAILS** - **GD-01 (y)** _govDeposit_ no debe ser negativo. - **GD-02 (y)** _govDeposit_ no debe ser inferior a 1,000,000 (1 ada). - **GD-03a (y)** _govDeposit_ no debe exceder 10,000,000,000,000 (10 millones de ada). - **GD-04 (x - “debería”)** _govDeposit_ debería ajustarse en línea con cambios fiduciarios. **Depósito para DReps (dRepDeposit)** ##### **GUARDRAILS** - **DRD-01 (y)** _dRepDeposit_ no debe ser negativo. - **DRD-02 (y)** _dRepDeposit_ no debe ser inferior a 1,000,000 (1 ada). - **DRD-03 (y)** _dRepDeposit_ no debe exceder 100,000,000,000 (100,000 ada). - **DRD-04 (x - “debería”)** Debería ajustarse a los cambios fiduciarios. **Período de Actividad DRep (dRepActivity)** El período (en épocas) tras el cual un DRep se considera inactivo si no vota. ##### **GUARDRAILS** - **DRA-01 (y)** _dRepActivity_ no debe ser inferior a 13 épocas (65 días). - **DRA-02 (y)** _dRepActivity_ no debe exceder 37 épocas (185 días). - **DRA-03 (y)** _dRepActivity_ no debe ser negativo. - **DRA-04 (~)** Debe ser mayor a _govActionLifetime_. - **DRA-05 (x - “debería”)** Debería calcularse en términos humanos. **Umbrales de Acción de Gobernanza (dRepVotingThresholds[…], poolVotingThresholds[…])** Umbrales sobre el stake de votación activo requerido para ratificar una acción. ##### **GUARDRAILS** - **VT-GEN-01 (y)** Todos los umbrales deben ser mayores al 50% y menores o iguales al 100%. - **VT-GEN-02a (y)** Parámetros económicos, de red y de seguridad deben estar entre 51%-75%. - **VT-GEN-03 (y)** Umbrales de gobernanza entre 75%-90%. - **VT-HF-01 (y)** Acciones “Hard Fork Initiation” entre 51%-80%. - **VT-CON-01 (y)** Acciones de “Nueva Constitución” entre 65%-90%. - **VT-CC-01 (y)** Acciones “Update Committee” entre 51%-90%. - **VT-NC-01 (y)** Acciones “No Confidence” entre 51%-75%. **Tiempo de vida de la Acción de Gobernanza (govActionLifetime)** ##### **GUARDRAILS** - **GAL-01 (y)** _govActionLifetime_ no debe ser inferior a 1 época (5 días). - **GAL-03 (x - “debería”)** No debería ser inferior a 2 épocas (10 días). - **GAL-02 (y)** _govActionLifetime_ no debe exceder 15 épocas (75 días). - **GAL-04 (x - “debería”)** Calibrado en términos humanos. - **GAL-05 (~)** Debe ser menor a _dRepActivity_. **Mandato Máximo del Comité Constitucional (committeeMaxTermLength)** ##### **GUARDRAILS** - **CMTL-01a (y)** No debe ser cero. - **CMTL-02a (y)** No debe ser negativo. - **CMTL-03a (y)** No inferior a 18 épocas (90 días). - **CMTL-04a (y)** No exceder 293 épocas (aprox. 4 años). - **CMTL-05a (x - “debería”)** No exceder 220 épocas (aprox. 3 años). **Tamaño Mínimo del Comité Constitucional (committeeMinSize)** ##### **GUARDRAILS** - **CMS-01 (y)** No debe ser negativo. - **CMS-02 (y)** No inferior a 3. - **CMS-03 (y)** No exceder 10. ### **2.6. Monitoreo y Reversión de Cambios de Parámetros** Todos los cambios en parámetros de red deben ser monitoreados cuidadosamente por no menos de 2 épocas (10 días). - Los cambios deben revertirse lo antes posible si los retrasos de propagación superan 4.5s para más del 5% de los bloques sobre cualquier ventana rodante de 6 horas. Se debe producir un plan específico de recuperación/reversión para cada cambio que incluya qué parámetros cambiar y cómo recuperarse en caso de falla desastrosa. ### **2.7. Parámetros de Protocolo No Actualizables** Algunos parámetros fundamentales no pueden ser cambiados por la acción de “Actualización de Parámetros”. Solo pueden cambiarse en un nuevo archivo Génesis como parte de un hard fork. No es necesario proporcionar guardrails específicos para estos. ### **3. Guardrails y Directrices sobre acciones de “Retiros del Tesoro” (“Treasury Withdrawals”)** ##### **GUARDRAILS** - **TREASURY-01a (x)** Un Límite de Cambio Neto por período debe ser acordado por los DReps mediante una acción on-chain con un umbral superior al 50%. - **TREASURY-02a (x)** Los retiros no deben exceder el Límite de Cambio Neto. - **TREASURY-03a (x)** Los retiros deben denominarse en ada. ### **4. Guardrails y Directrices sobre acciones de “Iniciación de Hard Fork”** La acción requiere que se especifique tanto una nueva versión de protocolo principal (mayor) como una menor como números enteros positivos. ##### **GUARDRAILS** - **HARDFORK-01 (~)** La versión principal debe ser la misma o una mayor que la vigente. Si es una mayor, la menor debe ser cero. - **HARDFORK-02a (~)** A menos que la principal cambie, la versión menor debe ser mayor a la vigente. - **HARDFORK-03 (~)** Al menos una de las versiones (principal o menor o ambas) debe cambiar. - **HARDFORK-04a (x)** Al menos el 85% de los stake pools por stake activo deberían haber actualizado a un nodo capaz de procesar las reglas de la nueva versión. - **HARDFORK-05 (x)** Cualquier parámetro nuevo introducido debe incluirse en este Apéndice con guardrails adecuados. - **HARDFORK-06 (x)** Las configuraciones de nuevos parámetros deben incluirse en el archivo Génesis apropiado. - **HARDFORK-07 (x)** Cualquier parámetro depreciado debe indicarse. - **HARDFORK-08 (~)** Las nuevas versiones Plutus deben estar respaldadas por un modelo de costos específico de la versión. ### **5. Guardrails y Directrices sobre acciones de “Actualizar Comité”** ##### **GUARDRAILS** - **UPDATE-CC-01a (x)** Estas acciones no deben ser ratificadas hasta que los propietarios de ada hayan ratificado esta Constitución mediante una acción on-chain. ### **6. Guardrails y Directrices sobre acciones de “Nueva Constitución”** ##### **GUARDRAILS** - **NEW-CONSTITUTION-01a (x)** Debe presentarse esta acción para definir los guardrails requeridos para nuevos parámetros introducidos vía Hard Fork. - **NEW-CONSTITUTION-02 (x)** Si se especifica, el nuevo Script de Guardrails debe ser coherente con esta Constitución. ### **7. Guardrails y Directrices sobre acciones de “Falta de Confianza”** No se imponen guardrails a las acciones de “Falta de Confianza” (_No Confidence_). - Ninguno. ### **8. Guardrails y Directrices sobre acciones de “Info”** Las acciones de “Info” no se promulgan on-chain. No se imponen guardrails. - Ninguno. ### **9. Lista de Grupos de Parámetros de Protocolo** Los parámetros de protocolo se agrupan por tipo, permitiendo que se establezcan diferentes umbrales para cada grupo. El grupo de parámetros de red consiste en: - _tamaño máximo del cuerpo del bloque_ (_maxBlockBodySize_) - _tamaño máximo de transacción_ (_maxTxSize_) - _tamaño máximo del encabezado del bloque_ (_maxBlockHeaderSize_) - _tamaño máximo de un valor de activo serializado_ (_maxValueSize_) - _unidades máximas de ejecución de script en una sola transacción_ (_maxTxExecutionUnits[steps]_) - _unidades máximas de ejecución de script en un solo bloque_ (_maxBlockExecutionUnits[steps]_) - _número máximo de entradas de colateral_ (_maxCollateralInputs_) El grupo de parámetros económicos consiste en: - _coeficiente de tarifa mínima_ (_txFeePerByte_) - _constante de tarifa mínima_ (_txFeeFixed_) - _tarifa mínima por byte para scripts de referencia_ (_minFeeRefScriptCoinsPerByte_) - _depósito en lovelace de clave de delegación_ (_stakeAddressDeposit_) - _depósito en lovelace de registro de pool_ (_stakePoolDeposit_) - _expansión monetaria_ (_monetaryExpansion_) - _expansión del tesoro_ (_treasuryCut_) - _corte fijo mínimo de recompensas para pools_ (_minPoolCost_) - _depósito mínimo de lovelace por byte de UTxO serializado_ (_coinsPerUTxOByte_) - _precios de unidades de ejecución Plutus_ (_executionUnitPrices[priceSteps/priceMemory]_) El grupo de parámetros técnicos/de seguridad consiste en: - _influencia de promesa del pool_ (_poolPledgeInfluence_) - _época máxima de retiro del pool_ (_poolRetireMaxEpoch_) - _número deseado de pools_ (_stakePoolTargetNum_) - _modelos de costos de ejecución Plutus_ (_costModels_) - _proporción de colateral necesario para scripts_ (_collateralPercentage_) El grupo de parámetros de gobernanza consiste en: - _umbrales de votación de gobernanza_ (_dRepVotingThresholds[…], poolVotingThresholds[…]_) - _tiempo de vida máximo de la acción de gobernanza en épocas_ (_govActionLifetime_) - _depósito de acción de gobernanza_ (_govDeposit_) - _cantidad de depósito de DRep_ (_dRepDeposit_) - _período de actividad de DRep en épocas_ (_dRepActivity_) - _tamaño mínimo del Comité Constitucional_ (_committeeMinSize_) - _duración máxima del mandato (en épocas) para los miembros del Comité Constitucional_ (_committeeMaxTermLength_) ## **APÉNDICE II. ORIENTACIÓN DE APOYO** Este Apéndice II tiene como objetivo proporcionar orientación en la interpretación de la Constitución, y el Comité Constitucional deberá considerar este Apéndice II como lo estime pertinente y útil para llevar a cabo sus deberes constitucionales. ### **1. Notas de Contextualización (Framing Notes)** La Blockchain de Cardano se estableció en 2017. En julio de 2020 se expandió para incluir validadores de bloques independientes y en septiembre de 2024 se introdujo un sistema de gobernanza on-chain. Esta Constitución describe los derechos y responsabilidades de los actores de gobernanza en el sistema descentralizado que representan a los propietarios de ada; ada es el token de gobernanza de la Blockchain de Cardano. La Blockchain de Cardano es un ecosistema descentralizado de tecnología blockchain, contratos inteligentes y gobernanza comunitaria. Al abordar esta Constitución, la Comunidad de Cardano reconoce que no se trata de una constitución solo para una blockchain, sino más bien de una constitución para un ecosistema de blockchain. En consecuencia, la forma en que se aprueban las acciones de gobernanza, si bien es extremadamente importante, no es el único enfoque de esta Constitución. Más bien, esta Constitución proporciona la base y el marco fundamental mediante el cual todos los participantes de la Comunidad de Cardano pueden unirse para autogobernarse y formar nuevos enfoques para la interacción y colaboración humanas. Por necesidad, esta Constitución reconoce el papel y empodera al Comité Constitucional, confirma el derecho de la Comunidad de Cardano a participar en cuerpos colectivos para la colaboración, da efecto a la gobernanza on-chain, y empodera a los DReps -incluidos los propietarios de ada que actúan directamente como DReps- para actuar como la voz de los propietarios de ada en la votación on-chain. La Constitución también reconoce la necesidad de salvaguardar el acceso y el uso de los fondos del tesoro de la Blockchain de Cardano mediante la inclusión de los Guardrails de la Blockchain de Cardano en esta Constitución. ### **2. Otra Orientación** Los redactores de la Constitución, junto con otros participantes de la Comunidad de Cardano, han publicado y en el futuro pueden publicar orientación para la interpretación de la Constitución, incluyendo, entre otros, un folleto de definiciones que ha sido publicado de manera contemporánea con la ratificación on-chain de la Constitución. Siempre que dicha orientación publicada haya sido convertida en hash e introducida en la Blockchain de Cardano a través de una acción de “Info”, al Comité Constitucional no se le impedirá considerar y utilizar dicha orientación como lo considere apropiado.