MIP21: Real World Assets - Off-Chain Asset Backed Lender

[mrabino1]

MIP21: Real World Assets - Off-Chain Asset Backed Lender

MIP#: 21
Title: Real World Assets - Off-Chain Asset Backed Lender
Author(s):  Matthew V Rabinowitz (@mrabino1 or [email protected])
Contributors: Lev Livnev (@equivrel) & Christopher Mooney (@cmooney)
Type: Technical
Status: Accepted
Date Proposed: 2020-09-01
Date Ratified: 2020-10-27
Dependencies: MIP13c3-SP4 (Declaration of Intent - Off-Chain Asset Backed Lender to Onboard Real World Assets as Collateral for a DAI loan)
Replaces: n/a
License: n/a

References

• MIP13c3-SP4 - Declaration of Intent Link
• prototype source code

Sentence Summary

This proposal defines a MakerDAO Module implementation for DAI borrowing with Real World Asset Backed Lenders.

Paragraph Summary

With the proposed on-boarding of Real World Assets as collateral into the Maker protocol, we will be requesting a technical MIP as we need to trailblaze a new way to engage the “real-world” while still having an umbilical to the blockchain. This will require some technical modifications to how the system handles collateral / liquidations etc. as well as adding some smart contracts (as outlined below) to handle the minting and repayment process. This Technical MIP is being submitted in parallel (with the Declaration of Intent) for MKR governance consideration.

Component Summary

MIP21c1: Collateral Parameters where the per-collateral asset parameters are defined.

MIP20c2: Smart Contract Components where the contracts novel to this proposal are listed and described.

MIP20c3: Liquidation Oracle where the details of the liquidation oracle contract are described.

MIP21c4: Write-offs where the process for writing off losses is described.

MIP20c5: Proposed Code where the proposed code is linked.

MIP20c6: Test Cases where the test cases are listed.

MIP20c7: Security Considerations is See Below

MIP20c8: Auditor Information and Report is See Below

Motivation

See paragraph summary above.

Specification

MIP21c1: Collateral Parameters

• Liquidation remediation period (tau):
• Asset document hash (doc):

MIP21c2: Smart Contract Components

Inserting real world assets via an off-chain asset backed lender, where the liquidations are handled by a third-party requires certain changes to how a module would interact with the Maker protocol. Specifically,

• Minting
• Repayments
• Liquidations
• Write-offs

The above said, many items remain un-changed from the current mechanism:

• Debt computation
• Interest Rates
• Debt Ceiling Constraint

The smart contracts implementing the new functionality are as follows:

• RwaLiquidationOracle: which acts as a liquidation beacon for an off-chain enforcer.
• RwaFlipper: which acts as a dummy liquidation module in the event of write-offs.
• RwaUrn: which facilitates borrowing of DAI, delivering to a designated account.

Administrative items to be completed prior to implementation

• RwaDeploySpell: which deploys and authorises the components for RWA collateral types.
• RwaInitSpell: which activates a new RWA collateral type.
• Auxiliary wallet contracts for handling disbursement and repayment of DAI.
• RwaLiquidateSpell: which allows MakerDAO governance to initiate liquidation proceedings.
• RwaRemedySpell: which allows MakerDAO governance to dismiss liquidation proceedings.
• RwaWriteoffSpell: which allows MakerDAO governance to write off a loan which was in liquidation.

MIP21c3: Liquidation Oracle

Instead of performing liquidations via on-chain public auctions, triggered by a continuously updated price feed, liquidation is triggered manually by MakerDAO governance and is enforced off-chain by a third party. The standard oracle and auction infrastructure are replaced by a “liquidation oracle” contract. MakerDAO governance can initiate liquidation proceedings, when they deem it necessary, by calling tell() on the RwaLiquidationOracle. This starts the countdown, and after the remediation period has passed the oracle will start to report that the position is under liquidation. If the cause for triggering liquidation has been remedied, or if the original liquidation trigger was illegitimate, during the remediation period, or after, MakerDAO governance can dismiss the liquidation proceedings by calling cure().

An off-chain enforcer (such as a trustee, etc.) can periodically check the liquidation status of the position by calling good(). good() will report that the position is in liquidation if and only if MakerDAO governance has triggered liquidation with tell() and the remediation period has passed without cure() being called.

