La Constitución de la DAO —como toda Constitución— deja asentadas ciertas reglas vinculantes; es decir, de cumplimiento obligatorio. Estas reglas y procedimientos son ejecutados y operalizados por actores humanos y por contratos inteligentes, según el caso. En cuanto a las tomas de decisiones y las acciones llevadas a cabo, existen dos categorías: on-chain, cuando son efectivizadas por contratos inteligentes y asentadas como transacciones en la blockchain, y off-chain, cuando se llevan a cabo de cualquier otra manera distinta a las acciones on-chain.

La Constitución, a su vez, se divide en seis secciones. Aquí vamos a hacer un punteo de los aspectos más relevantes de cada una, pero si quieres leer el documento de manera completa, no dudes en hacer click aquí.

Sección 1: Ownership de las cadenas

• La DAO puede decidir la creación de nuevas cadenas L2 desplegadas en Ethereum.
• Dicha creación debe surgir de una AIP (Arbitrum Improvement Proposal).
• Estas cadenas pueden ser de dos categorías distintas:
  • Governed Chain: son aquellas que se rigen por esta Constitución y se gobiernan a través del ARB por la DAO.
  • Non-Governed Chain: creadas por una AIP y autorizadas por la DAO, pero que no se gobiernan a través de ARB ni se rigen por la Constitución.
• Non-Governed Chain: creadas por una AIP y autorizadas por la DAO, pero que no se gobiernan a través de ARB ni se rigen por la Constitución.
• Las cadenas que se desplieguen —utilizando la tecnología de Arbitrum— sobre cadenas ya existentes de Arbitrum no necesitan la autorización de la DAO. Este tipo de cadenas son las denominadas L3.
• Cada cadena autorizada por la DAO puede tener distintos owners; es decir, aquellos que pueden decidir cambios estructurales sobre la misma, incluidos aquellos que incluyan contratos alojados en la L1.
• El control sobre las dos cadenas principales, Arbitrum Nova y Arbitrum One, recae sobre la Arbitrum DAO y el Concejo de Seguridad de la Arbitrum Foundation.

Sección 2: Propuestas y proceso de votación

Actores principales

• Fase 1: Temperature check, o chequeo de temperatura (7 días)
  • Si bien no es obligatorio, se recomienda subir la AIP al Foro durante una semana para habilitar la lectura y discusión de la misma a la comunidad.
  • Dicha publicación debe incluir además la posibilidad de votar al respecto de la AIP en cuestión; por ejemplo, a través de Snapshot.
  • La creación de esa encuesta tiene que ser realizada por una wallet que posea, al menos, el 0.01% de los ARB circulantes.
  • Esta votación no es vinculante y debe estar en línea una semana. La misma se define por mayoría simple y no requiere de un umbral mínimo de participación.
  • Una AIP que no tenga un buen desempeño durante la semana de temperature check, no debería ser puesta en votación on-chain.
