Esta es una traducción de la documentación de gobernanza de Arbitrum Foundation.

Esta Constitución del ArbitrumDAO entra en vigor en la fecha en que se publica AIP-1, ubicada en https://forum.arbitrum.foundation/t/aip-1-arbitrum-improvement-proposal-framework/30.

Algunas de las reglas y procedimientos de esta Constitución se aplicarán directamente mediante smart contracts en una Blockchain, y otros no. Todas las normas son igualmente vinculantes. Las medidas adoptadas en virtud de esta Constitución pueden ser acciones on-chain u off-chain. Las acciones on-chain son aquellas que son accionadas directamente por los smart contracts de gobierno de la DAO como transacciones en una Blockchain. Las acciones off-chain son aquellas que se accionan por otros medios.

Esta Constitución también incluye algunas "directrices recomendadas" que no son vinculantes pero que se recomiendan encarecidamente como práctica de buena gobernanza

Esta Constitución describe los procedimientos por los cuales puede ser enmendada. Para obtener más información sobre el framework de gobernanzade ArbitrumDAO y Arbitrum Foundation, consulte AIP-1.

Definiciones:

• AIP: Arbitrum Improvement Proposal (Propuesta de mejora de Arbitrum)

• AIP-1: Arbitrum Improvement Proposal- 1: Arbitrum Proposal Framework

• Chains gobernadas por ArbitrumDAO: Las chains  Arbitrum One y Arbitrum Nova y cualquier chain adicional autorizada por ArbitrumDAO

• DAO Treasury: Todos los tokens $ARB mantenidos en un smart contract de la gobernanza gobernado directamente por ArbitrumDAO y The Arbitrum Foundation a través de mecanismos de votación on-chain.

• Chains gobernadas: cualquier chainaprobada por ArbitrumDAO que se rija por el token $ARB

• Chains no gobernadas: cualquier chain aprobada por ArbitrumDAO que no esté gobernada por el token $ARB

• Tokens votables: Todos los tokens $ARB existentes, excluyendo cualquier token en poder de The Arbitrum Foundation y cualquier airdrop no reclamado.

Esta Constitución describe el framework de la toma de decisiones para la gobernanza de ArbitrumDAO y/o la autorización de las chains aprobadas por ArbitrumDAO. La DAO puede autorizar la creación de chains adicionales de Layer-2 que se asienten en Ethereum utilizando la tecnología Arbitrum, pero cada chain adicional de Layer-2 debe ser autorizada por un AIP correspondiente (es decir, no se puede autorizar más de una chain en cada AIP). Cualquier chain que esté autorizada puede regirse por el token $ARB y esta Constitución y los procedimientos descritos en AIP-1, en cuyo caso, dicha chain se considerará una chain gobernada. Cualquier chain que esté autorizada pero no gobernada por el token $ARB se considerará una chain no gobernada. Para evitar dudas, cualquier chain aprobada por ArbitrumDAO (ya sea una chain gobernada o una chain no gobernada) debe establecerse en sobre Ethereum. Las chains que utilizan la tecnología Arbitrum que se asientan en o sobre chains aprobadas por ArbitrumDAO (es decir, como "Layer 3") no requieren autorización de ArbitrumDAO.

El protocolo Arbitrum permite que cada chain tenga uno o más "chain owner" que tienen el poder de tomar medidas administrativas que cambian el protocolo y el código central de una chain y / o alteran cualquiera de sus parámetros centrales. El "chain owner"  también tendrá el poder de actualizar ciertos contratos de Layer 1 asociados. El "chain owner" controlará las posibilidades en la chain, como actualizar la implementación del contrato de cualquiera de los Transparent Upgradeable Proxy contracts del protocolo central de Arbitrum y ajustar los parámetros del sistema a través de, por ejemplo, métodos de configuración en la precompilación de ArbOwner.

Con el evento de generación de tokens $ARB y la posterior creación del ArbitrumDAO, se han otorgado privilegios de "owner" en las chain Arbitrum One y Arbitrum Nova tanto a ArbitrumDAO como al Security Council de The Arbitrum Foundation.

El siguiente proceso rige las reglas y procedimientos por los cuales ArbitrumDAO puede proponer, votar e implementar Arbitrum Improvement Proposals (AIP). Ningún AIP puede estar violando las leyes aplicables, en particular las regulaciones relacionadas con las sanciones.

**     Fase 1: Temperature Check(1 semana) (opcional pero recomendado): **El AIP se      sugiere en el foro público y se discute / debate durante 1 semana. El AIP debe ir      acompañado de una encuesta (poll) Snapshot u otro método determinado de      conformidad con el proceso de gobernanza, que solo puede ser enviado por una      dirección que pueda votar al menos el 0.01% de los tokens votables. La encuesta      Snapshot también dura 1 semana y se decide por mayoría simple sin umbral de      participación requerido. Un AIP que no pase el temperature check no debe      someterse a votación. Si un AIP no pasa el temperature check, o no se ha sometido      a un temperature check, como una cuestión de buena práctica de gobernanza, se      recomienda que los votantes consideren seriamente votar para rechazarlo.

**     Fase 2:** AIP formal y convocatoria de votación (3 días): El AIP se envía a través del      governance contracts en Arbitrum One, con una interfaz de usuario disponible en      Tally. Se requiere que el proponente de AIP tenga una dirección a la que se le      deleguen al menos 1,000,000 de tokens votables.

