MakerDAO Marco de Riesgo de Gobernabilidad

Parte 1 : Confianza descentralizada y Manejo de riesgo

Untermyer: “¿El crédito comercial no se basa principalmente en dinero o propiedades?”

Morgan: “No señor, lo primero es el carácter”.

Untermyer: “¿Carácter antes que dinero o propiedades?”

Morgan: “Antes que dinero o propiedades o cualquier otra cosa. El dinero no puede comprar caracter “

Morgan: “… porque un hombre en quien no confío no podría obtener dinero de todos los lazos de la cristiandad”.

J.P. Morgan en el Comité Pujo 1912–1913

[Morgan American Financier: Jean Strouse]

Introducción

Ya sea tiranizado como protagonista de los barones del robo, el arquitecto del “fideicomiso del dinero” o alabado como el salvador del sistema financiero y el creador de la reserva federal, no se puede negar la base de la declaración de J.P. Morgan; el carácter y la confianza son la base de todas las transacciones. En marcado contraste con tiempos pasados, el sistema financiero ha evolucionado a través de nociones cada vez más profundas de carácter y confianza, y en la actualidad ha aterrizado en una nueva manifestación de su significado gracias a la tecnología blockchain.

La noción de confianza no se ha desvanecido en este sistema “sin necesidad de confianza”. Simplemente se ha diversificado. Diversificado en la medida en que nunca antes se había realizado, creando una cartera de actores a la que podemos asignar porciones más pequeñas de nuestro escaso recurso de confianza y así establecer un nuevo sentido del mismo. Si uno o un grupo de actores fracasan, aún podemos contar con la mayoría de los otros actores para mantener nuestra noción de carácter y confianza.

En esta serie de tres partes, examinaremos el marco de riesgo de gobernanza que MakerDAO utilizará. Aquí, en la primera parte de la serie, veremos qué es una moneda estable, así como los diferentes tipos. Luego presentamos el concepto de ‘gestión de riesgos descentralizada’. La segunda parte de la serie abordará cómo el primer equipo de riesgo, un equipo de modelo de plantillas y el equipo de riesgo interno de Maker Foundation inician e implementan la gestión de riesgos descentralizada. La última parte reúne todo para los titulares de token de Maker, y que puedan ver que decisiones deberán tomar, el apoyo que tendrán y el proceso de votación a seguir para administrar la función de riesgo. El objetivo de esta serie es comprender la función de gestión de riesgos y la contribución que hacen los titulares de tokens en su gestión.

La confianza y el Stablecoin

Los Stablecoins son tokens que intentan crear dinero utilizando un mecanismo que pondera intencionadamente el valor transaccional sobre el valor de mercancía del token, lo que da como resultado un token que se parece más a las monedas fiat que todos entendemos hoy.

La estabilidad implícita en el nombre se crea a través de un mecanismo dinamico que intenta mantener constante el valor del token con un punto de referencia dado. En la mayoría de los casos, ese punto de referencia es el dólar de los Estados Unidos, pero podría extenderse a cualquier otro activo (euro) o índice de precios al consumidor (IPC).

Actualmente, han trascendido tres mecanismos o tipos de stablecoin que intentan implementar esto:

  • IOU (Fiduciario)
  • Acciones de Seigniorage
  • Colateralizado

Estos diferentes tipos indican implícitamente dónde deben depositar su confianza los usuarios de stablecoin.

La organización IOU le pide al usuario inicialmente que deposite su confianza en el sistema centralizado tradicional; ques es darles un activo (generalmente de valor $ 1), lo mantendrán con un custodio centralizado y le proporcionarán un token a cambio. Si desea recuperar su activo, se devuelve el token y el custodio centralizado le devolverá su activo. El usuario confía explícitamente en que el custodio cuidará de sus activos.

Seigniorage share o Algorithmic based organizations piden al usuario que inicialmente deposite su confianza en ellos. Si el precio del token es demasiado alto, aumentarán el suministro y reducirán la demanda. Si el precio es demasiado bajo, aumentarán la demanda y disminuirán el suministro. El usuario confía explícitamente en que ellos, o los mecanismos implementados por la organización, responderán de manera oportuna y apropiada para mantener el sistema y, por lo tanto, su token estable.