• Fase 2: Formalización de la AIP y llamado a votación (3 días)
  • La AIP es subida a Arbitrum One a través de Tally.
  • El usuario que eleve la AIP de esta manera debe poseer al menos 1.000.000 de ARB en su wallet.
  • Antes de que comience la votación formal, debe darse un periodo de 3 días para que los votantes piensen y discutan su voto.
  • A su vez, cada AIP puede caer dentro de dos categorías:
    • AIP Constitucional: aquella que modifica el texto o los procedimientos de la Constitución y de los Memorandum y Reglamentos de la Arbitrum Foundation; que instala o modifica software en cualquier cadena de Arbitrum; que realiza una acción que requiere permiso por los dueños de la cadena que se verá afectada; que apruebe una nueva cadena, de cualquiera de los dos tipos posibles ya mencionados.
    • AIP No-Constitucional: aquella que no es considerada una AIP Constitucional. Por ejemplo, aquellas AIP que incluyan a relocalización de los fondos del Tesoro de la DAO o de las wallets de la Arbitrum Foundation, o aquellas que agreguen reglas o información nueva a la DAO.
  • Cada AIP debe estar correctamente asignada en alguna de las dos categorías posibles.
  • Cada AIP debe señalar de manera clara a qué cadena de Arbitrum van dirigidas sus acciones.
  • En cuanto a su estructuración, se recomienda que cada AIP incluya:
    • Abstract: un resumen corto de no más de tres líneas con respecto a las intenciones de la AIP
    • Motivation: el motivo por el cual la comunidad de Arbitrum debería estar interesada en la propuesta
    • Rationale: explicación de por qué la AIP se alinea con los intereses y los valores de Arbitrum
    • Palabras clave: definición de aquellos conceptos, categorías o palabras específicos de la AIP y nuevos para la comunidad de Arbitrum, si los hay.
    • Especificaciones: información detallada de la tecnología y las plataformas que se utilizarán para cumplir lo propuesto.
    • Pasos a implementar: costos, equipo de trabajo, y todos aquellos insumos y elementos que se utilizarán a lo largo de las distintas etapas de acción proyectadas por la AIP.
    • Timeline: cronología proyectada, incluyendo, como mínimo, fecha de inicio, milestones y fecha de finalización.
    • Costos totales: costo total en caso de implementarse AIP.
  • En el caso de que se trate de una AIP resubida, enmendada o modificada de algún modo, pueden agregarse categorías que ayuden a dilucidar:
    • Link a la AIP original
    • El motivo por el cual la AIP originaria ha sido rechazada o modificada
    • Lista de cambios o enmiendas realizadas
• Fase 3: Votación on-chain de la DAO en Arbitrum One (14/16 días)
  • La AIP será aprobada si se cumplen las siguientes dos condiciones:
    • Hay más ARB colocados a favor que en contra en la votación.
    • Para las AIP Constitucionales:
      - Al menos el 5% de todos los ARB habilitados para votar han votado a favor de la propuesta
      
      Para las AIP No-Constitucionales:
      - Al menos el 3% de todos los ARB habilitados para votar han votado a favor de la propuesta
  • El periodo de votación es de dos semanas (14 días). Si recién entre el día 12 y el 14 se ha alcanzado el umbral mínimo de participación positiva (5% o 3% según el tipo de AIP), la votación se extenderá dos días más (totalizando 16 días).
  • Si la AIP es rechazada, el proceso termina durante esta Fase 3.
  • Si la AIP es aprobada, y se trata de una AIP Constitucional, se seguirá con las Fases 4, 5, 6 y 7.
  • Si la AIP es aprobada, y se trata de una AIP No-Constitucional, se seguirá con las Fases 4 y 7, obviándose la 5 y la 6.
• Fase 4: Periodo de espera en la L2 (3 días)
  • Aprobada una AIP, debe darse un periodo de espera de 3 días en el cual aquellos que han votado en contra pueden retirar sus ARB de la votación y llevar a cabo las acciones que crean necesarias en la L2.
• Fase 5: Iniciar y finalizar un mensaje desde la L2 a la L1
  • Debe enviarse un mensaje desde la L2 a la L1 indicando que la AIP ha sido aprobada y entrará en acción. Llegado este mensaje a la L1, cualquiera puede aprobarlo. De este modo, la AIP es reconocida en la L1 luego de que en la L1 sean reconocidos los movimientos de ARB ocurridos durante la Fase 4.
• Fase 6: Periodo de espera en la L1 (3 días)
  • Tras la finalización de la Fase 5, se esperará tres días para darle tiempo a aquellos que hayan realizado movimientos desde la L2 hacia la L1, sean estos mensajes o retiros de ARB.
• Fase 7: Implementación
  • La AIP es ejecutada e implementada. Esto puede ocurrir en la L1 o bien a través de transacciones enviadas desde la L1 hacia la cadena L2 correspondiente según el caso.