Después de 3 días, se tomará un snapshot de la distribución de votantes y comenzará el período de votación; esto da a las partes interesadas tiempo para discutir el AIP y reunir votos antes de que se tome snapshot de distribución de votantes.

Cada AIP debe ser etiquetado como constitucional o no constitucional.

Un AIP constitucional es aquel que:

• Process: Modifica el texto o procedimientos de esta Constitución o AIP-1

• Software update: instala o modifica software en cualquier chain

• Core: realiza cualquier acción que requiera permiso de "Chain owner" en cualquier chain

• New Chain Approval: Autoriza una nueva chain según lo aprobado por el ArbitrumDAO. Esto incluye autorizar tanto chains gobernadas como chains no gobernadas

Directriz recomendada: Los miembros de DAO deben votar en contra de cualquier AIP que esté etiquetado incorrectamente.

Un AIP no constitucional es aquel que no se considera un "AIP constitucional", incluyendo:

• Funding: Solicita fondos/subvenciones o propone de otro modo cómo gastar o asignar fondos del DATreasury en poder de The Arbitrum Foundation

• Informational: proporciona directrices generales o información a la comunidad, pero no propone una nueva característica o actualización.

Cada AIP también debe especificar claramente a qué chain(s) gobernada(s) afectará(n) (esto puede especificarse mediante código, datos o texto, según corresponda para el AIP específico).

Como guía recomendada, un AIP debe incluir:

• Abstract (resumen)- Dos o tres oraciones que resuman el AIP.

• Motivation (motivación) - Una declaración sobre por qué la comunidad de Arbitrum debería implementar el AIP.

• Rationale (justificación) - Una explicación de cómo el AIP se alinea con la misión y los valores rectores de la comunidad de Arbitrum.

• Key terms (Términos clave), (opcional): definiciones de cualquier término dentro de la propuesta que sea exclusivo de la propuesta, nuevo para la comunidad de Arbitrum y / o específico de la industria.

• Specifications (especificaciones) - Un desglose detallado de las plataformas y tecnologías que se utilizarán.

• Steps to implement (pasos a implementar) - Los pasos a implementar en el AIP, incluidos los costos asociados, la mano de obra y otros recursos para cada paso cuando corresponda. Para evitar dudas, cualquier AIP que implique transacciones con terceros (como Grants) deberá asegurarse de que también se incluyan la documentación y los procedimientos legales aplicables.

• Timeline (cronograma): detalles de tiempo relevantes, incluidos, entre otros, la fecha de inicio, los hitos y las fechas de finalización.

• Overall Cost (costo total) - El costo total para implementar el AIP.

Como guía recomendada, el autor del AIP puede agregar campos adicionales a cualquier plantilla si es necesario para comunicar completamente las intenciones, detalles e implicaciones del AIP.

Como directriz recomendada, los AIP que se vuelven a presentar también deben incluir:

• Un enlace al AIP original;

• Razones por las que la AIP original no fue aprobado;

• Los cambios que se han realizado y por qué ahora debería aprobarse; y

Cualquier campo adicional a cualquier plantilla si es necesario para comunicar completamente los cambios realizados y las intenciones, detalles e implicaciones de dicho AIP reenviado.

**     Fase 3: DAO vota sobre AIP, sobre Arbitrum One (14-16 días): Durante esta Fase 3,      ArbitrumDAO podrá votar directamente on-chain sobre un AIP presentado.**

Un AIP pasa si se cumplen las siguientes 2 condiciones:

A. Una mayoria de tokens votables han emitido votos "a favor" que votos "en contra      ("Threshold 1"); y

B. En el caso de:

• AIP constitucional, al menos el 5% de todos los tokens votables han emitido votos "a favor"; o

• AIP no constitucional, al menos el 3% de todos los tokens votables han emitido votos "a favor" (colectivamente, "Threshold 2").

El período de votación termina 14 días después del inicio de la votación. Sin embargo, si se alcanzó el Threshold 2 dentro de los últimos 2 días del período de votación de 14 días, el período de votación se extenderá hasta el final 2 días después de que se alcanzó el Umbral 2.

Si el AIP no se aprueba, el proceso finaliza después de esta Fase 3.

Si el AIP pasa, entonces:

• Si se trata de un AIP constitucional, se llevan a cabo las fases 4 a 7 a continuación.

• Si se trata de un AIP no constitucional, se lleva a cabo la Fase 4, y luego se omiten las Fases 5 y 6, después de lo cual el AIP entra en la Fase 7 inmediatamente.

**     Fase 4: Período de espera L2 (3 días)**: Después de que un AIP ha pasado la Fase 3,      se produce un período de espera de 3 días. Esto les da a los usuarios que se      oponen al AIP tiempo para iniciar el retiro de sus fondos o tomar otras medidas en      L2.

**     Fase 5: Iniciar y finalizar un mensaje de L2 a L1 (al menos 1 período de challenge      del rollup)**: una vez transcurrido el período de espera de 3 días en la fase 4, se envía      un mensaje de L2 a L1 que indica que se ha superado el AIP. Cuando este mensaje      se finaliza en L1, cualquiera puede redimirlopara completar este paso e iniciar el      siguiente paso. Este paso asegura que la finalización del período de espera L2 se      reconocerá en L1 después de que cualquier retiro iniciado durante o poco después      del período de votación haya sido reconocido en L1.

