# Stablecoin backed by any collateral {% hint style="info" %} Summary: rmUSD is an overcollateralized stablecoin that can be backed by any collateral with an oracle, including but not limited to PFP NFTs, univ3 LP positions, ERC20s, tokenized vaults, etc. It requires no to minimal governance and can be a completely automated mechanism. The collaterals and oracle reliability are assessed and approved by **managers** who provide skin in the game. After a collateral is approved, it is continuously re-evaluated by the managers. The cost of pricing risks and insurance is subsidized by the interest paid by the borrowers. We show below that market-driven underwriting can easily unlock liquidity for any long-tail assets. {% endhint %} The structure and the underlying logic are similar to the [conditional lending pool](https://limitless.gitbook.io/ramm/instrument-examples-and-usage/conditional-lending-pool-clp), where managers would be assessing the riskiness of lending to *any* collateral, but instead the borrowed capital is not from external LPs. Instead, RAMM as a protocol acts as the borrower by issuing rmUSD. A RAMM Vault would be analogous to staked rmUSD, in that they accrue pooled senior tranche portions of the total interest generated by *all* outstanding debt. There are 4 participants 1. **Borrowers**: They borrow rmUSD against any accepted collateral, or [propose](https://limitless.gitbook.io/ramm/protocol-flow/proposal) a new collateral to be accepted by the rmUSD `printer`, along with associated parameters such as LTV, interest rate curve, oracles, etc. They repay with interest. 2. **Managers**: They underwrite the collaterals & associated parameters accepted by the `printer`, and in doing so take a junior tranche of the isolated debt pool **of only** the collateral they are underwriting. 3. **staked rmUSD holders:** They stake their rmUSD and receive the senior tranche portion of **all** the isolated debt pools approved by the protocol. 4. **rmUSD holders**: They gain the most protection from potential bad debt and forego any yield generated by the system. Instead, they only gain price stability. Each isolated debt pool for each collateral A borrower wants to take a loan against collateral #n, an arbitrary asset. If this collateral #n is supported by the rmUSD issuing contract `printer` then he can take an instant rmUSD loan from the protocol. If not, he would have to *propose* a new `isolatedDebtPool` which supports this new collateral, which would go through the canonical(but slightly different) protocol [phases](https://limitless.gitbook.io/ramm/protocol-flow). ### Rules The following structure will apply. Note that `longZCB_i` is a tokenized junior tranche of investing in instrument\_i. In this case the instrument is the `isolatedDebtPool_i` which accrues interest paid by the borrower with collateral\_i 1. For a collateral\_i newly proposed, managers would buy `longZCB_i` with rmUSD if he believes the `isolatedDebtPool_i` will not incur bad debt, given the associated parameters(LTV, oracles, etc) 2. For a collateral\_i newly proposed, a rmUSD holder would buy `shortZCB_i` with rmUSD if he believes `isolatedDebtPool_i` will incur bad debt. This will give him protection against potential bad debt for collateral\_I. 3. The more `longZCB_i` bought(pre-apprvoal) or issued(post-approval), or the less `shortZCB_i` bought, the higher the `debtCapacity`of i. `debtCapacity` signifies the total amount of borrowable rmUSD for a given collateral. When `longZCB_i` is redeemed, the `debtCapacity` of i will decrease. 4. A borrower that borrowed against collateral\_i repays his loan with **interest**, and the **proceeds are split between** the `longZCB_i` holders(**junior** tranche) and the staked rmUSD holders(**senior** tranche). 5. `longZCB_i` will accrue a junior tranche share of the yield generated by the debt from borrowers who borrow against collateral\_i. 6. staked rmUSD holders will accrue a senior tranche share of the yield generated by the debt from borrowers from **all** `isolatedDebtPools.` 7. If `isolatedDebtPool_i` incur bad debt, then rmUSD used to buy `longZCB_i` will be used as first loss capital and will be burned. After this first loss capital is depleted, the rest of the bad debt will be incurred by staked rmUSD holders, where their staked portion will be burned, see figure 1. After *both* `longZCB_i` holders and staked rmUSD holders' funds are depleted, loss will finally be socialized by regular rmUSD holders. Figure 1. Chart of time vs price of rmUSD ### How would collaterals be continuously assessed? The design provides an elegant mechanism for continuously pricing the risk of all accepted collaterals without governance or centralization. First, note that managers can issue new `longZCB_i` or redeem their `longZCB_i` anytime after collateral\_i is approved. They would issue to gain exposure to yields generated by collateral\_i, or they would redeem to realize profit and offload risk from collateral\_i. Also note the more `longZCB_i` issued, the higher the `debtCapacity(`total amount of borrowable rmUSD) of i. When `longZCB_i` is redeemed, the `debtCapacity` of i will decrease. When managers believe the risk-reward of lending to collateral\_i has increased, they can issue new `longZCB_i` (to be exposed to yield generated from collateral\_i), which will increase the `debtCapacity` for collateral\_i. This would mean borrowers can borrow more using collateral\_i. When managers believe the risk-reward of lending to collateral\_i has decreased, they can redeem their `longZCB_i` (to realize profit and offload risk from collateral\_i), which will decrease the `debtCapacity` for collateral\_i. This would mean borrowers can borrow less using collateral\_i. As a system, this introduces a market-driven mechanism to limit or expand borrowing capacity for a given collateral. ### Liquidations Liquidations will be conducted via dutch auctions, where the rmUSD proceeds will be burnt. Solvency and/or liquidation conditions will be triggered by oracle\_i, where oracle\_I is among the parameters assessed by the managers for collateral\_i. ### Stability The max price of rmUSD will be capped by the LTV of the most liquid collateral supported by the system. For example, if ETH is supported by the system at an LTV of 110%, arbitrageurs will set the max price of rmUSD will be 1.1. The min price of rmUSD will be capped at 1, assuming the system stays solvent. Below the peg, arbitrageurs will be able to buy the riskiest debt positions from the protocol with rmUSD, where the proceeds will be burnt.