6s - RWA001-A - How MakerDAO is protected

When onboarding Real World Assets into MakerDAO, it is important to scrutinize the edge case scenarios just as we would with crypto collateral. Below is a consolidation of sections for RWA001 that provide some additional context and some scenarios that have been contemplated. Please don’t hesitate to contribute your own in the comments, as I am happy to answer.

Section 1: Some Q&As for the Smart Contracts Team
Section 2: Collateralization Ratio - The shock absorber
Section 3: Scenario analysis

Section 1: Some Q&As for the Smart Contracts Team

Q. How does governance know to call tell() to start a remediation period?

A. It is essential to understand that the Trustee will trigger the liquidation process without governance if LendCo is in material breach of the Credit Agreement. (e.g. for not meeting reporting reqs, not getting an annual financial audit, or not maintaining equity covenants, among the list of things in the Credit Agreement).
— OR
Governance via its Mandated Actors via its Maker Representatives can outline to MKR Governance why a breach has occurred and a liquidation should be triggered.
— OR
Governance decides to unilaterally liquidate (which it always retains the right to do, but is politically “not advisable”).

Q. How long should tau be for this remediation period?

A. 30 calendar days per the Documents

Q. How does Maker participate in the remediation? Everything from setting expectations, to determining success and calling cure()?

A. LendCo will work with both maker representatives and Mandated Actors to outline what actions were taken to remedy the theoretical breach with confirmation from the Trustee that any theoretical breach has been cured.

Q. If remediation fails, then good() will return false. Is this a condition that the trust company is always looking for, or are we expected to notify them to check the on-chain status?

A. Trustee will be routinely checking. We may even set it such that they get a daily / weekly email of the vault status with third-party confirmation (e.g. etherscan). In parallel, a Maker Representative will notify the Trustee which they can verify on the blockchain.

Q. Once the trust company has liquidated all the assets they can, I assume that value would be sent to the input conduit and push()ed to the RwaUrn where anyone can wipe(). Is this assumption correct?

A. Correct

Q. Let’s take each “state” of normal operation and liquidation and make sure there is a legal process to handle emergency shutdown should it occur at any state. At the end of the day, we want to ensure that DAI holders get that $1 worth of collateral at ES (even if that is basically a promissory note that they can collect principal + interest payments on).

A. The Trust is totally ignorant / blind to the events of the ES. Though an ES does technically trigger a liquidation event, it should motivate the MKR community to “restart” the protocol to cure() the triggered liquidation. Once the Trustee sees, that A) the liquidation has started, they will inform the LendCo (LendCo will likely already know) and then B) if that goes uncured and good() goes to false, they will liquidate the Trust and return proceeds no different that if tell() went uncured. At that stage, should a liquidation go the distance and we have an ES that stays shutdown, the DSS will allocate a portion of the RWA001-A token to DAI holders. (this is my understanding and is really best answered by the DSS architects)

Section 2: Collateralization Ratio - Shock absorber

To further protect the DAO, LendCo has an equity requirement covenant (in the credit agreement) that it must maintain. This is the “shock-absorber” for the system.

Below are the implied collateralization ratios


  • 100% LTC (Loan-To-Cost) = 30% Equity / 70% Debt
    Project Cost = implied collateralization ratio of 142%
    Based on the Appraised Value = implied collateralization ratio of ~157%

Stabilized Inventory:

  • 100% LTC (Loan-To-Cost) = 15% Equity / 85% Debt
    Appraised Value = implied collateralization ratio of ~117% - 129% (acquisition vs. construction->stabilized)
    ^ Note: LendCo may constrain activities further using other metrics (e.g. DSCR & LTV, etc.)

Section 3: Scenario analysis