**     Fase 6: Período de espera L1 (3 días)**: Después de la finalización de la Fase 5, habrá      un período de espera adicional de 3 días. Esto garantiza que los usuarios que      iniciaron retiros u otros mensajes de L2 a L1 tengan tiempo para ejecutarlos en L1      antes de que el AIP entre en vigencia.

**     Fase 7: Implementación**: El AIP está completamente ejecutado e implementado.      Esto puede suceder en L1 o a través de una transacción enviada desde L1 a una o      más Chains Gobernadas.

Este proceso AIP como se especifica generalmente requerirá 37 días desde el comienzo del control en la Fase 1 hasta que finalmente se ejecute un AIP en la Fase 7 para un AIP constitucional, o 27 días para un AIP no constitucional. Un AIP puede especificar opcionalmente un retraso adicional antes de su implementación.

El Consejo de Seguridad es un comité de 12 miembros que son firmantes de una multi-sig wallet, que tiene poderes para realizar ciertas Acciones de Emergencia y Acciones de No Emergencia, según lo delegado por AbitrumDAO y la Arbitrum Fundation, y es responsable de defender esta Constitución de ArbitrumDAO. A través de la presentación, aprobación e implementación de un AIP Constitucional, ArbitrumDAO puede modificar los poderes del Security Councilo eliminar el Security Council por completo.

Existen "copias" equivalentes de los contratos multi-sig del Security Council, uno en Ethereum y otro en cada chain gobernada por ArbitrumDAO.

Acciones de emergencia:

El Security Council tiene la facultad de ejecutar cualquier actualización de software o realizar otras acciones necesarias sin demora para responder a una emergencia de seguridad, en caso de que surja (tales acciones, "Acciones de emergencia"). La realización de cualquier acción de emergencia requiere una aprobación de 9 de 12 del Security Council. El Security Council no debe usar su poder para realizar Acciones de Emergencia excepto en una verdadera emergencia de seguridad, como una vulnerabilidad crítica que podría comprometer significativamente la integridad, confidencialidad o disponibilidad de una chain gobernada por el ArbitrumDAO.

Después de realizar cualquier acción de emergencia, el Security Council debe emitir un informe de transparencia completo (en un momento apropiado después de que la emergencia de seguridad haya pasado) para explicar lo que se hizo y por qué se justificó dicha acción de emergencia.

ArbitrumDAO puede restringir o eliminar el poder del Security Council para realizar Acciones de Emergencia a través de la aprobación e implementación de un AIP Constitucional.

Acciones que no sean de emergencia:

El Security Council también puede aprobar e implementar actualizaciones rutinarias de software, mantenimiento de rutina y otros ajustes de parámetros en un entorno que no sea de emergencia (tales acciones, "Acciones que no sean de emergencia"), que requieren una aprobación 7 de 12 para que tengan efecto. Cualquier acción que no sea de emergencia, después de la aprobación del Security Council, omitirá las Fases 1 a 3 del proceso AIP y, en su lugar, pasará directamente por las Fases 4 a 7 del proceso AIP, para proporcionar un delay antes de que se despliegue cualquier acción que no sea de emergencia. El Consejo de Seguridad puede especificar opcionalmente demoras adicionales antes del despliegue.

ArbitrumDAO puede restringir o eliminar el poder del Security Council para realizar acciones que no sean de emergencia a través de la aprobación e implementación de un AIP constitucional.

El Security Council tiene 12 miembros, que se dividen en una September Cohort de 6 miembros y una March Cohort de 6 miembros. Cada año, el 15 de septiembre, a las 12:00 UTC, comienza una elección para los lugares de la cohorte del 6 de septiembre; y cada año, el 15 de marzo, a las 12:00 UTC, comienza una elección para los lugares de la cohorte del 6 de marzo.

Esto significa que la cohorte inicial de septiembre servirá un término inicial de 6 meses, mientras que la cohorte inicial de marzo servirá un término inicial de 1 año.

Las cohortes iniciales del Security Council se determinaron dividiendo aleatoriamente a los 12 miembros en dos cohortes de 6 miembros: 6 miembros en la cohorte de septiembre y 6 miembros en la cohorte de marzo. Los miembros de las cohortes iniciales del Security Council se detallan en AIP-1.

La siguiente línea de tiempo rige una elección que comienza en el tiempo T:

1. Desde T hasta T+7 días: Cualquier miembro de DAO puede declarar su candidatura al Security Council; sin embargo, un miembro actual del Security Council en una cohorte no puede ser candidato a un puesto en la otra cohorte. En la medida en que haya más de seis candidatos, cada candidato elegible debe estar respaldado por votos comprometidos que representen al menos el 0.2% de todos los tokens votables. En el caso de que menos de seis candidatos sean apoyados por votos comprometidos que representen al menos el 0.2% de todos los tokens votables, los miembros actuales del Security Council cuyos lugares estén disponibles para la elección pueden convertirse en candidatos (seleccionados al azar de su cohorte) hasta que haya 6 candidatos.

