“El ‘algo’ que conecta dos transacciones se llama dinero, y ha tomado innumerables formas físicas — desde piedras hasta plumas, tabaco, conchas, cobre, plata, oro, hasta pedazos de papel y entradas en libros contables. ¿Quién sabe cuáles serán las futuras encarnaciones del dinero? ¿Serán bytes de computadoras?”

Milton Friedman, Money Mieschief: Episodios en la Historia Monetaria 1994.

“La única cosa que falta, pero que pronto será desarrollada, es un dinero electrónico confiable. Un método para comprar en Internet dónde puedes transferir fondos desde A hasta B, sin que A conozca a B o que B conozca a A.”

Milton Friedman, Entrevista con la Unión Nacional de Contribuyentes Marzo de 1999

Introducción

En la última parte de Marco de Riesgo de Gobernabilidad, describimos y notamos las responsabilidades de gobernar el Sistema de MakerDAO. Observemos ejemplos prácticos de gobernabilidad usando Gobernanza y Votos Ejecutivos. El objetivo de Gobernar el sistema es proporcionar la mejor estructura para asegurar la estabilidad de Dai. Manifestando un dinero electrónico verdaderamente descentralizado desde bytes de computadoras, creando con suerte, un poco más de aquello que Milton Friedman pensó que ocurriría. Antes de unir todas las piezas, necesitamos considerar el concepto de gobernanza desde la perspectiva de aquellos que poseen MKR.

La gobernanza describe cómo se controla una organización, y al mismo tiempo describe quien es responsable ante las partes interesadas de la organización. Gobernar se trata de encontrar el equilibrio entre lo que diferentes grupos de gobierno piensan que es lo mejor para la organización, contra lo que en realidad en lo mejor para la organización. La dificultad adicional está en que no muchos pueden articular, y menos estar de acuerdo en que es lo mejor. De hecho, la complejidad de la gobernanza depende de cuán clara u obvia es la definición de “lo mejor” para la organización. Cuánto menos obvia sea esta definición, entonces se formarán más grupos en torno a sus propias decisiones.

Es por estos grupos que entra una nueva dinámica en juego. Una dinámica que se desarrolla desde la competencia de lo que se considera como la mejor interpretación a implementar, convirtiéndose en una modalidad de los’ ganadores toman todo’. En consecuencia, esto resulta en la necesidad de juntar una masa crítica de acuerdos en torno a una interpretación popular subjetiva, en vez de un debate objetivo abierto y crítico. A su vez también, se forman grupos de interés especial para promover sus respectivos puntos de vista a través de un acto de cabildeo o lobby. El lobby parece ser una función natural de esos sistemas así que no es una sorpresa que aparezca.

Y no es que los grupos de interés sean propiamente malos. Sin embargo, el peligro en esta situación está en que la dinámica de los grupos puede valorar más el “ganar”que compartir una interpretación válida de la situación y su impacto. En consecuencia, el colectivo podría ser dirigido por aquellos con más recursos y no necesariamente en la mejor dirección.

Estos no son problemas nuevos, y tampoco hay nuevas soluciones para ellos. MakerDAO no se escapa de estos problemas, pero replantea la pregunta de “qué es lo mejor”, esto nos permite un tipo de gobierno llamado — gobernanza científica — que nos da la mejor posibilidad de éxito.

Propuestas y Rigor Científico

Propuestas, como las mencionadas en la primera parte de estas series toman dos formas, proactivas y reactivas. Las propuestas proactivas crean algo nuevo para el sistema, mientras que las propuestas reactivas alteran lo que ya se ha implementado.

Las propuestas proactivas tienen una cuestión de tiempo adjunto. El momento es sugestivo en cuánto a la regularidad de espera, extensión y asiduidad de los cambios esperados para el sistema. Las propuestas proactivas podrían ser generalmente relacionadas al inicio del sistema de gobierno. Las propuestas intermitentes están más relacionadas al servicio de proveedores para el sistema, un ejemplo puede ser la inclusión de un nuevo Oracle o equipo de riesgo.

Por otra parte, tenemos propuestas reactivas, su función es responder a un cambio de estado en el sistema. Los tipos de garantías (Colaterales) incluidos en el sistema pueden haber cambiado en términos de liquidez y por ello, pueden requerir de una alteración de su límite de deuda específico. La volatilidad puede haberse movido a un régimen diferente para un tipo de garantía o para una cripto como un todo y el rango de liquidez quizá necesite ser modificado. Básicamente, las propuestas reactivas responden a cambios en el sistema.