MIP21c4: Write-offs

If at the end of the liquidation process there is still debt remaining on the position, and MakerDAO governance believes that the debt will not be paid off, it can trigger a write-off by calling cull(). Write-off works by setting the system’s collateral value to zero, which will cause the position to proceed to on-chain liquidation via bite(), etc. Unlike the liquidation modules for existing collateral types, the specialised liquidation module RwaFlipper does not attempt a sale of the underlying collateral and instead just marks the loss on the system’s balance sheet by allowing system debt to be created.

MIP21c5: Proposed Code (WIP)

Real World Assets Example

MIP21c6: Test Cases

• Add Real World Asset Module
• Mint DAI
• Repay DAI
• Modify Annual Interest Rate
• Emergency Shutdown
• Liquidate Vault
• Write-off any associated losses

MIP21c7: Security Considerations

The framework surrounding minting and repaying DAI is rather battle-hardened. Further, the computation on interest rate calculations and debt ceilings is equally hardened.

Counterintuitively, the majority of the functionality related to liquidations will be completed by real world people that are using legal documents to govern their actions. Thus many of the features that might otherwise cause security vulnerability may be disabled as they are effectively outsourced to a Trust company or the legal system in general.

Prior to any executive vote, the smart contracts domain team shall determine if formal verification is necessary.

MIP21c8: Auditor Information and Report

The code has not been audited.

Prior to any executive vote, the smart contracts domain team shall determine if an audit and bug bounty program is necessary.

Additional Information

Mint Process

All smart contracts below are owned by and controlled by MKR Governance, not LendCo.

1. With a smart contract triggered by LendCo and another MKR holder, the DAI created is sent to a “Tax Favorable Entity” (“TFE”) ETH address.

   1. Minting was “gated” by LendCo but not caused by LendCo
   2. DAI is now created and at the TFE
   3. The ETH address for the TFE is controlled and may be subsequently modified by MKR Governance.

2. Anyone with MKR may trigger the smart contract to move the DAI from the TFE to the Trust (w/ one exception. LendCo is specifically excluded as a party that can cause this).

   1. DAI is now being borrowed (from the TFE to the Trust). The DAI is now at the Trust.
   2. The ETH address for the Trust is controlled and may be subsequently modified by MKR Governance.

3. LendCo may then borrow DAI / USD (1*) from the Trust.

   1. The LendCo recipient target ETH address is changeable by MKR Governance.
   2. LendCo’s ETH address shall be a confirmed / validated, constant address for a registered broker-dealer OTC desk FBO of LendCo. (Note: based on (1*), it might be the Trust or Trustee that has the broker-dealer OTC desk account.)

The above process removes the custody risk for the DAI and inserts a process for accounting to track that DAI was minted into existence to a TFE, then moved from TFE to a jurisdiction specific “trust” account (or its equivalent). From there, the DAI is borrowed from the Trust when it is called upon by LendCo.

In reverse,

1. LendCo sends fiat wire to the broker-dealer OTC desk. (1*)
2. OTC desk converts fiat to DAI.
3. OTC desk orders the transfer of DAI to a previously validated ETH address (which is a smart contract) which was requested by LendCo
4. That Smart contract address is and represents the “Trust.”
5. Thereafter anyone that has MKR can cause that DAI to be transferred to the TFE ETH address.
6. Finally anyone can cause the TFE ETH address to pay down the Vault balance.
   • The above said, the underlying functionality will always exist that will allow anyone to pay down this vault.

(Note: based on (1*), it might be the Trust or Trustee that has the broker-dealer OTC desk account, not LendCo.)

Note: None of the addresses above are “owned” or controlled by LendCo. The addresses are Always with MKR governance. Important add-on: it is important for the DAI to have a source of origination; a stop in TFE; another stop in the Trust;. and then to its final destination. In all cases, LendCo / the Trust / TFE need a paper trail for accounting and regulatory compliance. The reasons for the gating of DAI minting and movements is that DAI loans may not be caused from minting to LendCo without the explicit assistance from someone else in the MKR community.)

Operational Security

