MIP22: Módulo de Liquidación Directa de Centrifuge

MIP22: Módulo de Liquidación Directa de Centrifuge

Preámbulo

MIP#: 22
Título: Modulo de Liquidación Directa de Centrifuge
Autor(es): Lucas Vogelsang (@spin on forum.makerdao.com, [email protected])
Colaborador(es): Lea Schmitt ([email protected]), Lev Livnev (@equivrel on forum.makerdao.com)
Tipo: Técnica
Estado: Aceptada
Fecha de Propuesa: 2020-09-02
Fecha de Ratificación: 2020-10-27
Dependencias: ninguna
Reemplaza: ninguna
Licencias: AGPL

Referencias

Sumario Abreviado

Esta propuesta proporciona un mecanismo de liquidación de vaults para los colaterales de préstamos a corto plazo basado en Tinlake que implica dejar madurar un portafolio de dichos activos a corto plazo o refinanciarlos de forma off-chain y utilizar reembolsos de préstamos para liquidar el saldo del Vault.

Sumario Extendido

Para los préstamos a corto plazo combinados de Vaults de Centrifuge, subastar un portafolio de préstamos a corto plazo no es necesariamente la forma más eficaz para que Maker liquide un Vault. Cuando estos activos son muy ilíquidos, el descuento que un poseedor querría superar al beneficio de esperar el vencimiento de los préstamos subyacentes. Centrifuge ha construido los contratos de Tinlake para gestionar las liquidaciones de portafolios de préstamos on-chain. Este mecanismo permite a los contratos inteligentes de Maker obtener acceso directo a estos reembolsos sin la necesidad de ningún guardián externo.

Sumario de Componentes

MIP22c1: Prerrequisitos de Colateral Describe los requisitos para el tipo de colateral para hacer uso del módulo de liquidación propuesto.

MIP22c2: Mecanismo de Liquidación Describe el mecanismo mediante el cual los Vaults son liquidados cuando el adaptador descrito es usado.

MIP22c3: Definiciones Definiciones de Componentes del Adaptador

MIP22c4: Código Propuesto Una explicación de la lógica junto con el código

MIP22c5: Uso del código y Casos de Prueba Aún pendiente

MIP22c6: Consideraciones de Seguridad Aún pendiente

MIP22c7: Licencia El código tiene licencia APGL.

Motivación

Como hemos dicho en discusiones y hilos anteriores, creemos que agregar activos del mundo real (RWA) al MCD es el camino a seguir para escalar el suministro de Dai y equilibrar el portafolio de riesgo de colateral a través de activos no correlacionados.

Un problema clave que impide la adición de RWA al Protocolo Maker ha sido la ausencia de un proceso confiable para liquidar un Vault de Maker que esté respaldado por estos activos.

Cuando una entidad legal invierte en una pool de Tinlake respaldada por RWA, firma un contrato legal con el emisor y, por lo tanto, obtiene un reclamo legal sobre el colateral subyacente (el activo del mundo real).

Cuando Maker liquida un Vault respaldada por estos tokens, debe tener una forma de recuperar el DAI que se generó del Vault sin tener que firmar un contrato legal con el emisor.

Estamos proponiendo un mecanismo de liquidación que resuelve eso siempre que un Vault esté respaldado por un colateral de préstamo a corto plazo. Este mecanismo no requiere subasta ni estructuras legales adicionales. Vemos esta solución como un gran impulso para hacer realidad los RWA en MCD a corto plazo.

La solución propuesta en esta MIP requiere que el grupo de préstamos que se tokeniza a través de Centrifuge sea:

  1. De muy corto plazo y esperar el vencimiento del préstamo es económicamente viable.

o

  1. Los préstamos pueden ser vendidos (refinanciados) por el emisor off-chain y existe un proceso para la liquidación de la pool en caso de que cualquier titular de un token DROP (como Maker)

Si el componente de liquidación propuesto debe usarse para un tipo de colateral dado, debe ser parte de la Evaluación de Riesgos y discutirse activo por activo. Si esto se desea, el siguiente código debe configurarse para usarse al agregar un nuevo colateral con el voto ejecutivo de MIP12.

Especificación

MIP22c1: Prerrequisitos de Colateral

Los activos que deberían poder utilizar este colateral tienen algunos requisitos:

  • Esto solo funciona para colaterales que utilizan contratos inteligentes Tinlake de Centrifuge para tokenizar sus préstamos off-chain.
  • Debe haber suficientes inversores además de MakerDAO que aseguren el correcto funcionamiento del recurso legal.
  • Los Equipos de Dominio de Riesgo consideran suficiente este mecanismo de liquidación para el tipo de colateral.

MIP22c2: Mecanismo de Liquidación

Cuando se inicia la liquidación de un Vault, el adaptador de liquidación propuesto obliga a la pool de Tinlake a liquidarse al enviar una orden para canjear todos los colaterales dentro del Vault. Los contratos de Tinlake asignan entonces automáticamente todos los flujos de efectivo entrantes de los prestatarios a los inversores (es decir, el Vault de Maker) para reembolsos.

https://camo.githubusercontent.com/b38fa723378c051616983a99d015c10e67518e1a/68747470733a2f2f73746f726167652e676f6f676c65617069732e636f6d2f63656e747269667567652d6861636b6d642f75706c6f61645f61363562396239326131376132333539366162346330643461323430346666372e706e67