Independientemente del tipo de propuesta, el contenido de la propuesta es examinado o basado en rigor científico. Esto asegura que lo que los votantes necesitan decidir el ‘qué’ y no tanto el ‘cómo’. Los equipos de riesgo sirven como un buen ejemplo. Los poseedores de MKR votando en un equipo de riesgo a través de una votación de gobierno están implícitamente de acuerdo con los modelos usados por el equipo de riesgo, y por ende, votar en un equipo de riesgo es lo mismo que estar de acuerdo con los productos de sus modelos.

Las propuestas se introducen a la comunidad, luego se discuten, y finalmente se presentan para la Gobernanza, y cuando sea necesario un Voto Ejecutivo. La razón de este proceso es asegurar la mayor confianza en la aprobación de la propuesta. La siguiente sección explica este proceso.

El éxito a través de la Gobernanza y la Votación Ejecutiva

Una propuesta, ya sea reactiva o proactiva necesitar pasar por un proceso de incremento de confianza. La propuesta necesita ser considerada, digerida, y resuelta como necesaria para el sistema. La resolución se logra a través de una encuesta de gobernanza exitosa, una resolución que señale la intención general de los poseedores de tokens MKR. Una resolución que muestre la intención de la comunidad gobernante para aprobar una propuesta en un voto ejecutivo, aliviando la mayor cantidad de discordia posible antes de que la propuesta sea desplegada en el sistema.

Si la votación es sobre una propuesta proactiva única, así como la inclusión de un nuevo Oracle, una Encuesta de gobernanza es todo lo que se requiere. El voto será binario, será sí o no. En el futuro los votos calificados podrían ser incluidos así como diferentes mecanismo de sub-votaciones. Los votos ejecutivos también son binarios, la decisión puede determinar si el estado del sistema será cambiado. Dado esto, una resolución que fue alcanzada con una encuesta de gobernanza de antemano, podemos asumir que la resolución también se aplicaría a la votación ejecutiva — incrementando la confianza en que la votación ejecutiva será exitosa.

La encuesta de la gobernanza está basada en tiempo

Una propuesta abierta para una encuesta de gobernanza tendrá un periodo de consideración luego de ser emitida. Si un cambio es requerido en ese periodo, el cambio será implementado en una re-emisión de la propuesta, y se reiniciará el periodo de consideración. La consideración es seguida de un periodo de votación, un periodo que está abierto a recibir votos de sí o no. Independientemente del resultado final del periodo de votación, el resultado será registrado en el sistema de Gobernanza. Si la propuesta no obtiene suficientes votos positivos no se aprobará y permanecerá visible en el sistema reflejando el porcentaje de votos en contra. Si por alguna razón la propuesta no es suficiente para ir a votaciones puede ser retirada. De todos modos, una nueva propuesta puede ser emitida y comenzar de nuevo el proceso. En resumen, el periodo de consideración y de votación tienen una duración predeterminada. Al final del periodo de votación, el resultado (sí o no) con la mayor cantidad de votos gana.

El voto ejecutivo es continuo

El voto ejecutivo, por extensión, representa el estado del sistema. El estado del sistema, sin importar lo que parezca, siempre está en vivo. La implicación es que el estado del sistema está continuamente activo y por lo tanto, requiere una gobernanza contínua. Para elaborar, imagina que los poseedores de MKR han decidido una propuesta anterior, digamos que es una que implementación de un grupo de parámetros de riesgo, esta propuesta refleja el estado actual del sistema — independientemente de lo que se ha implementado. En cualquier momento una propuesta competente podría presentarse en el sistema. Si los poseedores de MKR no están de acuerdo con la nueva propuesta necesitan emitir su voto para el estado actual del sistema, lo que implica que ellos no quieren que se cambie nada.

La continuidad del sistema se enfatiza en el hecho de que una nueva propuesta puede ser emitida en cualquier momento por un poseedor de MKR. Por lo tanto, el sistema debe ser monitoreado y gobernado continuamente, y por ello necesita una estructura de votación que refleje esa necesidad. La construcción empleada por MakerDAO, que satisface esta necesidad, es llamado el Sistema de Votación de Aprobación Continua.