Given the size and centralization of an off-chain asset backed lender, OpSec is a critical component to be hardened prior to any material debt ceiling being allocated. To that end, it is presently contemplated that LendCo will have its Vault adapter be modified away from the default (where DAI is returned to the originating ETH address) since we are planning to implement the above minting and repayment process.

The foregoing serves three purposes:

1. To minimize the attack surface to as little as possible on the minting of DAI
2. To allow for LendCo to clear a financial audit, as Broker / Dealer will issue account statements that outline the arrival of DAI and the sales/purchase price.
3. The Broker / Dealer has already completed KYC / AML on all of the cash that is used in exchange for the DAI (in both directions).

---

Footnotes

1* - At present, it is unknown if the Trustee will require direct engagement to provide the loans from the Trust to LendCo to facilitate each closing or not. Further, it is unknown if the Trustee will allow the conversion of DAI to USD to be done at LendCo or if they will require that they do the conversion with an account that is in their name F/B/O the Trust. This MIP is giving latitude for adjustment surrounding the flow of DAI / USD to meet the requirements of the Trust Company to be willing to serve as the Trustee of the Trust.

[MakerMan]

I am still trying to digest this so right now I only have one question.

IF (and I consider this becoming less and less likely for multiple reasons) an ES is activated exactly how would this facility be settled for DAI holders?

My concern here is that this particular facility will have to recify differently during an ES than other collateral types that are ‘non-binding’ in the sense that anyone owning DAI can redeem for their share of MCD assets within what 24-48hrs after an ES and that there is little to no impairment for the DAI holders to do this. (they don’t have to be reg-D investors or another type of financial manager)

Rather than me speculate as to how this would be handled for this particular facility perhaps you and/or Lev could explain how this facility would be handled with respect to an ES.

[mrabino1]

answered in the MIP13 thread.

MIP13c3-SP4 Declaration of Intent & Commercial Points - Off-Chain Asset Backed Lender to onboard Real World Assets as Collateral for a DAI loan

@MakerMan excellent question… Following on with @g_dip 's comment, the Trust views the MKR tokens holders as the beneficiaries. The Trust is a legal entity with a Trust company as the Trustee. Unless they are specifically noticed, they will make the assumption that all is well and no “liquidation” has been instructed. So now insert the edge case of the Emergency Shutdown of the Maker protocol. It is also important to recognize there are fundamentally two scenarios for the ES. 1.) Something ba…

[Akiva]

Overall great post.

Rather than pricing the interest rate comparative to the Maker “Base Rate,” this proposal contemplates competing directly on terms the financial system uses today which means that we should use the Wall St. Prime Rate as the benchmark with a spread above or below (as LIBOR is in process of retiring).

Can you elaborate more on this?
Generally MakerDAO uses the Base Rate mechanism to match its assets to liabilities. Any deviation from such practices could interfere with the system. Consider if 50% of the portfolio was RWA priced without Base Rate then any DSR hike would be amplified by 2x to the remaining Vault users that had a Base Rate determined SF. I imagine that would be an undesirable outcome.

[mrabino1]

@Akiva Excellent topic to discuss. A few observations first to frame the response. There have been multiple discussions in the past RE the Base Rate and needing a new model. Events like yield farming have already shown a need for a new structure for how RP will be implemented in the future. I do not want to opine too much on how that should be done as I am sure the Maker team has a plan.

The above said, for a revolver, this needs to be a “market” transaction that competes with (and beats) the traditional system. The traditional system prices a spread +/- off of Prime. For thus structure, my proposal would do the same.

As was debated last year at length and also in a recent post of mine (Economics behind Real World Assets (“RWA”) - Part 2), real world assets (emphasis on those that are credit backed) have interest rate sensitivity that the rest of the crypto market just doesn’t have (yet).

Based on the MIP13 proposal, there is room for the DSR to be included. The end borrower rate (the ultimately cost of capital) is what was proposed based on an industry metric. How that is broken down behind the scenes is for the community to decide.

[LongForWisdom]

Hey @mrabino1 + @equivrel , Gonna go through and leave notes. Hopefully they’re useful.

@mrabino1

MIP13c3-SP4 - Declaration of Intent