Scenario 1: Flow of funds
TLDR: After DAI is minted, regulated entities control the DAI, not 6s. That DAI can then be returned to Maker without interacting with 6s in any way in a secure manner. Thus it is not only a conduit; it is an intentionally SECURED conduit. Further, even if 6s’ hardware wallet is compromised or staff threatened, the DAI has nowhere to go except the Trust (which can then send the DAI right back to Maker).

  • 6s mints 1MM DAI and then Matt has a heart attack the next moment (literally the next block).

    • The DAI that is minted directly to the “secured conduit” of MIP21. It does NOT go to 6s. While in the secured conduit, the only target is an address controlled by governance. That target address is the address of CayCo’s (short-hand for the entity based in the Cayman Islands) Broker (preferably a US-based Broker Dealer or well-known international cryptocurrency OTC desk). The only way governance will be willing to add an address is after it has been proven (either cryptographically or operationally) that funds that go to that DAI address come out on the other side as USD to the Trust account.
    • The Broker has irrevocable instructions to convert all received DAI to USD and deliver to CayCo’s bank account (escrow / custody account… e.g. a bank account governed with specific previously agreed instructions).
    • CayCo’s bank account (custody account) includes instructions to transfer any USD received to the Trust account and therefore will be governed by the Trust Agreement.
    • The Trustee or Trust Sponsor or LendCo retain the authority to cause the funds in the Trust account to be sent back to Maker (Note: this is an “OR” not an “AND”, any individual party can trigger the return of funds)
    • From there, cash is transferred to CayCo’s bank account (custody) which has instructions to transfer to the Broker for CayCo.
    • The Broker has irrevocable instructions to send all USD received to convert USD to DAI and to send it to the address of the secured conduit.
    • Once in the secured conduit, ANYONE can then cause the DAI to be returned to the Vault.
    • ANYONE can then pay down the debt.

Scenario 2: Levers in the Trust Agreement

TLDR: the Trust (and Trustee) operates like a smart contact. They are indifferent about the politics of why, they just follow the agreement to the letter.

  • In the future, 6s has 80MM of debt outstanding against a 100MM debt ceiling. For whatever reason, MakerDAO reduces the 6s debt exposure to 50MM and 6s has a deal that needs to close the day after.
    • As a closing covenant (e.g. a condition to close outlined within the Credit Agreement), the LendCo must deliver a certificate to the Trustee outlining the then current debt ceiling. Based on the above, the Trustee will see that the debt outstanding is greater than the then current debt ceiling. In addition, the Trustee will independently verify the numbers presented. The Trustee would then not allow the closing to occur. Also important, 6s cannot draw new DAI from the Vault.
  • Similar to the above, 6s has 80MM of debt outstanding and 20MM of it is being paid back the day before a 6s desired closing (so there is money in the trust’s bank account).
    • The Trust agreement will include a verification of debt outstanding compared to debt ceiling. If the then current debt ceiling is lower than the loans outstanding, the funds in the account must be returned back to Maker (as outlined above via the secured conduit, with LendCo powerless to stop it). In that case, as available funds would have been sent back to Maker, LendCo would not be permitted to close.
  • For whatever reason, a liquidation order has been issued by the DAO. One of the Maker Representatives (@maarten, who is the VP of Transactions of the RWA International Ltd. aka “CayCo” or the Trust Sponsor) delivers notice of liquidation to the Trustee. In addition, the Trustee will be routinely monitoring the Vault liquidation status via the verification portal and may kick off the exact same process based on third-party verification from the Blockchain without a Maker Representatives engagement. This monitoring will be reoccurring and also measured at every closing and cash inflow / outflow (above a predefined amount).
    • This order must remain uncured (from Maker) for 30 calendar days before the trustee will start the liquidation process (this is to protect LendCOs against a governance attack).
    • Steps:
      • The Trustee will notify LendCo.
      • LendCo will do whatever it can to cure a theoretical breach.
      • On the assumption that the breach remains uncured, the Trustee will contact suitable buyers (e.g. credit funds) under the authority granted in both the Credit Agreement and Security Agreement. LendCo is powerless to stop any sale. The Security Agreement is not like a “prenuptial agreement” that would start a process, rather it is a “pre-divorce agreement” that finalizes the process.
      • Note: This is why it’s incredibly important that the DAO only permit Trust Companies with expertise in the lending sector to hold and disperse funds.
      • Proceeds from that sale are returned as outlined above sent back to the secured conduit.
      • NOTE: The exact same sequence will occur if the Trustee causes a liquidation, which it can do without the consent of the DAO, if the LendCo is in material breach of the covenants within the Credit Agreement (e.g. reporting requirements or maintaining equity, etc).

RE politics, similar to the aftermath of the 2008 financial crisis, no one wanted to foreclose on homes that were underwater. Trustees (protecting the trusts to which they had a fiduciary obligation) had no choice but to follow the agreements and bring in liquidation agents to foreclose assets accordingly and return the maximum principal. This is no different.

Trustee’s follow the agreements. The agreements must include enforceability opinions to ensure that they are consistent and enforceable under Law. The corollary to the smart contract work is that smart contract code may look great, but if REMIX won’t compile, it doesn’t matter. Think of the enforceability opinions as the Audit report for smart contract code.)