MIP22c3: Definiciones

  • Tinlake Flipper: el contrato que puede liquidar un Vault al ir a los contratos de la Pool de Tinlake para canjear DROP por DAI y luego transferir el DAI obtenido al Vow
  • DROPJoin: un adaptador basado en gran medida en GemJoin que sólo permite un contrato del grupo de Tinlake seleccionado para añadir colateral al Vault de Maker.
  • Tinlake Pool: una pool de préstamos respaldados por activos liquidados en DAI.
  • DROP: el token ERC20 de acciones de la pool senior, que se puede canjear por una parte del DAI reembolsado por los préstamos en el Grupo Tinlake

MIP22c4: Código Propuesto

El código se ha mantenido al mínimo y cualquier cambio funcional se muestra a continuación. Publicaremos un repositorio Git luego de recolectar opiniones sobre esta propuesta (que se modificará). El código completo se puede ver aquí.

Para cada pool de Tinlake solo habrá un Vault de su propiedad. La pool tendrá la lógica necesaria para administrar el Vault. Modificamos el adaptador GemJoin estándar para solo permitir el método join a ser llamado por wards (es decir, es una llamada autorizada). Esto prevendrá que cualquier otra persona pueda abrir un CDP con tokens DROP, ya que no podrán añadir el colateral al sistema.

El contrato TinlakeJoin se ve como a continuación. Nótese el modificador auth agregado en la función join. Este es el único cambio necesario.

contract DROPJoin is GemJoin {
    function join(address usr, uint wad) external auth note {
        require(live == 1, "GemJoin/not-live");
        require(int(wad) >= 0, "GemJoin/overflow");
        vat.slip(ilk, usr, int(wad));
        require(gem.transferFrom(msg.sender, address(this), wad), "GemJoin/failed-transfer");
    }
}

El Tinlake Flipper toma todo el colateral de un Vault y solicita el reembolso de la pool. Entonces, los contratos Tinlake obligan a que cualquier pago de préstamos se desembolse a cualquier poseedor de DROP que solicite el reembolso. A medida que se canjea el DAI de la Pool, el adaptador transifere el DAI en el vow hasta que se recupera tab. En ese punto cualquier DAI adicional que puede ser canjeado por el DROP es devuelto al pool.

El mecanismo de subasta es binario: desde el punto de vista económico, no sería deseable liquidar solo una parte del colateral. Por lo tanto, el mecanismo está diseñado para liquidar todo y solo después de devolver cualquier exceso de DAI recaudado a la pool.

Cuando se liquida una Vault (se llama a Cat.bite), Cat llamará a Flipper.kick que da inicio a la liquidación. Al principio, retira todo el colateral (los tokens DROP) del sistema y se coloca una redeemOrder en el contrato pool.

   function kick(address dest_, address gal, uint256 tab_, uint256 lot, uint256 bid)
       public auth returns (uint256 id)
   {
       vow = gal;
       dest = dest_;
       tab = tab_;
       vat.flux(ilk, msg.sender, address(this), lot);
       dropJoin.exit(address(this), lot);
       pool.redeemOrder(drop.balanceOf(address(this)));
       emit Kick(id, lot, bid, tab_, dest, vow);
   }

La orden de canje ahora se tendrá en cuenta siempre que los reembolsos de préstamos fluyan hacia el grupo o cuando otros inversores quieran unirse a la pool. A medida que la pool canjea los DROP, cualquier usuario puede llamar a la función take. Esto mueve el DAI disponible para retiro de la pool y reembolsa la deuda pendiente (tab) al vow o la devuelve a la pool. Este método se puede llamar varias veces para hacer que la pool disburse más DAI y lo devuelva a la pool como fondos disponibles para los prestatarios.

    function take() public {
        (uint returned, ) = pool.disburse();
        uint tabWad = tab / RAY; // always rounds down, this could lead to < 1 RAY to be lost in dust
        if (tabWad < returned) {
            dai.transfer(dest, sub(returned, tabWad));
            returned = tabWad;
        }
        if (tab != 0) {
            daiJoin.join(vow, returned);
            tab = sub(tab, mul(returned, RAY));
        }
    }

Los contratos inteligentes de Tinlake recopilan las órdenes de canje y devuelven cualquier DAI devuelto por los prestatarios proporcionalmente a todos los poseedores de tokens DROP primero. Esto significa que para recibir la máxima prioridad en el reembolso, la liquidación debe solicitar que se reembolse todo el DROP.

Esto se puede hacer estableciendo la variable dunk en uint (-1). Esto eleva el tamaño mínimo del colateral a subastar durante la liquidación por encima del colateral máximo que puede existir, lo que obliga a la liquidación de todo el Vault y no solo de parte de él.


MIP22c5: Casos de Prueba

Tinlake se está sometiendo a una auditoría que se publicará el 22 de septiembre. Modificaremos esta sección con información sobre los casos de prueba que tenemos que cubren tanto a GemJoin como al Flipper.


MIP22c6: Consideraciones de Seguridad

Esta sección se completará. Los contratos principales de Tinlake se han sometido a auditorías de seguridad en el pasado (informes) y publicaremos la auditoría que estamos realizando para el próximo lanzamiento en las próximas semanas, ya que está lista.

En cuanto a los contratos que interactúan directamente con MakerDAO (TinlakeFlipper y DROPJoin), se enviarán con una amplia cobertura de pruebas y se redactaron siguiendo la guía de estilo de contrato inteligente de MakerDAO / DappHub, no utilizan bibliotecas externas y son fáciles de auditar con un total de menos de 100 líneas de código.


MIP22c7: Licencia

  • Todo el código tiene la licencia AGPL

Esto es una traducción libre del artículo original en inglés, gracias a @Lozadaluis12 y @JoseFerrari por la traducción.