This should link to the github version at some point. Possibly in addition to the forum thread.

@mrabino1

With the proposed on-boarding of Real World Assets as collateral into the Maker protocol, we will be requesting a technical MIP

This is that technical MIP?

@mrabino1

Paragraph Summary

This should be a summary of what is actually in the MIP, rather than motivation which should go in the Motivation section.

@mrabino1

Component Summary

This heading isn’t for listing smart contract components, it’s for listing and summarizing the components of this MIP. So this should include:

• Proposed Code
• Test Cases
• Security Considerations
• Auditor information and report

etc. In addition each of these should have a MIP component code. IE: MIP21c1, MIP21c2, etc. If you want to list the smart contract components, that seems sensible, and I’d probably provide links to the code as well. I would suggest that goes into the proposed code section.

@mrabino1

Proposed Code

There should be more detail here, and explanation of how the new code works, and why it works in that way. I’d like to see links to the different components, descriptions of what they do, etc. Compare to MIP22c4.

@mrabino1

Test Cases

This should go into more detail. What do these tests cover? Why are they important? Which version of the code have they been run against? Does this cover the full spectrum of functionality? Edge cases, etc.

@mrabino1

Security Considerations

I don’t have a great idea of the security considerations, so going to reserve judgement here. This might be fine, would like to get an opinion from the Smart Contracts domain.

@mrabino1

The code has not been audited.

Is this planned to be audited at some point? If not be an auditor, at least by the Smart Contracts domain team?

@mrabino1

Additional Information

There’s a lot in this section, which I suppose makes sense because there is a lot to cover. I’d much prefer if this section was broken up into its own components with their own MIP-Component codes though. This makes it easier to reference and easier to consume.

Will hold off on reading over and understanding the content for the time being because it’s late. I will do so in the near future. Hopefully after this has been structured to more closely follow the MIP templates and guidelines.

[charlesstlouis]

This proposal has been moved to the Request for Comments (RFC) phase and will have a 1 month feedback period before being eligible for Formal Submission.

[cmooney]

I’ve reviewed both the declaration of intent and this technical MIP, as well as the prototype code. As a member of the Smart Contracts Domain Team, I think this is ready for a vote.

There is still work to be done in the code, but it’s mostly trivial and should not block the process of this MIP. The prototype still needs some example spells to perform governance actions, some unit tests, and a small fix to the flip contract to bring it up-to-date with LIQ-1.2.

On the engineering side, once this MIP is ratified, we can continue by freezing the code for a final review and possible formal verification, audits, and bug bounty. As I understand it, while this process is happening, @mrabino1 will be putting in a considerable amount of off-chain work and expense to ensure the legal structures are in place to support this MIP. This should give the technical stake holders time to complete their due diligence.

[mrabino1]

This proposal has been moved to the Formal Submitted phase. While the proposal itself cannot change, please continue to ask questions publicly or privately.

[joel]

@mrabino1

Hey, I know I’m late to the table. Some thoughts I’d love to get your feedback on.

The above said, for a revolver, this needs to be a “market” transaction that competes with (and beats) the traditional system. The traditional system prices a spread +/- off of Prime. For thus structure, my proposal would do the same.

Is that not concerning? There are professionals who compete daily to provide the best interest rates, balancing risk and reward. Given that we’d definitely be worse at this than these professionals, would we have a winner’s curse of getting debt that the market doesn’t otherwise want to buy? Is the thought that the CRs would be higher than people would get otherwise? This seems like the only debt people should give to Maker would be debt that we’d get at worse terms than the market, no?

To me this seems like one of the big reasons why people don’t like Tether. They invest the float in assets they aren’t more or less guaranteed to be paid back on and run the risk of being under-collateralized.

RWA seems like a great idea to me in theory, but I’m trying to wrap my head around how we’d do it in a way that doesn’t cause Maker to take losses (since we’ll be worse at it than a real bank). Please let me know what, if anything, I’m missing here.

[Joshua_Pritikin]

@joel

Given that we’d definitely be worse at this than these professionals

Why? Assume we can balance risk and reward, we should be able to out-compete traditional lenders because there is no middleman. Cost of capital is essentially zero. DAI is ultimately backed by faith in the Maker protocol.