stablecoins colateralizadas le piden al usuario que confíe en el valor creado por blockchain. Si el usuario cree que la economía de la cadena de bloques florecerá, también lo harán las tokens en la cadena de bloques. Esos tokens se utilizan para garantizar el suministro de monedas estables en esa economía. Independientemente de la dinámica de gobierno utilizada para la estabilidad, los usuarios ponen su confianza ante todo en la garantía prendaria antes que nada.

Uno podría argumentar los méritos de cada sistema indefinidamente, pero lo que está claro es que el tipo de sistema que elija como usuario se trata de dónde desea depositar su confianza y, por extensión, cómo define el carácter de esa moneda estable.

Stablecoins colateralizada — DAI

Maker sostiene que los usuarios deben confiar en la propuesta de valor de blockchain. Si un usuario está en la cadena de bloques, de manera predeterminada, ya hay un cierto nivel de confianza empleado. En lugar de confiar en un mecanismo fuera de la cadena, o concentrar esa confianza en una organización en cadena, parece natural llevar el establo a donde ya está la confianza: descentralizada y en la cadena de bloques.

El stablecoin de la organización Maker es Dai que se suministra a la economía blockchain de Ethereum por medio de un mecanismo de préstamo, mediante el cual un usuario toma prestado Dai y aumenta el suministro a través de transacciones on-chain. Para facilitar este préstamo, Maker ha creado un smart contract denominado Posición de Deuda Colateralizada (CDP). El objetivo del CDP es doble: aceptar tokens de garantía o colateral y poner a disposición DAI. Dicho de otra manera, proporciona préstamos e intenta mitigar el riesgo de crédito al mismo tiempo.

Posición de deuda colateralizada: el motor de suministro

Como se mencionó, un CDP es un contrato inteligente diseñado con el objetivo de minimizar el riesgo de crédito utilizando garantías y suministrar Dai a la economía de Ethereum. Entonces, ¿qué es el riesgo de crédito y por qué necesitamos garantías?

El riesgo de crédito o de contraparte es el riesgo de que un prestatario no cumpla con su deuda. Si eso ocurre, el prestamista desearía recurrir al prestatario para recuperar esa deuda. La forma más sencilla de hacerlo es mediante el uso de colateral. La colateralización es una herramienta fundamental utilizada en todo el espacio financiero tradicional para minimizar o mitigar el riesgo de crédito. La garantía se produce cuando un prestatario promete un activo como recurso al prestamista en caso de incumplimiento de ese préstamo. Dos conceptos fundamentales necesitan elaboración. Son la “prenda de activos” y el “evento de incumplimiento”.

Activos comprometidos, ya que las garantías deben ser liberadas y accesibles para el prestamista. En el sentido tradicional, eso significa que el prestamista tomaría posesión y la almacenaría en algún lugar si el activo era móvil. Existe una industria dedicada a este proceso de promesas de contribuciones de activos, asegurando que no esté gravado y almacenando adecuadamente. Lo que es impresionante es que todo esto se hace en casi un instante con un CDP.

El segundo punto importante es el evento de incumplimiento. El CDP lo convierte este incumplimiento en un evento bien establecido y casi instantáneo al que podemos identificar y reaccionar.

El CDP ha encapsulado estas dos ideas importantes y ha convertido la noción fundamental de una línea de crédito en un mecanismo de suministro de Dai.

Ahora que estamos más familiarizados con un CDP, dos preguntas vienen a la mente. ¿Qué activos usamos como garantía y cómo definimos un evento predeterminado? De hecho, estas dos preguntas son un subconjunto de un universo más amplio de preguntas de riesgo que necesitan una respuesta. La forma en que respondemos esas preguntas es a través del uso de una “construcción de riesgo” desarrollada por un equipo de riesgo.

De hecho, la función de riesgo va un paso más allá. En última instancia, nos gustaría responder estas preguntas a través de una miríada de constructos de riesgo de una multitud de equipos de riesgo. La combinación de estos equipos a través de la competencia y las estructuras cooperativas constituye la base de la función de gestión de riesgos descentralizados. Una función que continuamente presenta riesgos construye y evoluciona para comprender mejor los peligros del sistema y cómo gestionarlos. Será deber de los titulares de tokens Maker considerar y votar los constructos de riesgo para el sistema. Los creadores tendrán que analizar los méritos de cada construcción y, si están satisfechos, tendrán que votar en el equipo de riesgo contribuyente. La siguiente sección detalla la lógica detrás de la función descentralizada, así como un esquema inicial sobre cómo los titulares de Maker pueden gestionarlo y votarlo. Una elaboración sobre la gobernanza aparecerá en la tercera parte de esta serie.