Votación de Aprobación Continua

La gobernanza puede ser considerada en términos de “dónde desean retener sus tokens los poseedores de MKR”. Solo hay tres lugares para ellos, el primero es en una wallet, el segundo es en la estructura de votación (Smart contracts de Votación) y tercero en la construcción del fondo de liquidez.

Vale la pena repetir que los tokens MKR son Tokens de Gobernanza. La razón del recordatorio es enfatizar que los tokens MKR deberían, al menos teóricamente, estar siempre en la estructura de votación (Smart Contract de Votación) manteniendo el status quo del sistema. Entonces la pregunta que queda es, si los tokens MKR no están en la estructura de votación, entonces dónde deberían estar y por qué deberían estar allí? Esta sección se enfocará solo en la estructura de votación, las secciones que siguen considerarán cuando los tokens no estén en la misma.

Un experimento mental ayudará a aclarar las dinámicas subyacentes. Los poseedores de tokens MKR necesitan gobernar el sistema, establecer el status quo para el sistema y defenderse contra cualquier propuesta que parezca contraria al objetivo general de la buena gobernanza. Imaginese entonces que todo el millón de tokens MKR están en la estructura de votación, con una mayoría de los tokens en una propuesta — votando así por una propuesta que refleje el estado actual del sistema. Los tokens restantes serán distribuidos a través de la colección de nuevas propuestas que desean desafiar el estado del sistema. Dada la distribución general de tokens, está claro que el status quo del sistema prevalecerá porque la mayoría de los tokens aún están ‘votando’ para el estado actual.

Si se introduce una propuesta que es claramente beneficiosa, el valor inherente de la misma se verá en el sistema. Si los poseedores de MKR reconocen este valor, la mayoría de los tokens se cambiarán a esta nueva propuesta y la implementarán como el nuevo estado del sistema.

En este punto, sería útil dar un paso atrás y pensar cómo una nueva propuesta podría representar un nuevo estado de TODO el sistema. Lo primero que se debe tener en mente es que si una propuesta gana la mayoría, entonces el cambio descrito en esa propuesta será implementado una vez y solo una vez. Luego de esto, la propuesta se convierte en una propuesta de “Estado Actual del Sistema” . Por lo tanto un nuevo estado del sistema está representado por cómo se modifica, así la mayoría de los poseedores de tokens MKR representarían en una nueva propuesta el estado actual del sistema Y el cambio requerido en la nueva propuesta. Además, para defender el estado actual del sistema se requiere que los poseedores de tokens MKR mantengan sus votos en esta propuesta más actual que refleja el status quo de TODO el sistema.

Para continuar con el experimento mental, asuma que las propuestas se introducen constantemente en el sistema. Para gobernar apropiadamente el sistema todos los poseedores de tokens MKR deberían tener sus tokens en la estructura de votación, tanto para representar constantemente el status quo o para moverse a la nueva propuesta para desatar su valor potencial. Esto es la Votación de Aprobación Continua, donde la continuidad representa el status quo constantemente siendo desafiado y reforzado a través de movimientos continuos de la mayoría de los votos entre las nuevas propuestas deseadas y la propuesta exitosa más reciente.

Dándole un valor a la responsabilidad

La característica principal del token MKR como token de gobernanza es que el poseedor represente una responsabilidad fiduciaria con el sistema y con ellos mismos. El incentivo para implementar esa responsabilidad es tener una opinión sobre el desarrollo y crecimiento de una organización que otorga valor al token si la gobernanza se implementa correctamente y devaluarlo si ocurre lo contrario.

En la sección anterior se hizo referencia a un experimento mental donde asumimos que todos los tokens MKR están en la estructura de votación — El sistema de Aprobación Continuo. Además, se dedujo usando un caso límite de propuestas continuas siendo emitidas, el por qué todos los tokens en la estructura de votación serían necesarios. Alejándonos de este caso límite, donde las propuestas no son constantemente emitidas al sistema, qué significaría esto para los poseedores de MKR? .