2. Desde T+7 días hasta T+28 días: Cada miembro o delegado de DAO puede votar por cualquier candidato declarado. Cada token puede ser emitido para un candidato. Los votos emitidos antes de T+14 días tendrán el 100% de peso (weight). Los votos emitidos entre T+14 días y T+28 días tendrán peso en función del momento de la emisión, disminuyendo linealmente con el tiempo, con un peso del 100% a T+14 días, disminuyendo linealmente al 0% de peso a T+28 días.

3. A T+28 días: Los 6 candidatos que han recibido más votos son elegidos e inmediatamente se unen al Council, reemplazando a la Cohorte que se presentaba a la reelección.

Antes de la próxima elección del Consejo de Seguridad, la Arbitrum Foundation establecerá procedimientos y pautas más detallados con respecto al proceso de elección para el Security Council, que pueden incluir, entre otros, un proceso de admisión de candidatos para cumplir con las leyes de las Islas Caimán, una plantilla estándar para que los candidatos completen a los fines de sus nominaciones públicas y otros procesos para garantizar un Elecciones justas y transparentes.

Como cuestión de práctica óptima para mantener un Security Council independiente, ninguna organización debe estar excesivamente representada en el Security Council. En particular, no debe haber más de 3 candidatos asociados con una sola entidad o grupo de entidades elegidas para el Security Council, asegurando así que no haya una sola entidad o grupo de entidades capaz de controlar o incluso vetar una votación del Security Council.

Además, ningún candidato con conflictos de intereses que le impida actuar en el mejor interés de ArbitrumDAO, Governed Chains y/o The Arbitrum Foundation debe ser elegido para el Security Council. Los posibles conflictos de intereses podrían ser, pero no se limitan a, afiliaciones con competidores directos de Arbitrum, historias comprobadas de exploits de proyectos y otros.

La DAO puede aprobar e implementar un AIP Constitucional para cambiar las reglas que rigen las futuras elecciones del Security Council, pero el proceso AIP no puede usarse para intervenir en una elección en curso.

Los miembros del Security Council sólo pueden ser destituidos antes de que finalice su mandato bajo dos condiciones:

1. Al menos el 10% de todos los tokens votables han emitido votos "a favor" de la eliminación y al menos 5/6 de todos los votos emitidos son "a favor" de la eliminación; o

2. Al menos 9 de los miembros del Security Councilvotan a favor de la remoción.

Los puestos de los miembros del Consejo de Seguridad que hayan sido destituidos antes de que concluyan sus respectivos mandatos permanecerán vacantes hasta la próxima elección en que esos puestos hayan de ser nombrados, a menos que se sustituyan de otro modo antes de la siguiente elección por una votación de al menos 9 de los miembros del Security Council, en cuyo caso ese puesto se nombrará en la siguiente elección.

Como los valores rectores de ArbitrumDAO y The Arbitrum Foundation, las cadenas gobernadas, la tecnología y la comunidad deben ser:

• Ethereum-aligned: Arbitrum es parte del ecosistema Ethereum, y la comunidad Arbitrum es parte de la comunidad Ethereum. Aunque ArbitrumDAO toma sus propias decisiones y persigue sus propios objetivos, está profundamente alineado con Ethereum y se ve a sí mismo como un participante activo y constructivo en la comunidad Ethereum.

• Sostenible: Arbitrum debe construirse y operarse con miras al mediano y largo plazo. Las decisiones sobre tecnología, economía y asignación de recursos no deben valorar la optimización a corto plazo sobre la salud a largo plazo y la prosperidad del protocolo, la tecnología y la comunidad de Arbitrum.

• Seguro: Arbitrum tiene una mentalidad de seguridad, y la seguridad del sistema debe pesar  mucho al considerar cualquier cambio de protocolo. En particular, Arbitrum One es una rollup chain L2 adecuada, y como tal, deriva su seguridad de Ethereum; cualquier cambio realizado en Arbitrum One debe preservar esta propiedad.

• Socialmente inclusiva: La comunidad debe ser abierta y acogedora para todas las personas que deseen participar constructivamente. Las diferencias en el conocimiento, los recursos, la geografía, el idioma y la experiencia de vida deben verse como oportunidades para aprender y hacer crecer la comunidad.

• Técnicamente inclusivo: Debería seguir siendo posible que la gente común, con sistemas informáticos ordinarios, participe lo más plenamente posible en el protocolo Arbitrum si así lo desea.

• Centrado en el usuario: El ecosistema de Arbitrum debe gestionarse en beneficio de todos los usuarios de Arbitrum.

• Neutral y abierta: La gobernanza de Arbitrum no debe elegir ganadores y perdedores, sino que debe fomentar la innovación abierta, la interoperación, la elección del usuario y la competencia sana en las cadenas de Arbitrum.

0x5e5d9153e6d9b0c1e88187d31468f0a7fa096aff9f4d538d27619798db6522e7

Para calcular este hash usted mismo, puede clonar ArbitrumFoundation/docs en su máquina local y ejecutar yarn update-constition-hash desde el root del repositorio. Alternativamente, puede instalar Node.js, navegar a la carpeta docs y ejecutar node ./scripts/updateConstitutionHash.js.

Esto usará el método keccak256 del proyecto @ethersproject/solidity para calcular el hash del código fuente de markdown de la Constitución, ubicado en /ArbitrumFoundation/docs/blob/main/docs/partials/_constitution-content-partial.md.