Gobernanza y gestión de riesgos descentralizada

El objetivo de la gobernanza para el riesgo

El objetivo de la gobernanza es establecer la forma más efectiva de proteger la integridad y la estabilidad del sistema Maker. Logramos ese objetivo al crear una comunidad de gestión de riesgos científica descentralizada y abierta. Una comunidad que presentará argumentos claros y aplicará modelos en competencia para evaluar y administrar los riesgos que subyacen en el sistema. La comunidad se guiará inicialmente por la fundación, pero eventualmente será liderada por una multitud de equipos de riesgo que son elegidos formalmente por votación de MKR, y por investigadores de riesgo independientes que contribuyen de manera voluntaria.

El valor de una función de riesgo descentralizado radica en su capacidad de proteger contra los prejuicios y al mismo tiempo desafiar el status quo y hacer mejores contribuciones.

La integridad del sistema en cualquier momento será vulnerable a los sesgos inherentes. Sesgos como los titulares de MKR que votan por fichas que pueden tener en su poder, o los prejuicios en los canales de comunicación de los shills hablando de su libro. Una función de riesgo descentralizado asegurará que el rigor y los argumentos basados ​​en hechos se vean favorecidos sobre la opinión y, como tales, protegen contra la influencia indebida de esos sesgos inherentes.

La estabilidad del sistema siempre está expuesta a riesgos sistémicos e idiosincrásicos. Riesgos que requieren modelos bien establecidos para identificarlos, cuantificarlos y gestionarlos. Una función de riesgo descentralizado tendrá modelos competitivos abiertos que evolucionan continuamente para comprender mejor y gestionar el riesgo. La competencia garantizará que las amenazas al sistema estén bien estudiadas y que exista una gran probabilidad de que se apliquen los mejores modelos.

Formando una función de gestión de riesgos descentralizada

La visión es que lleguemos a un punto donde la comunidad debata rigurosamente un constructo de riesgo potencial aplicable al sistema. Este debate será científico y se evidenciará mediante construcciones de riesgo competidoras presentadas por equipos de riesgo establecidos o contendientes. Es decir, un equipo de riesgo podría desafiar la construcción actual implementada mediante la introducción de una nueva construcción para su consideración. La aceptación de la nueva construcción atraerá una ponderación inicial, una ponderación que determinará cómo esa construcción contribuirá a la función de riesgo general.

El objetivo de este rigor es evitar polarizar el debate. Por lo que diferentes facciones intentan ahogarse mutuamente en una retórica egoísta. En cambio, la idea es llegar a un consenso científico sobre lo que se considera la mejor construcción de riesgo general para el sistema.

Los constructos de riesgo se prevén para ser creados y presentados por ser reproducibles. Lo que significa que el constructo incluye no solo los modelos, sino también los datos utilizados y los resultados obtenidos al aplicar esos datos. Además, los datos deberían definirse explícitamente, y podrían ser exógenos o endógenos al constructo. Los datos exógenos pueden ser datos de precios o datos cualitativos obtenidos fuera del constructo, donde los datos endógenos son datos calculados desde dentro del sistema y usados ​​nuevamente como una entrada para el sistema. Un ejemplo de esto puede ser una evaluación cualitativa que da como resultado un puntaje que se usa como entrada para el cálculo de un parámetro de riesgo final. En este caso, el puntaje cualitativo es la información endógena.

Es críticamente importante comprender que, en última instancia, la construcción del riesgo sea el debate y no su resultado. La idea es que el consenso sobre la construcción implique un acuerdo sobre todos los procesos. Esto significa además consenso sobre los datos obtenidos, la fuente de los datos y cualquier transformación de los mismos que pueda ocurrir dentro del constructo.

Equipos de riesgo y sus contribuciones

A medida que avanzamos hacia una función de riesgo más descentralizada, los equipos de riesgo que están aprobados por los titulares de token de Maker tendrán sus construcciones incluidas en el sistema. El resultado de estos constructos de riesgo consistirán en evaluaciones y parámetros de riesgo para el sistema. Las construcciones de riesgo pueden diferir en cuanto a qué tipo de evaluaciones y parámetros de riesgo generan, o en qué tipo de tokens producen esto. Además, pueden surgir híbridos cuando una construcción de riesgo sólo proporciona un subconjunto de parámetros de riesgo para tokens específicos .Otra permutación es que una construcción de riesgo de un equipo de riesgo puede producir un resultado que es utilizado por otro equipo de riesgo.