Suponga que se ha alcanzado un equilibrio y que no se aceptarán más propuestas en el sistema. Significando que los tokens MKR han extraído todo el valor de las propuestas y que ese valor permanecerá constante ante el sistema, dado que no se presentan más propuestas. En términos de asignar capital para su mejor uso, un poseedor de MKR puede desear transferir el valor a Dai para mantener el máximo valor percibido extraído de todas las propuestas.

La transferencia del valor a Dai es un evento de liquidación específico y una instancia de lo que pasa en la estructura de fondos de liquidez. El fondo de liquidez representa todos los vectores de liquidación disponibles para los poseedores de MKR que creen necesaria una redistribución de recursos, requerida mientras el sistema MakerDAO está en equilibrio y no se perciba ninguna otra amenaza en el sistema. Si comienzan a entrar nuevas propuestas en el sistema, entonces los poseedores anteriores posiblemente quieran entrar en el fondo de liquidez para readquirir su posición en MKR y participar en la votación para ayudar a extraer el valor de la nueva propuesta o defenderse de ella.

Retener MKR en una wallet refleja la madurez del sistema. Si la estructura de votación no está completamente desarrollada, asegurada o apropiadamente fluida, y la estructura de liquidez no es lo suficientemente líquida, la única alternativa disponible es mantener los tokens en una wallet separada.

En resumen, dado una estructura de votación completamente desarrollada y segura junto con un mercado líquido en tokens MKR, debe haber solo dos opciones a considerar. Mantener tus MKR en la estructura de votación para gobernar constantemente o cambiarlos a Dai. Considerando que estas estructuras nunca van a satisfacer los estándares de todos los poseedores, se puede suponer que una cantidad natural de tokens MKR será mantenida en wallets.

Responsabilidades personales de los poseedores de tokens MKR

Probablemente el aspecto más importante a tener en mente del sistema de votación es que no se requiere un quórum para aprobarla. Combinado con el principio de ‘la mayoría gana’, debe quedar claro que la responsabilidad principal de los poseedores de tokens MKR es conocer todas las propuestas que entren a la estructura de votación. De hecho, la falta de quórum incentiva implícitamente a todos los poseedores de MKR a involucrarse. La amenaza del caso límite es que una propuesta antiética podría aprobarse con un muy bajo número de participantes. En este caso, se asumirá que la propuesta de gobernanza no fue clara o se había establecido una apatía masiva. De todos modos, si una propuesta perjudicial se aprueba, el Módulo de Seguridad de Gobernanza se activaría. Si el resultado es que la propuesta es en efecto perjudicial o un ataque al sistema, entonces un Apagado de Emergencia sería implementado antes que la propuesta tenga efecto. En esta coyuntura, sería prudente explorar lo que es el Módulo de Seguridad de Gobernanza y que hace, junto con la revisión de la función del Apagado de Emergencia del sistema.

Módulo de Seguridad de Gobernanza

Una vez que haya pasado la votación ejecutiva, se establece un periodo de demora. Este periodo es el componente principal del Módulo de Seguridad de Gobernanza. El código recientemente votado es encapsulado por el módulo antes que se despliegue en el sistema y se mantiene para su consideración final por 24 horas. Durante este periodo los interesados pueden revisar el código, especialmente los interesados responsables del Apagado de Emergencia. El propósito de la revisión es solo asegurar la integridad del sistema. Si el código es revisado y considerado perjudicial para el sistema, entonces el sistema se desconectará antes de que pueda ser desplegado.

Apagado de Emergencia

El sistema se desconecta si se encuentra bajo ataque. Cualquier acción, deliberada o no, que sea perjudicial para el sistema será contrarrestada con una desconexión del sistema. El Módulo de Seguridad de Gobernanza es un ejemplo de una medida de seguridad incorporada usada para proteger el sistema contra influencias y acciones debilitantes. El Módulo de Seguridad Oracle funciona de la misma manera donde Inicialmente un conjunto de precios es transformado en un solo precio. La transformación mejora la autenticidad del precio usado pero aún no garantiza el 100% de autenticidad de los precios reportados. En ese caso, el Módulo de Seguridad Oracle instituye las mismas medidas que el Módulo de Seguridad de Gobernanza y le da al sistema la oportunidad de ser desconectado antes que se establezca el precio perjudicial.

El objetivo principal del Apagado de Emergencia es alinear todos los incentivos. Como todo, hay incentivos atípicos que deben atenderse, es en estos casos que si el incentivo atípico no se alinea con el propósito general del sistema, la función del Apagado de Emergencia entra en juego.