Esta es una traducción de la documentación de gobernanza de Arbitrum Foundation.

Esta Constitución del ArbitrumDAO entra en vigor en la fecha en que se publica AIP-1, ubicada en https://forum.arbitrum.foundation/t/aip-1-arbitrum-improvement-proposal-framework/30.

Algunas de las reglas y procedimientos de esta Constitución se aplicarán directamente mediante smart contracts en una Blockchain, y otros no. Todas las normas son igualmente vinculantes. Las medidas adoptadas en virtud de esta Constitución pueden ser acciones on-chain u off-chain. Las acciones on-chain son aquellas que son accionadas directamente por los smart contracts de gobierno de la DAO como transacciones en una Blockchain. Las acciones off-chain son aquellas que se accionan por otros medios.

Esta Constitución también incluye algunas "directrices recomendadas" que no son vinculantes pero que se recomiendan encarecidamente como práctica de buena gobernanza

Esta Constitución describe los procedimientos por los cuales puede ser enmendada. Para obtener más información sobre el framework de gobernanzade ArbitrumDAO y Arbitrum Foundation, consulte AIP-1.

Definiciones:

• AIP: Arbitrum Improvement Proposal (Propuesta de mejora de Arbitrum)

• AIP-1: Arbitrum Improvement Proposal- 1: Arbitrum Proposal Framework

• Chains gobernadas por ArbitrumDAO: Las chains  Arbitrum One y Arbitrum Nova y cualquier chain adicional autorizada por ArbitrumDAO

• DAO Treasury: Todos los tokens $ARB mantenidos en un smart contract de la gobernanza gobernado directamente por ArbitrumDAO y The Arbitrum Foundation a través de mecanismos de votación on-chain.

• Chains gobernadas: cualquier chainaprobada por ArbitrumDAO que se rija por el token $ARB

• Chains no gobernadas: cualquier chain aprobada por ArbitrumDAO que no esté gobernada por el token $ARB

• Tokens votables: Todos los tokens $ARB existentes, excluyendo cualquier token en poder de The Arbitrum Foundation y cualquier airdrop no reclamado.

Esta Constitución describe el framework de la toma de decisiones para la gobernanza de ArbitrumDAO y/o la autorización de las chains aprobadas por ArbitrumDAO. La DAO puede autorizar la creación de chains adicionales de Layer-2 que se asienten en Ethereum utilizando la tecnología Arbitrum, pero cada chain adicional de Layer-2 debe ser autorizada por un AIP correspondiente (es decir, no se puede autorizar más de una chain en cada AIP). Cualquier chain que esté autorizada puede regirse por el token $ARB y esta Constitución y los procedimientos descritos en AIP-1, en cuyo caso, dicha chain se considerará una chain gobernada. Cualquier chain que esté autorizada pero no gobernada por el token $ARB se considerará una chain no gobernada. Para evitar dudas, cualquier chain aprobada por ArbitrumDAO (ya sea una chain gobernada o una chain no gobernada) debe establecerse en sobre Ethereum. Las chains que utilizan la tecnología Arbitrum que se asientan en o sobre chains aprobadas por ArbitrumDAO (es decir, como "Layer 3") no requieren autorización de ArbitrumDAO.

El protocolo Arbitrum permite que cada chain tenga uno o más "chain owner" que tienen el poder de tomar medidas administrativas que cambian el protocolo y el código central de una chain y / o alteran cualquiera de sus parámetros centrales. El "chain owner"  también tendrá el poder de actualizar ciertos contratos de Layer 1 asociados. El "chain owner" controlará las posibilidades en la chain, como actualizar la implementación del contrato de cualquiera de los Transparent Upgradeable Proxy contracts del protocolo central de Arbitrum y ajustar los parámetros del sistema a través de, por ejemplo, métodos de configuración en la precompilación de ArbOwner.

Con el evento de generación de tokens $ARB y la posterior creación del ArbitrumDAO, se han otorgado privilegios de "owner" en las chain Arbitrum One y Arbitrum Nova tanto a ArbitrumDAO como al Security Council de The Arbitrum Foundation.

El siguiente proceso rige las reglas y procedimientos por los cuales ArbitrumDAO puede proponer, votar e implementar Arbitrum Improvement Proposals (AIP). Ningún AIP puede estar violando las leyes aplicables, en particular las regulaciones relacionadas con las sanciones.

**     Fase 1: Temperature Check(1 semana) (opcional pero recomendado): **El AIP se      sugiere en el foro público y se discute / debate durante 1 semana. El AIP debe ir      acompañado de una encuesta (poll) Snapshot u otro método determinado de      conformidad con el proceso de gobernanza, que solo puede ser enviado por una      dirección que pueda votar al menos el 0.01% de los tokens votables. La encuesta      Snapshot también dura 1 semana y se decide por mayoría simple sin umbral de      participación requerido. Un AIP que no pase el temperature check no debe      someterse a votación. Si un AIP no pasa el temperature check, o no se ha sometido      a un temperature check, como una cuestión de buena práctica de gobernanza, se      recomienda que los votantes consideren seriamente votar para rechazarlo.

**     Fase 2:** AIP formal y convocatoria de votación (3 días): El AIP se envía a través del      governance contracts en Arbitrum One, con una interfaz de usuario disponible en      Tally. Se requiere que el proponente de AIP tenga una dirección a la que se le      deleguen al menos 1,000,000 de tokens votables.

