Stablecoin backed by any collateral
Last updated
Last updated
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.
The structure and the underlying logic are similar to the conditional lending pool, 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
Borrowers: They borrow rmUSD against any accepted collateral, or propose 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.
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.
staked rmUSD holders: They stake their rmUSD and receive the senior tranche portion of all the isolated debt pools approved by the protocol.
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.
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.
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
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)
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.
The more longZCB_i bought(pre-apprvoal) or issued(post-approval), or the less shortZCB_i bought, the higher the debtCapacityof i. debtCapacity signifies the total amount of borrowable rmUSD for a given collateral. When longZCB_i is redeemed, the debtCapacity of i will decrease.
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).
longZCB_i will accrue a junior tranche share of the yield generated by the debt from borrowers who borrow against collateral_i.
staked rmUSD holders will accrue a senior tranche share of the yield generated by the debt from borrowers from all isolatedDebtPools.
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.
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 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.
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.