Las responsabilidades de los poseedores de tokens MKR

El objetivo principal de gobernar el sistema MakerDAO es alinear los intereses de todas las partes interesadas para un mismo fin:

• Gobernar MakerDAO requiere estar consciente de la compensación entre los incentivos de la estructura de liquidez y la estructura de votación. MakerDAO se convierte en un mejor sistema si se somete a una serie de propuestas que provienen del cuerpo de gobierno que trae un incremento potencial en valor, que reta al valor inherente presentado por la estructura de liquidez.
• Gobernar MakerDAO requiere estar involucrado constantemente. No se requiere un quórum, por lo tanto el cuerpo de gobierno necesita estar siempre comprometido para prevenir, lo que podría ser, un número no representativo de votos cambiando el estado del sistema. Instituir un quórum desde el principio puede ser una mejor propuesta pero instituye una inyección de autoridad central. Los quórums son esencialmente una manera de representar la importancia de un voto, esto es subjetivo, y cualquier quórum predeterminado solo representará lo que una persona o grupo de personas consideran importante.
• Gobernar MakerDAO requiere cambio iterativo. El sistema subyacente a la provisión de Dai stablecoin está basado en gobernanza científica. Un componente fundamental del método científico es el empirismo, el cual establece que siempre debemos estar validando o cuestionando hipótesis con datos. Últimamente, el sistema se mejora al estar continuamente cambiándose y cuestionándose. Se puede esperar que los cambios tengan beneficios marginales materiales al inicio y luego disminuir lentamente a beneficios marginales insignificantes. En este punto, el sistema debería estar idealmente en un estado de equilibrio. Entonces ocurriría un cambio de régimen y tendríamos una nueva ola de cambios. Los cambios de régimen siempre deberían esperarse.

Gobernando en la Práctica

Proceso de encuesta de gobernanza — Votando en un nuevo equipo de riesgo

Un equipo de riesgo construye una herramienta o serie de herramientas para evaluar el riesgo inherente en MakerDAO. Las herramientas creadas pueden enfocarse en el proceso entero de riesgo o en un componente del mismo. El equipo entonces muestra la funcionalidad de la herramienta dado un grupo de datos, donde el grupo de datos es verificable y fácilmente accesible.

El equipo de riesgo entonces hace que la serie de herramientas estén disponibles para que los poseedores de MKR lo evalúen. Las herramientas podrían estar disponibles a través de una interfaz de usuario avanzada o simplemente a través de una hoja de trabajo descargable. Es de suma importancia que el conjunto de herramientas incluya toda la documentación necesaria.

El procedimiento requerido para votar en un nuevo equipo de riesgo será el siguiente:

• Un equipo de riesgo describe y demuestra su serie de herramientas. Esto incluye interactuar con los poseedores de MKR y otros equipos de riesgo.
• Cuando el equipo de riesgo esté seguro de que se hayan entendido sus herramientas, deberían enviar formalmente sus herramientas para ser incluidas.
• Una propuesta enviada a la estructura de votación será esa presentación; implicando que el equipo de riesgo deberá tener algunos tokens MKR para emitir dicha propuesta. la propuesta entonces será colocada en una Votación de Gobernanza.
• La propuesta entonces pasará por el periodo de consideración (por ejemplo unas dos semanas), donde se puede tener una discusión final a través de los canales sociales de Maker (Reddit, Rocketchat o un tablero interno creado).
• Luego del periodo de consideración la propuesta se abrirá al proceso de votación (por ejemplo, dos semanas).
• Al final del periodo de votación, si la propuesta tiene la mayoría de los votos positivos, es exitosa y se aceptará el equipo de riesgo.
• Luego de eso, el valor de los parámetros de riesgo generados por ese equipo de riesgo contribuirá a la votación ejecutiva por defecto. Implicando que el valor nominal no se votará sino simplemente será incluido en el nuevo estado.
• Si los poseedores de MKR encuentran que los valores emitidos a la votación ejecutiva no son los mismos que los que implica el conjunto de herramientas aceptado — la votación será rechazada y el equipo de riesgo será expulsado de MakerDAO.

Proceso de Votación Ejecutivo — Votación en un nuevo tipo de garantía y parámetros de riesgo