[joel]

@Joshua_Pritikin

there is no middleman

We’re the middlemen here, right? Somehow we’re paying someone to assess the risk of any assets we onboard, right? (Unless we accept any assets, which would obviously sink us.) Banks pay armies of PhDs to model out the assets they onboard. I assume we won’t be doing that, so we’ll definitely be worse at it (unless we can beat the market with less work for some reason I’m missing).

Cost of capital being effectively zero is a great point. My understanding is that banks themselves also have effectively 0 cost of capital at the moment (0.08%? which might be comparable to the gas costs of dealing with Maker depending on the size of the loans involved, but I think Maker should be able to have big/long enough loans where that’s not a factor), but I imagine that will change over time. However, an edge of 0.08% doesn’t seem like it should make up for our disadvantage at pricing RWA, does it?

[mrabino1]

@joel

Is that not concerning? There are professionals who compete daily to provide the best interest rates, balancing risk and reward. Given that we’d definitely be worse at this than these professionals, would we have a winner’s curse of getting debt that the market doesn’t otherwise want to buy? Is the thought that the CRs would be higher than people would get otherwise? This seems like the only debt people should give to Maker would be debt that we’d get at worse terms than the market, no?

To me this seems like one of the big reasons why people don’t like Tether. They invest the float in assets they aren’t more or less guaranteed to be paid back on and run the risk of being under-collateralized.

RWA seems like a great idea to me in theory, but I’m trying to wrap my head around how we’d do it in a way that doesn’t cause Maker to take losses (since we’ll be worse at it than a real bank). Please let me know what, if anything, I’m missing here.

Excellent question and happy to provide some color at least from my lens.

MakerDAO is not “buying” debt from the market. If that were the case, I can definitely see your perspective and concern. In this context, what is contemplated is that Maker is providing credit to an external lending party, nicknamed “LendCo” for short, via a Trust legal structure. The Trust is fundamentally the legal representation of the DAO and the DAO will be the beneficiary (as such, let’s just remove the entire notion of a blockchain) and just focus on three entities (BorrowCo, LendCo, and the Trust).

When I reference that the deal needs to be a “market” deal (or slightly better), the context behind that is one of pure competition. Unlike crypto loans (or loans against digital collateral), the “analog” credit system is exceptionally advanced and well priced. Forget the Trust for a moment, if LendCo tries to do an “out of the market” deal that is too expensive, BorrowCo will just go somewhere else (as we all would). LendCo is lending USD to BorrowCo, so demand in this context is quite elastic the moment we get near “market” pricing.

Now, let’s back our way back to the deal between LendCo and the Trust. With the mindset that the Trust is the embodiment of the DAO, the Trust is broadly a corollary to being the Central Bank in this equation. It is not the middleman. It is the anchor senior money, the money that is the most de-risked (and should be priced accordingly). LendCo is company that is the operating business of lending capital to willing borrowers. With all of that said, if LendCo prices the money out of the market (e.g. too expensive) then BorrowCo will walk. A similar theme will also apply to LendCo. The deal between LendCo and the Trust must be market competitive. If the Trust starts to have money that is too expensive comparative to the market, LendCo will start to shop around (as it should).

As for how we will correctly price that risk, initial pricing (between LendCo and the Trust) has been provided and it is competitive, though competitively less than a bank would charge. For Real World Assets, it is imperative to allow the control levers of an off-chain lender to be adjusted by the DAO. Along with the debt ceiling and interest rates, it is essential that the DAO retain the ability to approve the scope and underlying credit quality of where the capital ultimately goes. By doing this, the DAO can control and price accordingly that cost of capital.

[SebVentures]

I would add that even if banks can borrow cheaply, they still have regulatory constraint (Basel 2/3) and obviously have a cost of capital that blend deposits/borrowing and equity. The later is above 10% I guess.

On the Maker side, even a net neutral investment (with RWA specific costs) can be a good opportunity. 1. It gives us knowledge of the space. 2. It helps our peg issue that reduce the DAI value. 3. It reduces our risk profile thanks to the diversification.

[mrabino1]

This MIP21 has now passed governance with an executive vote.