Después de 3 días, se tomará un snapshot de la distribución de votantes y comenzará el período de votación; esto da a las partes interesadas tiempo para discutir el AIP y reunir votos antes de que se tome snapshot de distribución de votantes.

Cada AIP debe ser etiquetado como constitucional o no constitucional.

Un AIP constitucional es aquel que:

• Process: Modifica el texto o procedimientos de esta Constitución o AIP-1

• Software update: instala o modifica software en cualquier chain

• Core: realiza cualquier acción que requiera permiso de "Chain owner" en cualquier chain

• New Chain Approval: Autoriza una nueva chain según lo aprobado por el ArbitrumDAO. Esto incluye autorizar tanto chains gobernadas como chains no gobernadas

Directriz recomendada: Los miembros de DAO deben votar en contra de cualquier AIP que esté etiquetado incorrectamente.

Un AIP no constitucional es aquel que no se considera un "AIP constitucional", incluyendo:

• Funding: Solicita fondos/subvenciones o propone de otro modo cómo gastar o asignar fondos del DATreasury en poder de The Arbitrum Foundation

• Informational: proporciona directrices generales o información a la comunidad, pero no propone una nueva característica o actualización.

Cada AIP también debe especificar claramente a qué chain(s) gobernada(s) afectará(n) (esto puede especificarse mediante código, datos o texto, según corresponda para el AIP específico).

Como guía recomendada, un AIP debe incluir:

• Abstract (resumen)- Dos o tres oraciones que resuman el AIP.

• Motivation (motivación) - Una declaración sobre por qué la comunidad de Arbitrum debería implementar el AIP.

• Rationale (justificación) - Una explicación de cómo el AIP se alinea con la misión y los valores rectores de la comunidad de Arbitrum.

• Key terms (Términos clave), (opcional): definiciones de cualquier término dentro de la propuesta que sea exclusivo de la propuesta, nuevo para la comunidad de Arbitrum y / o específico de la industria.

• Specifications (especificaciones) - Un desglose detallado de las plataformas y tecnologías que se utilizarán.

• Steps to implement (pasos a implementar) - Los pasos a implementar en el AIP, incluidos los costos asociados, la mano de obra y otros recursos para cada paso cuando corresponda. Para evitar dudas, cualquier AIP que implique transacciones con terceros (como Grants) deberá asegurarse de que también se incluyan la documentación y los procedimientos legales aplicables.

• Timeline (cronograma): detalles de tiempo relevantes, incluidos, entre otros, la fecha de inicio, los hitos y las fechas de finalización.

• Overall Cost (costo total) - El costo total para implementar el AIP.

Como guía recomendada, el autor del AIP puede agregar campos adicionales a cualquier plantilla si es necesario para comunicar completamente las intenciones, detalles e implicaciones del AIP.

Como directriz recomendada, los AIP que se vuelven a presentar también deben incluir:

• Un enlace al AIP original;

• Razones por las que la AIP original no fue aprobado;

• Los cambios que se han realizado y por qué ahora debería aprobarse; y

Cualquier campo adicional a cualquier plantilla si es necesario para comunicar completamente los cambios realizados y las intenciones, detalles e implicaciones de dicho AIP reenviado.

**     Fase 3: DAO vota sobre AIP, sobre Arbitrum One (14-16 días): Durante esta Fase 3,      ArbitrumDAO podrá votar directamente on-chain sobre un AIP presentado.**

Un AIP pasa si se cumplen las siguientes 2 condiciones:

A. Una mayoria de tokens votables han emitido votos "a favor" que votos "en contra      ("Threshold 1"); y

B. En el caso de:

• AIP constitucional, al menos el 5% de todos los tokens votables han emitido votos "a favor"; o

• AIP no constitucional, al menos el 3% de todos los tokens votables han emitido votos "a favor" (colectivamente, "Threshold 2").

El período de votación termina 14 días después del inicio de la votación. Sin embargo, si se alcanzó el Threshold 2 dentro de los últimos 2 días del período de votación de 14 días, el período de votación se extenderá hasta el final 2 días después de que se alcanzó el Umbral 2.

Si el AIP no se aprueba, el proceso finaliza después de esta Fase 3.

Si el AIP pasa, entonces:

• Si se trata de un AIP constitucional, se llevan a cabo las fases 4 a 7 a continuación.

• Si se trata de un AIP no constitucional, se lleva a cabo la Fase 4, y luego se omiten las Fases 5 y 6, después de lo cual el AIP entra en la Fase 7 inmediatamente.

**     Fase 4: Período de espera L2 (3 días)**: Después de que un AIP ha pasado la Fase 3,      se produce un período de espera de 3 días. Esto les da a los usuarios que se      oponen al AIP tiempo para iniciar el retiro de sus fondos o tomar otras medidas en      L2.

**     Fase 5: Iniciar y finalizar un mensaje de L2 a L1 (al menos 1 período de challenge      del rollup)**: una vez transcurrido el período de espera de 3 días en la fase 4, se envía      un mensaje de L2 a L1 que indica que se ha superado el AIP. Cuando este mensaje      se finaliza en L1, cualquiera puede redimirlopara completar este paso e iniciar el      siguiente paso. Este paso asegura que la finalización del período de espera L2 se      reconocerá en L1 después de que cualquier retiro iniciado durante o poco después      del período de votación haya sido reconocido en L1.