Un nuevo tipo de garantía agregado al sistema implica la posibilidad de generar Dai. La inclusion de un nuevo tipo de garantía debe ser considerada desde dos ángulos. EL primero es el potencial que trae generar Dai, el segundo la cantidad de estabilidad que trae al sistema. Una evaluación cualitativa de la organización que representa al token da una indicativo de cuán robusto puede ser el token. En consecuencia, dar una idea del nivel de estabilidad puede contribuir con el sistema. Una evaluación cuantitativa del token da una indicación de los riesgos enfrentados al tradear el token en mercados secundarios, así como la cantidad de tokens que serán usado en el sistema. Tal evaluación indicaría la cantidad potencial de Dai que podria ser generada, así como los riesgos de mercado del token.

Toda votación ejecutiva está precedida por una votación de gobernanza. Así la secuencia de la votación de gobernanza será:

• El nuevo tipo de garantía o colateral sera presentado por al menos un equipo riesgo, incluyendo la evaluación cualitativa y cuantitativa del tipo de garantía.
• El equipo de riesgo enviará formalmente una propuesta para aceptar el tipo de garantía en el sistema.
• La propuesta pasara el periodo usual de consideración (dos semanas) y si no hay una disputa obvia pasará por el periodo de votación (dos semanas).
• Al final del periodo de votación la propuesta se aprobará si tiene la mayoría de los votos.

La secuencia para la votación ejecutiva será la siguiente:

• La evaluación cualitativa y cuantitativa del tipo de garantía será actualizada con cualquier nueva información y será pública de nuevo.
• El equipo de riesgo que presenta la solicitud enviará entonces una propuesta que incluye los valores nominales para el tipo de garantía.
• Desde que la propuesta entre en el sistema de votación de aprobación continua, la propuesta necesitará atraer la mayoría de votos.
• Tan pronto la propuesta se convierta en la propuesta dominante con la mayoría de votos será inicializada.
• El Módulo de Seguridad de Gobernanza entrará en juego y retrasará la implementación del código en la blockchain durante 24hrs. Esta es la estructura de seguridad final que permite una determinación final de la seguridad del código.
• El código se implementa en la blockchain y se cambia el estado de MakerDAO.

En este punto, el nuevo tipo de garantía es libre para ser usado como garantía y contribuir al suministro general de Dai. Esto cubre los diferentes tipos de estructuras de votación. En conclusión a este artículo, abordaremos las decisiones de la gobernanza que se espera se pongan en marcha en el sistema para el Multi-Collateral Dai.

Conclusión — Los próximos pasos

Gobernar el sistema MakerDAO es similar a gobernar un gran ecosistema. Hay características inherentes que ayudan a cuidar el sistema y algunas requieren de la participación del cuerpo de gobierno. No importa cómo lo veas, la información pertinente al sistema se volverá fluida y continua. Requiriendo evaluación y gobernanza constantes. Destacando la necesidad de los poseedores de MKR de entender completamente la profundidad de la responsabilidad y también los beneficios de gobernar el sistema MakerDAO.

El inicio del motor del Multi-Collateral Dai es el foco de los ‘próximos pasos’ que incluirán lo siguiente:

• Aprobar el equipo de riesgo interno mediante una Votación de Gobernanza. Requerido para votar por tipos de garantías y parámetros de riesgo. Antes del lanzamiento de la mainnet.
• Aprobar la lista inicial de tipos de garantías o colaterales mediante una Votación de Gobernanza. Requerida para votar e implementar los valores de los parámetros de riesgo. Antes del lanzamiento de la mainnet.
• La votación de los valores de los parámetros de riesgo para los tipos de garantía aprobados a través de una Votación Ejecutiva. En el lanzamiento de la mainnet.

En términos de consideraciones prácticas para la gobernanza, aún necesitamos considerar algunas cosas. Primero, se usan las herramientas actuales para calcular las cifras de riesgo, así como el método para construir el portafolio de garantías como un todo. En segundo lugar, cómo se agregan y se implementan al sistema las cifras de riesgo de una colección de equipos de riesgo. Esto se cubrirá en dos documentos separados, para dado que se implementa y se tienen la aprobaciones necesarias, la producción completa del sistema comienza en serio y damos este gran paso hacia una nueva era.