De este modo, el proceso completo de presentación y aprobación de una AIP lleva generalmente 37 días, en caso de tratarse de una AIP Constitucional, o 27 días para las AIP No-Constitucionales.

Sección 3: Concejo de Seguridad

• El Concejo de Seguridad esta formado por 12 miembros firmantes de una multi-sig.
• El Concejo puede tomar dos tipos de acciones:
  • Acciones de Emergencia:
    • Si el sistema enfrenta un problema de seguridad, el Concejo esta habilitado a realizar las acciones necesarias para enfrentar dicha situación.
    • Para llevar a cabo dichas acciones, se necesita la aprobación de 9 de los 12 miembros del Concejo.
    • El problema de seguridad debe estar debidamente justificado y comprometer de manera seria la disponiblidad, confidencialidad o integridad de alguna cadena gobernada por Arbitrum DAO.
    • Una vez llevadas a cabo las acciones y solucionada la emergencia, el Concejo debe elaborar un reporte público y transparente en el que señale los motivos, el curso de acción y los resultados obtenidos.
  • Acciones no Urgentes:
    • Se trata de acciones de rutina, mantenimiento y actualización que no se dan dentro de una situación de emergencia.
    • Dichas tareas pueden ser llevadas a cabo por el Concejo y, para eso, deben contar con la aprobación de 7 miembros del mismo.
    • Una vez que obtengan dicha aprobación, el plan de acción debe ser publicado en la DAO y seguir las Fases 4, 5, 6 y 7 seguidas por las AIP, tras lo cual, si aprobadas, se podrán llevar finalmente a cabo.
• El Concejo recibe sus poderes de Arbitrum DAO y de la Arbitrum Foundation, y estos poderes pueden ser modificados o revocados por la DAO a través de una AIP.
• El Concejo puede ser disuelto a través de una AIP promovida por la DAO.

Sección 4: Elecciones del Concejo de Seguridad

• El Concejo de Seguridad esta conformado por 12 miembros, divididos a su vez en dos cohortes de 6: la Cohorte 1 y la Cohorte 2
• Las elecciones deben llevarse a cabo de manera on-chain y ser promovidas y ejecutadas por la DAO.
• En una primera elección, se eligen los miembros de la Cohorte 1.
• En una segunda elección, que debe celebrarse seis meses luego de la primera elección se eligen los miembros de la Cohorte 2.
• Las elecciones, por lo tanto, se llevan a cabo cada seis meses.
• Las elecciones se llevan a cabo del siguiente modo:
  • Nominación (7 días):
    • Cualquier miembro de la DAO puede proponerse como miembro del Concejo por uno de los dos Cohortes (pero no por los dos al mismo tiempo).
    • Cada candidato debe ser apoyado con, al menos, el 0.2% de los tokens de votación totales.
  • Proceso de conformidad (_14 días):
    • Los candidatos deben pasar un proceso de conformidad e idoneidad bajo el acompañamiento de la Arbitrum Foundation, que tendrá a su vez la potestad de dar de baja a aquellos candidatos que no cumplan las expectativas.
    • Si se han presentado menos de 6 candidatos, se elegirá de manera aleatoria a alguno de los Concejeros en cargo hasta que se llegue a una nómina de 6 candidatos.
  • Elección (21 días):
    • Cada miembro de la DAO o los Delegados pueden votar por los candidatos. El peso de los votos irá en relación con el momento en el cual dichos votos son emitidos; de esta forma, los votos emitidos durante el primer día de la votación tienen una incidencia del 100%, que va decreciendo a medida que se llega a los últimos momentos del periodo de votación.
    • Dicho sistema tiene como objetivo incentivar la votación temprana.
  • Finalización:
    • Finalizada la votación, y habiendo concluido ya el ciclo de 42 días, los miembros elegidos pasan a formar parte del Concejo de Seguridad.
    • Dicho proceso debe operalizarse a través de contratos inteligentes de manera on-chain.