Las construcciones de riesgo pueden eventualmente incluir modelos de gestión de riesgo y diagnóstico para toda la cartera de garantías. En consecuencia, podemos ver cómo una colección de construcciones de riesgo podría en última instancia cubrir todos los aspectos de la función de gestión de riesgos.

El debate sobre gobernanza consistirá en elegir equipos de riesgo según el formato, la estructura y la calidad de los constructos de riesgo a los que desean contribuir. Una vez que una construcción de riesgo ha sido debatida, entendida y aprobada (aprobado por el equipo de riesgo), el nivel de transparencia de la construcción dictará la ponderación inicial que obtendrá. Los equipos de riesgos explícitos que tienen construcciones transparentes obtendrán una ponderación mayor que los equipos de riesgos implícitos que no son transparentes.

La elección de los equipos de riesgo se realizará a través de una votación, y una vez aprobado, como se mencionó, se agregará una ponderación simple a la contribución de la construcción de riesgo. Esta ponderación representará la participación del constructo en la función de riesgo general y puede cambiar en función de su longevidad y calidad de entradas y aportes.

Los titulares de tokens de Maker finalmente administrarán la función de riesgo del sistema, y lo harán a través del uso de su mecanismo de votación. Este mecanismo incluirá dos grupos de funciones y dos formas de votación que explicaremos a continuación.

Esquema del Mecanismo de Gobernabilidad

El mecanismo de gobernanza tendrá dos grupos de funcionalidad. El primero es proactivo y el segundo es reactivo. El gobierno proactivo incluye debate, resolución e implementación automatizada. El gobierno reactivo contiene intervención procesal.

La consideración de un nuevo token como garantía, su aceptación e inclusión en la cartera junto con el despliegue de sus parámetros de riesgo es un ejemplo de gobernanza proactiva. La necesidad de aumentar potencialmente la exposición a esa garantía porque ha crecido en tamaño y liquidez es un ejemplo de gobierno reactivo.

La votación tendrá dos formas, y la primera será un voto donde se rquiera resolución. El segundo será un voto para promulgar esa resolución en el sistema. El primer tipo de votación se llama voto de gobernanza y su objetivo es representar una resolución sobre un asunto o conjunto de asuntos. Como ejemplo, ese asunto podría ser la inclusión de nuevos Oráculos o un nuevo equipo de riesgo. El segundo tipo de voto se llama voto ejecutivo y su objetivo es cambiar el estado del sistema. Un ejemplo de esto sería votar en los parámetros de riesgo para un tipo de garantía recientemente aceptada.

Lo que es extremadamente importante es el tiempo de estos votos y la frecuencia con que ocurren. Además de eso, al promulgar una votación exitosa, debemos ser conscientes de la frecuencia con la que se requiere una gobernanza reactiva. La frecuencia de estos eventos está directamente relacionada con la cantidad de creadores de token Maker que pueden gestionar el proceso y la función de riesgo. La descentralización total, eventualmente contendrá solo pequeñas contribuciones del gobierno reactivo, y la mayoría de las contribuciones provienen de un gobierno proactivo.

I. Momento de los votos de gobernabilidad proactiva

Habrá tres subtipos de votos. Votos únicos o de inicialización, votos intermitentes y votos regulares.

Los votos únicos o de inicialización inician el proceso por algo. En este caso, votar por la primera construcción de riesgo, que se explica a continuación, es un buen ejemplo. La función de gestión de riesgos estará representada inicialmente por el equipo interno cuyo objetivo será crear una construcción y plantilla para los equipos futuros. Por lo tanto, se requerirá una votación inicial para iniciar este proceso.

Los votos intermitentes serán irregulares y, en general, no se esperará que tengan un gran patrón. La votación en nuevos Oráculos es un buen ejemplo; Los oráculos no se incluyen regularmente en el sistema y, por lo tanto, caerían bajo este tipo de voto.

Los votos regulares serán votos por asuntos que se esperan. Se espera que la implementación de nuevos parámetros de riesgo colateral sea algo que estará continuamente en la lista de votantes para los titulares de token de Maker. Con la expectativa de ser llevado a cabo trimestralmente.

II. Momento de las acciones de gobernanza reactiva

