From 941b56d312602d87295db5f807cd2bd9b5f3cdb6 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Wed, 17 Feb 2021 22:24:46 -0500 Subject: [PATCH] Describe the risk manager role --- docs/risk-manager.adoc | 75 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 docs/risk-manager.adoc diff --git a/docs/risk-manager.adoc b/docs/risk-manager.adoc new file mode 100644 index 00000000..b2208d72 --- /dev/null +++ b/docs/risk-manager.adoc @@ -0,0 +1,75 @@ += The risk manager + +The risk manager holds a privileged role over the coverage pool. It maintains +the ability to claim coverage from the pool, liquidating enough collateral from +the pool to cover an outstanding obligation. + +Because of the nature of the role, the risk manager is a critical component of +the coverage pool. Depending on the implementation, a risk manager can determine +whether to put assets at capped or uncapped risk; how quickly auctions should +put collateral up on offer; whether to end an auction early; and whether to +remunerate existing underwriters in the case of "extra" assets on hand from an +auction. + +== An example pool + +The tBTC v1 coverage pool has one purpose — to backstop the TBTC peg and +simplify the lives of signers by guaranteeing to take any outstanding TBTC +liquidation, trading TBTC for ETH. + +Because we have no guaranteed bounds on the ETHBTC price, the risk to the pool +is technically uncapped; if the price of BTC suddenly 10x's relative to ETH, the +pool is still on the hook for a fixed amount of BTC. On the other hand, once the +pool takes a TBTC https://docs.keep.network/tbtc/#liquidation[liquidation +auction], the resulting ETH proceeds should be distributed back to the pool. + +== Auctions + +When the risk manager claims coverage, it specifies an amount denominated in +the asset the pool covers. An auction is opened across across all assets in the +pool, increasing the portion of the pool on offer over time. Eventually, the +entire collateral pool is on offer. + +For an auction to be filled, a participant pays the asking price, and in return +receives a portion of each asset in the pool. + +Consider a collateral pool containing 10 WBTC and 100 WETH, and claim of 1 TBTC. + +.A collateral pool under auction +[frame="topbot",options="header"] +|============================================ +|Time | Offer | WBTC on offer | WETH on offer +|1 |1% |0.1 |1 +|2 |2% |0.2 |2 +|3 |3% |0.3 |3 +|4 |4% |0.4 |4 +|5 |5% |0.5 |5 +|6 |6% |0.6 |6 +|7 |7% |0.7 |7 +|8 |8% |0.8 |8 +|9 |8% |0.9 |9 +|10 |10% |1 |10 +|============================================ + +For simplicity, assume WBTC and TBTC trade at parity. Regardless of the ETH/WBTC +exchange rate, there is a point between `t=1` and `t=10` where it makes sense to +buy all assets on offer. + +An efficient on-chain implementation can allow partial and atomic fills, opening +up arbitrage opportunities with lower total liquidity requirements. + +In addition to claiming coverage and opening an auction, the risk manager +determines the parameters that govern the auction, including the velocity of the +falling price based on market conditions, and whether to withdraw a claim and +end an auction early. + +== Returning funds + +If there are funds to return to the pool after a coverage claim, a risk manager +implementation can do one of two things + +1. Deposit the funds in the rewards pool, effectively distributing them across + underwriters based on the relative reward rate, regardless of the asset. +2. Deposit the funds directly in the collateral pool, requiring funds to be + traded to match the existing collateral distribution, or intentionally + distributing funds in a way that favors a particular underwritten asset.