**     Fase 6: Período de espera L1 (3 días)**: Después de la finalización de la Fase 5, habrá      un período de espera adicional de 3 días. Esto garantiza que los usuarios que      iniciaron retiros u otros mensajes de L2 a L1 tengan tiempo para ejecutarlos en L1      antes de que el AIP entre en vigencia.

**     Fase 7: Implementación**: El AIP está completamente ejecutado e implementado.      Esto puede suceder en L1 o a través de una transacción enviada desde L1 a una o      más Chains Gobernadas.

Este proceso AIP como se especifica generalmente requerirá 37 días desde el comienzo del control en la Fase 1 hasta que finalmente se ejecute un AIP en la Fase 7 para un AIP constitucional, o 27 días para un AIP no constitucional. Un AIP puede especificar opcionalmente un retraso adicional antes de su implementación.

El Consejo de Seguridad es un comité de 12 miembros que son firmantes de una multi-sig wallet, que tiene poderes para realizar ciertas Acciones de Emergencia y Acciones de No Emergencia, según lo delegado por AbitrumDAO y la Arbitrum Fundation, y es responsable de defender esta Constitución de ArbitrumDAO. A través de la presentación, aprobación e implementación de un AIP Constitucional, ArbitrumDAO puede modificar los poderes del Security Councilo eliminar el Security Council por completo.

Existen "copias" equivalentes de los contratos multi-sig del Security Council, uno en Ethereum y otro en cada chain gobernada por ArbitrumDAO.

Acciones de emergencia:

El Security Council tiene la facultad de ejecutar cualquier actualización de software o realizar otras acciones necesarias sin demora para responder a una emergencia de seguridad, en caso de que surja (tales acciones, "Acciones de emergencia"). La realización de cualquier acción de emergencia requiere una aprobación de 9 de 12 del Security Council. El Security Council no debe usar su poder para realizar Acciones de Emergencia excepto en una verdadera emergencia de seguridad, como una vulnerabilidad crítica que podría comprometer significativamente la integridad, confidencialidad o disponibilidad de una chain gobernada por el ArbitrumDAO.

Después de realizar cualquier acción de emergencia, el Security Council debe emitir un informe de transparencia completo (en un momento apropiado después de que la emergencia de seguridad haya pasado) para explicar lo que se hizo y por qué se justificó dicha acción de emergencia.

ArbitrumDAO puede restringir o eliminar el poder del Security Council para realizar Acciones de Emergencia a través de la aprobación e implementación de un AIP Constitucional.

Acciones que no sean de emergencia:

El Security Council también puede aprobar e implementar actualizaciones rutinarias de software, mantenimiento de rutina y otros ajustes de parámetros en un entorno que no sea de emergencia (tales acciones, "Acciones que no sean de emergencia"), que requieren una aprobación 7 de 12 para que tengan efecto. Cualquier acción que no sea de emergencia, después de la aprobación del Security Council, omitirá las Fases 1 a 3 del proceso AIP y, en su lugar, pasará directamente por las Fases 4 a 7 del proceso AIP, para proporcionar un delay antes de que se despliegue cualquier acción que no sea de emergencia. El Consejo de Seguridad puede especificar opcionalmente demoras adicionales antes del despliegue.

ArbitrumDAO puede restringir o eliminar el poder del Security Council para realizar acciones que no sean de emergencia a través de la aprobación e implementación de un AIP constitucional.

El Security Council tiene 12 miembros, que se dividen en una September Cohort de 6 miembros y una March Cohort de 6 miembros. Cada año, el 15 de septiembre, a las 12:00 UTC, comienza una elección para los lugares de la cohorte del 6 de septiembre; y cada año, el 15 de marzo, a las 12:00 UTC, comienza una elección para los lugares de la cohorte del 6 de marzo.

Esto significa que la cohorte inicial de septiembre servirá un término inicial de 6 meses, mientras que la cohorte inicial de marzo servirá un término inicial de 1 año.

Las cohortes iniciales del Security Council se determinaron dividiendo aleatoriamente a los 12 miembros en dos cohortes de 6 miembros: 6 miembros en la cohorte de septiembre y 6 miembros en la cohorte de marzo. Los miembros de las cohortes iniciales del Security Council se detallan en AIP-1.

La siguiente línea de tiempo rige una elección que comienza en el tiempo T:

1. Desde T hasta T+7 días: Cualquier miembro de DAO puede declarar su candidatura al Security Council; sin embargo, un miembro actual del Security Council en una cohorte no puede ser candidato a un puesto en la otra cohorte. En la medida en que haya más de seis candidatos, cada candidato elegible debe estar respaldado por votos comprometidos que representen al menos el 0.2% de todos los tokens votables. En el caso de que menos de seis candidatos sean apoyados por votos comprometidos que representen al menos el 0.2% de todos los tokens votables, los miembros actuales del Security Council cuyos lugares estén disponibles para la elección pueden convertirse en candidatos (seleccionados al azar de su cohorte) hasta que haya 6 candidatos.