Dada una construcción de riesgo o una colección de construcciones de riesgo, a lo largo del tiempo es posible que haya que cambiar las aportaciones específicas. Estas entradas estarán relacionadas con el rendimiento de una función, como un Oraculo, si necesitamos excluir un Oraculo, entonces se necesita implementar una acción reactiva para eliminarlo. Del mismo modo, si un tipo de garantía ha cambiado con respecto a su tamaño y liquidez, entonces la exposición a ese tipo de garantía puede aumentar (o disminuir). Siempre que la salida del nuevo parámetro de riesgo concuerde con la estructura de fórmula de la construcción de riesgo, entonces se realiza un ajuste. Se espera que este tipo de cambio sea irregular y, por lo tanto, intermitente.

III. Votación en nuevos tipos de garantías

Para ponerlo todo junto, consideramos cómo se votarán e implementarán los tipos de garantías. El primer paso es una evaluación cualitativa del token considerado, realizado por un equipo de riesgo o un investigador de riesgo independiente, y propuesto a los titulares de token Maker. Los titulares de tokens de Maker utilizan un voto de gobernanza para aceptar o rechazar el resultado de la propuesta de diligencia debida. El Voto de Gobernabilidad puede ocurrir en cualquier momento durante el trimestre, antes del Voto Ejecutivo.

Cada vez que un nuevo tipo de garantía pasa un voto de Gobernabilidad, agregamos los parámetros de riesgo a la lista para la próxima votación del Ejecutivo. Cada trimestre, la colección de parámetros de riesgo se votará en el sistema por medio de la votación del Ejecutivo. Lo que significa que el código necesario se implementará en el sistema para actualizar los campos y, por lo tanto, el estado del sistema.

La garantía cambiará su naturaleza a lo largo del tiempo y, como tal, si la garantía aceptada disminuye o mejora en calidad, las acciones de gobernanza reactiva se utilizarán para ajustar las partes necesarias del sistema. Estos ajustes se implementan intermitentemente pero de manera congruente con la colección aprobada de construcciones de riesgo establecidas.

La primera construcción de riesgo

¿Cómo comenzamos la función de gestión de riesgos descentralizada? La función de riesgo comenzará con el equipo de riesgo interno de Maker Foundation. Este equipo tendrá dos propósitos: crear la primera construcción de riesgo y servir como referencia y plantilla para futuros equipos de riesgo. La idea es externalizar la gestión del riesgo a la función descentralizada y que el equipo interno se convierta en una metafunción que guíe el formato y el proceso en el que se crean, consideran e incluyen los constructos.

El equipo interno de riesgos comienza el proceso considerando los riesgos inherentes al sistema y los modelos necesarios para identificar y gestionar esos riesgos.

En resumen, el equipo interno debe crear el primer constructo de riesgo para que los creadores de tokens de Maker lo tengan en cuenta. El constructo debe identificar, cuantificar y gestionar los riesgos de suministro de Dai mediante el uso de CDP. La forma en que el equipo interno crea e implementa esa construcción se explorará en la segunda parte de esta serie.

Conclusión

En esta primera parte de la serie sobre el Marco de Riesgo de Gobernanza, consideramos en qué lugar se inserta Dai en el conjunto de monedas estables de la industria. Además, delineamos la función de suministrar Dai y nos centramos en los riesgos principales de este proceso. Es importante destacar que describimos la función de gestión de riesgos descentralizada que se implementará para gestionar estos riesgos, incluyendo un esquema inicial de dónde caben los titulares de tokens de Maker y los tipos de decisiones requeridas.

La segunda parte de esta serie se centrará en la primera construcción de riesgo que comience todo el proceso. Consideraremos cada uno de los riesgos importantes inherentes al sistema y nos centraremos en cómo se creará una construcción de riesgo para administrarlos. La segunda parte será una mirada más profunda sobre qué tipo de modelos emplear, cómo están interrelacionados y cómo combinarlos en una construcción de riesgo bien formada.

Te gustó el articulo ? Dale un aplauso y seguinos en Medium!

Seguinos tambien en nuestro canal de anuncion de Telegram!

--

--

--

Curious by nature - Decentralized Tech

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Mariano Di Pietrantonio

Mariano Di Pietrantonio

Curious by nature - Decentralized Tech

More from Medium

iExec at ETHDenver 2022: Participate in our Bounties and Earn $15K in RLC!

Verus Showcases Scalable, Decentralized Currency Launch and Anti-MEV DeFi Technology for Ethereum

💎Diamond — $DMNDS💎