• En cuanto a la remoción de uno de los miembros, la misma puede ocurrir únicamente en dos casos. A saber:
  • Al menos el 10% de los ARB con capacidad de voto se ha manifestado a favor de la remoción y al menos el 83.33% de todos los votos vertidos esta a favor de la remoción.
  • 9 de los 12 miembros del Concejo de Seguridad se manifiestan a favor de la remoción de uno o más miembros.
• Un miembro que ha sido removido del Concejo solo puede volver a formar parte del mismo a través de un nuevo proceso de elección.
• El asiento vacante puede ser ocupado por un nuevo miembro si 9 miembros del Concejo se muestra favorables a dicha acción.
• Si un nuevo miembro es colocado por este medio, aplican para él los mismos tiempos que para todos los demás miembros. Es decir: su silla queda vacante cuando lleguen las siguientes elecciones.
• Si los 9 miembros del Concejo no colocan a un nuevo miembro en una silla que ha quedado vacía, la misma permanece en este estado hasta las siguientes elecciones.

Sección 5: Comité de Disponibilidad de Datos

• Únicamente aplicable a Arbitrum Nova, los datos de las transacciones son atesorador por un Comité de Disponibilidad de Datos que, a su vez, publica los mismos en un Server de Disponibilidad de Datos, y no en la red principal de Ethereum (como sí sucede con los datos transaccionales en Arbitrum One).
• Los miembros del Comité son elegidos y pueden ser removidos por la DAO a través de una AIP.
• Si un miembro del Comité renuncia o es removido, el Cocejo de Emergencia puede llevar a cabo una Acción de Emergencia tras la aprobación de la misma por 9 de sus 12 miembros y colocar a un nuevo miembro del Comité en el asiento vacante.

Sección 6: Valores Centrales de la Comunidad

• Alineación con Ethereum:
  Por su misma naturaleza, Arbitrum forma parte del ecosistema de Ethereum, y la comunidad de Arbitrum es parte de la comunidad de Ethereum. Por eso, si bien la DAO es independiente y toma sus propias decisiones y su propio camino, se siente profundamente alineada con el ethos de Ethereum y forma parte de su comunidad.
• Sustentablidad:
  El proyecto de Arbitrum pretende ser uno de largo alcance; proyectarse hacia el futuro. Por eso, las decisiones referidas a cuestiones económicas, tecnológicas, financieras, políticas, etcétera, tienen que tender a una visión de largo plazo: no priorizar acciones cortoplacistas, aún si estas revistieran, por ejemplo, ganancias económicas, por sobre la visión general del trayecto de Arbitrum y su sustentabilidad.
• Seguridad:
  La seguridad del protocolo debe ser una prioridad. Cualquier cambio estructural o profundo debería tener en alta consideración mantener los estándares de seguridad. En el caso de Arbitrum One, estos emanan de Ethereum, y deberían conservarse de esa manera.
• Inclusión social:
  La DAO debe ser abierta y plural y darle la bienvenida a todos aquellos interesados en participar del proyecto. Las diferencias culturales, de conocimiento, tecnológicas, geográficas, idiomáticas, y demás, deben ser vistas como factores enriquecedores, y no como trabas.
• Inclusión tecnológica:
  Arbitrum se propone como una solución de escalabilidad que apunta a facilitar el uso y la adopción de Ethereum. Por lo tanto, debe ser un servicio plausible de ser utilizado en la mayor cantidad de dispositivos posibles; de ser, en definitiva, lo más tecnológicamente inclusivo que se pueda.
• Foco en el usuario:
  Arbitrum debe enfocarse siempre en promover el beneficio de sus usuarios como objetivo principal.
• Neutralidad y apertura:
  Sin señalar y promover ganadores y perdedores, la comunidad de Arbitrum debe fomentar la competencia y la innovación entre sus productos y cadenas, y también la discusión enriquecedora entre sus miembros.