MIP31: AMM de Reserva Activa (`dss-ara`)

MIP31: AMM de Reserva Activa (dss-ara)

Preámbulo

MIP#: 31
Título: AMM de Reserva Activa (`dss-ara`)
Autor(es): Alexis
Colaboradores: n/a
Tipo: Técnica
Estado: Por definir
Fecha de Propuesta: <yyyy-mm-dd>
Fecha de Ratificación: <yyyy-mm-dd>
Dependencias: el módulo keg (https://github.com/makerdao/keg)
Reemplaza: n/a
Licencia: AGPL3+

Referencias

Reseña abreviada

Esta MIP es una propuesta técnica para una reserva activa basada en el contrato de Uniswap V2.

Reseña extendida

Actualmente la gobernanza usa el surplus buffer (búfer de excedentes) como reserva, cuando en realidad el surplus buffer no ha sido diseñado con este propósito debido a su naturaleza. El búfer de excedentes debe ser una reserva de seguridad del protocolo para tenedores de Dai en caso de fallo. En consecuencia, debe ser considerado en alguna medida como parte del colateral, puesto que es redistribuido a los tenedores de Dai en caso de emergenia. Esta propuesta busca sumarle a Maker una pieza faltante: la Reserva Maker.

Es una propuesta técnica para crear una reserva para tenedores de Maker basada en el AMM (Automatic Market Maker) de Uniswap V2. Utiliza DAI y MKR como activos dentro de un pool de liquidez y como par de intercambio. La propuesta le posibilitará a MakerDAO construir su propia reserva. Como efectos secundarios también debería:

  • Aumentar la eficiencia del proceso de quema - swap versus subasta dutch
  • Aumentar la estabilidad de precio de MKR al crear un búfer
  • Ser una pieza importante para mejoras futuras:
    • Liquidación de cantidades pequeñas
    • Reducir la ineficiencia de la quema
    • Swap de Oasis
    • Etcétera. (DeFi se basa en AMM).

El AMM con el par DAI/MKR tendrá un efectivo similar en el mecanismo de quema. En lugar de quemar depositaremos 1/2 de MKR y 1/2 de DAI. El módulo le permitirá a la gobernanza extraer DAI, MKR o ambas. Estará conectado al keg.

Componente - Nueva prestación

La lógica general está basada en Uniswap V2: https://github.com/Uniswap/uniswap-v2-core/blob/master/contracts/UniswapV2Pair.sol

El mecanismo de swap no cambiará; solo se depurarán parámetros de tarifas y mecanismos sin uso. mint y burn serán reemplazados por deposit y withdraw. Pare prevenir eventuales problemas estos nuevos métodos serán colocados detrás de una lista de permisos. Solo el swap debe ser “externo”.

Lista de modificaciones a aplicar:

Tarifas

swap()

MIP31a1: las tarifas deben ser parametrizadas y gestionadas por la gobernanza con el parámetro fees .

_mintFee()

MIP31a2: _mintFee debe removerse. Las tarifas de entrada no se aplican en este caso. Debemos remover el método y las llamadas a él.

skim()

MIP31a3: puede ser removido.

Mint y Burn

UniswapV2ERC20

MIP31b1: Remover la implementación del token.

Mint()

MIP31c1: Remover la generación de tokens, el método _mint()

MIP31c2: Renombrar el método como deposit().

MIP31c3: No se necesitan parámetros.

MIP31c4: Debe formar parte de la lista de permitidos y ser accesible por keg y gov para hacer extracciones.

Burn()

MIP31d1: Remover la destrucción de tokens, el método _burn()

MIP31d2: Renombrar el método como withdraw().

MIP31d3: Debe formar parte de la lista de permitidos y ser accesible por keg y gov para hacer extracciones.

Dos opciones aquí

Opción 1:

MIP31e1: Debe ser capaz de extraer cualquier cantidad de ambos tokens.

MIP31e2: Son necesarios tres parámetros: amount0Out, amount1Out, addressTo

Opción 2 (opción segura):

MIP31g1: Debe ser capaz de pedir la extracción de cualquier cantidad de Dai.

MIP31g2: La acción de extracción tomará la misma cantidad de Dai y de MKR. El MKR es quemado.

MIP31g3: El Dai es transferido al búfer de excedentes o a cualquier vault pasado como parámetro al momento de la creación.

MIP31g4: Es necesario un parámetro: amountOut

MIP31: ¿Cómo funciona?

El depósito inicial (50% DAI, 50% MKR) debe ser relativamente alto para tener alguna liquidez — probablemente alrededor de 500K cada uno. Cuanto más pequeño es el depósito, tanto mayor es el deslizamiento (slippage).

La idea es redireccionar algún porcentaje de DAI desde el mecanismo de quema de MKR hacia el AMM. Cuando el Dai esté dentro del AMM hará que el precio de MKR baje y creará un incentivo para comprar el MKR contra el mercado. Nótese que el deslizamiento debe reducirse cuando la liquidez aumenta. (Con 500000 Dai dentro del AMM y 10000 Dai dentro deberíamos tener un deslizamiento de alrededor de 1%). Podemos ajustar el porcentaje tomado para controlar el deslizamiento.

Existen dos opciones para el método de extracción. La primera opción: podemos extraer cualquier cantidad de DAI o de MKR o de ambos, pero habrá deslizamiento. Puede extraerse DAI por cualquier motivo y hacia cualquier dirección; la dirección es pasada como parámetro. (El método está en una lista blanca — gobernanza). Lo mismo para MKR. Podemos extraer la misma cantidad de MKR y DAI sin deslizamiento, quemar el MKR y usar el Dai.

La segunda opción es más segura. Nótese que usar solo una lista blanca (primera opción) es común en MakerDAO. No permitiremos que el contrato extraiga ninguna moneda. En cambio quemaremos el MKR y transferiremos el Dai al búfer de excedentes o a cualquier vault predefinido. De esa manera incluso si el contrato/método es comprometido no habrá una forma fácil de transferir el depósito a cualquier dirección.

Una pequeña tarifa es recolectada con cada swap y la tarifa es gestionada por la gobernanza. (Uniswap utiliza un porcentaje fijo). Aunque yo sugeriría igualar la tarifa del PSM, 0.1% o incluso menos, 0.04% como Curve. No debemos olvidar que cobramos por el DAI dentro y que la idea era quemar el MKR.

En última instancia, espero que el AMM sea más eficiente que la subasta dutch.

Además podemos añadir más reserva basada en Dai. Podemos redireccionarle pequeñas liquidaciones y reducir el dust (mínimo). Podemos intercambiar MKR a ser quemado. Podemos añadir el swap a Oasis, etcétera…

MIP31: Seguridad

Contrato de Uniswap

Errores o vulnerabilidades de seguridad en el contrato de Uniswap. El contrato ha sido largamente usado y está bien probado.

Riesgo técnico de la modificación del contrato

Además del riesgo técnico inherente al contrato de Uniswap, esta implementación añade otros riesgos. Sin embargo, debido al diseño y a la separación del sistema principal, las peores pérdidas posibles se limitan a lo depositado en el AMM. Creo que sería bueno auditarlo.

MIP31: Consideraciones económicas y de gobernanza

Riesgos económicos

Pérdidas impermanentes, el famoso "impermanent loss"

Diferencia entre AMM y la quema

  • 1/2 MKR y 1/2 DAI están lockeados contra 100% de MKR quemado.
  • Con el AMM no disminuye el suministro de MKR.
  • Debido a las pérdidas impermanentes y a la naturaleza del AMM, la cantidad de tokens depositados cambiará dependiendo de la fluctuación de precios.
  • La reserva del AMM puede ser recuperada. El MKR quemado no puede recuperarse, aunque sí puede ser acuñado nuevamente.

Un buen plus es que la reserva de Dai aumenta cuando se reduce el MKR, que es cuando necesitamos la reserva. Por otro lado, la reserva de Dai disminuye cuando aumenta el MKR, pero esto no debería ser un problema ya que podemos acuñar MKR en su lugar.

MIP31: Licencia


Esta es una traducción libre del artículo original publicado por @alexis. Gracias a @blimpa y a @Lozadaluis12

3 Likes