MIP48: Transmisión de Pagos a través del Keg

MIP48: Transmisión de Pagos a través del Keg

Preámbulo

MIP#: 48
Título: Transferencia de Pagos a través del Keg
Autor(es): Payton Rose @prose11, Sam MacPherson (@hexonaut)
Colaboradores: @amyjung, @LongForWisdom, @Elihu
Etiquetas: general
Tipo: General
Estado: Aceptada
Fecha de Propuesta: 2021-02-03
Fecha de Ratificación: 2021-25-03
Dependencias: n/a
Reemplaza: n/a

Referencias

Sumario Abreviado

La MIP48 describe cómo utilizar el Keg, un método de transmisión de DAI a diversas direcciones, a un ritmo definido.

Sumario Extendido

La MIP48 detalla qué propiedades deben ser definidas para que la Gobernanza de Maker utilice la herramienta de distribución de DAI llamada Keg. El Keg le permite a la Gobernanza de Maker distribuír DAI en “flights”, grupos de direcciones que reciben fondos a lo largo del tiempo en una proporción fija. Tanto el Buffer de Excedentes como el Flapper (Subasta de Excedentes) pueden ser utilizados como fuentes de financiación para el Keg.

Sumario de Componentes

MIP48c1: Componentes que definen al Keg

Describe el Keg y los componentes necesarios para utilizarlo.

MIP48c2: Configuración de Distribuciones Fijas a través del Keg

Describe cómo la Gobernanza de Maker puede dictar pagos desde el Buffer de Excedentes hacia el Keg a través de una subpropuesta de la MIP48c2.

MIP48c3: Configuración de Distribuciones Variables a través del Keg

Describe cómo la Gobernanza de Maker puede dictar pagos variables redirigiendo un porcentaje de DAI que de otra manera serían destinados al Flapper a través del Keg, utilizando la subpropuesta MIP48c3.

MIP48c4: Detención de Distribuciones del Keg

Describe cómo la Gobernanza de Maker puede detener o pausar pagos a través del Keg, utilizando la subpropuesta MIP48c4.

Motivación

El Keg fue creado como una forma de que la Gobernanza de Maker haga transmisiones de pagos a diferentes direcciones de wallet. Actualmente, cada asignación de DAI debe ser dictada por Gobernanza, que lanza un hechizo para una sola distribución. Habilitar el Keg le permitirá a la Gobernanza distribuir DAI continuamente para proyectos de importancia permanente al Protocolo de Maker, en vez de requerir iniciativas para pedir DAI continuamente en cada Ciclo de Gobernanza.

Adicionalmente, la habilidad de utilizar fondos que de otra forma irían al Flapper (Subastas de Excedentes) le permite a la Gobernanza designar DAI a programas como un porcentaje de excedente de ingresos. Por lo tanto, ciertos proyectos pueden ser fundados siempre y cuándo haya un excedente de los requisitos operativos para el Protocolo Maker.

Especificaciones / Detalles de la Propuesta

MIP48c1: Componentes de Definen al Keg

El Keg es la implementación de un contrato inteligente que permite la transmisión de DAI a diferentes direcciones. Utilizando los siguientes parámetros, el Keg puede retirar fondos del Buffer de Excedentes o redirigir fondos que de otra forma irían al Flapper, según lo dicte la Gobernanza de Maker.

Un flight es definido por el Keg como un grupo de direcciones a las que se le transmitirán DAI y la cantidad de DAI que cada dirección recibirá, en relación a la asignación completa Cada flight repreesenta una transmisión de fondos que necesitará ser asignado por la Gobernanza.

El rate es un parámetro que debe configurarse para definir cuánto DAI por segundo será transferido desde el Buffer de Excedentes en un flight específico. El parámetro rate sólo es utilizado cuando la Gobernanza desea utilizar DAI desde el Buffer de Excedentes.

El flow es un parámetro que indica el porcentaje de DAI destinados al Flapper a ser redirigidos a un flight específico. Flow sólo es configurado para iniciativas que deseen utilizar el excedente de DAI de los gastos operacionales.

Estos parámetros pueden ser utilizados para permitir a la Gobernanza de Maker realizar distribuciones contínuas de DAI para cualquier número de iniciativas. Se debería prestar especial atención a la fuente de los DAI en cada flight aprobado por la Gobernanza, ya que la transmisión de DAI desde el Buffer de Excedentes será constante mientras que la transmisión de DAI desde el excedente de ingresos variará en base al rendimiento del Protocolo.

MIP48c2: Configuración de Distribuciones Fijas a través del Keg

Cuando una iniciativa desea una tasa constante de transmisión de una cantidad de DAI, la financiación debe ser solicitada a través de la Gobernanza y sería retirada del Buffer de Excedentes. Debe enviarse una subpropuesta MIP48c2 cuando se vaya a establecer un flight nuevo o se quiera actualizar uno. Esta propuesta está sujeta a los siguientes parámetros:

  • Período de Feedback: 4 semanas.
  • Período de Congelamiento: 2 semanas.

MIP48c3: Configuración de Distribuciones Variables a través del Keg

Cuando una iniciativa desea una transmisión de DAI a tasa variable basada en el exceso de ingresos a los gastos operativos, la financiación debe ser solicitada a través de la Gobernanza. Debe enviarse una subpropuesta MIP48c3 cuando se vaya a establecer un flight nuevo o se quiera actualizar uno.

Debido a limitaciones del contrato, sólo se podrá realizar una transmisión de los fondos que de otra manera irían al Flapper. El trabajo de “backend” debe ser hecho para definir y dividir la transmisión del exceso de ingresos a cualquier iniciativa aprobada por Gobernanza. Como resultado, las subpropuestas de la MIP48c3 requerirán un período más prolongado de feedback:

  • Período de Feedback: 6 semanas
  • Período de Congelamiento: 2 semanas

MIP48c4: Detención de Distribuciones del Keg

En algunos escenarios en que el tiempo sea una cuestión sensible, los Facilitadores de Gobernanza pueden considerar apropiada una Petición de Señal para detener o pausar pagos del Keg.

Para cualquier escenario que los Facilitadores de Gobernanza no consideren urgente, se debe utilizar una Subpropuesta MIP48c4 para detener la transmisión de DAI a un flight en particular. La propuesta estará sujeta a los siguientes parámetros:

  • Periodo de Feedback: 4 semanas
  • Periodo de Congelamiento: 2 semanas

Esta es una traducción libre del artículo original en inglés, gracias a @Sebix y @alefcripto.

4 Likes