2. Desde T+7 días hasta T+28 días: Cada miembro o delegado de DAO puede votar por cualquier candidato declarado. Cada token puede ser emitido para un candidato. Los votos emitidos antes de T+14 días tendrán el 100% de peso (weight). Los votos emitidos entre T+14 días y T+28 días tendrán peso en función del momento de la emisión, disminuyendo linealmente con el tiempo, con un peso del 100% a T+14 días, disminuyendo linealmente al 0% de peso a T+28 días.

3. A T+28 días: Los 6 candidatos que han recibido más votos son elegidos e inmediatamente se unen al Council, reemplazando a la Cohorte que se presentaba a la reelección.

Antes de la próxima elección del Consejo de Seguridad, la Arbitrum Foundation establecerá procedimientos y pautas más detallados con respecto al proceso de elección para el Security Council, que pueden incluir, entre otros, un proceso de admisión de candidatos para cumplir con las leyes de las Islas Caimán, una plantilla estándar para que los candidatos completen a los fines de sus nominaciones públicas y otros procesos para garantizar un Elecciones justas y transparentes.

Como cuestión de práctica óptima para mantener un Security Council independiente, ninguna organización debe estar excesivamente representada en el Security Council. En particular, no debe haber más de 3 candidatos asociados con una sola entidad o grupo de entidades elegidas para el Security Council, asegurando así que no haya una sola entidad o grupo de entidades capaz de controlar o incluso vetar una votación del Security Council.

Además, ningún candidato con conflictos de intereses que le impida actuar en el mejor interés de ArbitrumDAO, Governed Chains y/o The Arbitrum Foundation debe ser elegido para el Security Council. Los posibles conflictos de intereses podrían ser, pero no se limitan a, afiliaciones con competidores directos de Arbitrum, historias comprobadas de exploits de proyectos y otros.

La DAO puede aprobar e implementar un AIP Constitucional para cambiar las reglas que rigen las futuras elecciones del Security Council, pero el proceso AIP no puede usarse para intervenir en una elección en curso.

Los miembros del Security Council sólo pueden ser destituidos antes de que finalice su mandato bajo dos condiciones:

1. Al menos el 10% de todos los tokens votables han emitido votos "a favor" de la eliminación y al menos 5/6 de todos los votos emitidos son "a favor" de la eliminación; o

2. Al menos 9 de los miembros del Security Councilvotan a favor de la remoción.

Los puestos de los miembros del Consejo de Seguridad que hayan sido destituidos antes de que concluyan sus respectivos mandatos permanecerán vacantes hasta la próxima elección en que esos puestos hayan de ser nombrados, a menos que se sustituyan de otro modo antes de la siguiente elección por una votación de al menos 9 de los miembros del Security Council, en cuyo caso ese puesto se nombrará en la siguiente elección.

Como los valores rectores de ArbitrumDAO y The Arbitrum Foundation, las cadenas gobernadas, la tecnología y la comunidad deben ser:

• Ethereum-aligned: Arbitrum es parte del ecosistema Ethereum, y la comunidad Arbitrum es parte de la comunidad Ethereum. Aunque ArbitrumDAO toma sus propias decisiones y persigue sus propios objetivos, está profundamente alineado con Ethereum y se ve a sí mismo como un participante activo y constructivo en la comunidad Ethereum.

• Sostenible: Arbitrum debe construirse y operarse con miras al mediano y largo plazo. Las decisiones sobre tecnología, economía y asignación de recursos no deben valorar la optimización a corto plazo sobre la salud a largo plazo y la prosperidad del protocolo, la tecnología y la comunidad de Arbitrum.

• Seguro: Arbitrum tiene una mentalidad de seguridad, y la seguridad del sistema debe pesar  mucho al considerar cualquier cambio de protocolo. En particular, Arbitrum One es una rollup chain L2 adecuada, y como tal, deriva su seguridad de Ethereum; cualquier cambio realizado en Arbitrum One debe preservar esta propiedad.

• Socialmente inclusiva: La comunidad debe ser abierta y acogedora para todas las personas que deseen participar constructivamente. Las diferencias en el conocimiento, los recursos, la geografía, el idioma y la experiencia de vida deben verse como oportunidades para aprender y hacer crecer la comunidad.

• Técnicamente inclusivo: Debería seguir siendo posible que la gente común, con sistemas informáticos ordinarios, participe lo más plenamente posible en el protocolo Arbitrum si así lo desea.

• Centrado en el usuario: El ecosistema de Arbitrum debe gestionarse en beneficio de todos los usuarios de Arbitrum.

• Neutral y abierta: La gobernanza de Arbitrum no debe elegir ganadores y perdedores, sino que debe fomentar la innovación abierta, la interoperación, la elección del usuario y la competencia sana en las cadenas de Arbitrum.

0x5e5d9153e6d9b0c1e88187d31468f0a7fa096aff9f4d538d27619798db6522e7

Para calcular este hash usted mismo, puede clonar ArbitrumFoundation/docs en su máquina local y ejecutar yarn update-constition-hash desde el root del repositorio. Alternativamente, puede instalar Node.js, navegar a la carpeta docs y ejecutar node ./scripts/updateConstitutionHash.js.

Esto usará el método keccak256 del proyecto @ethersproject/solidity para calcular el hash del código fuente de markdown de la Constitución, ubicado en /ArbitrumFoundation/docs/blob/main/docs/partials/_constitution-content-partial.md.