Attached is a paper I wrote as a Core Contributor to MakerDAO’s Collateral Engineering Service (CES) Core Unit, on challenges and issues related to the scaling of Real World Asset (RWA) collateral vaults at MakerDao - originally published on MakerDao’s Forum here.

MakerDAO collateral vaults were originally designed for margin lending against liquid collateral. Using MakerDAO’s current approach to on-boarding RWAs there are significant limitations on scalability as real world asset lending (where there are no liquid secondary markets in the underlying collateral) relies on a different lending and trust model than that used for margin lending against collateral with liquid secondary markets.

As a result, real world assets at MakerDao currently require manual liquidation and can potentially distort the realize profitabilty of these loans given the accounting currently used to determine MakerDao’s on-chain profitability as measured by the surplus buffer.

---

Collateral On-Boarding and Management of RWAs - Lessons Learned/Recommendations

By the end of 2022, based on the current pipeline of transactions, @CES is expected to have onboarded over $800 million in collateral to the Maker Protocol. The majority of this collateral has been related to Real World Assets. Providing CES with a first-hand view of the challenges, potential issues, and risks that onboarding and managing these collaterals exposes the protocol too.

Further learnings have also been gained from the assets we did not onboard, whether at the green-light stage or through a rejected government vote.

In this forum post, we discuss CES’s learnings concerning RWAs (MIP21s) and the collateral onboarding and management process. And propose CES’s recommendations concerning these learnings should continued use of MIP21 be required, pending and after implementation of the Endgame Plan.

CES’s objective in sharing these learnings and issues identified is to procure feedback from the community as to what areas we need to focus our innovation efforts on should further innovation be required moving forward.

Before going into detail about crucial CES learnings from collateral onboarding, we will review the MIP21 Toolkit that CES utilizes for the collateral onboarding and then discuss in depth the primary issues and deficiencies of using this toolkit for the onboarding of RWAs.

MIP21 Toolkit

Most of the learnings and issues identified herein relate to using MIP21 Toolkit, a toolkit that pre-dates the creation of the CES core unit. This toolkit was developed initially to provide a simple way for the Maker Protocol to experiment with small RWA transactions and appears to have been originally designed to allow for the on-chain abstraction of real-world asset transactions while minimizing any changes required at Maker Core.

This abstraction is required because the Maker Protocol was designed to accommodate crypto-native assets where the liquidity of underlying crypto assets is known, and oracles are available to provide reliable real-time pricing for the underlying assets placed as collateral in Maker’s vaults.

In contrast, for real-world asset deals, oracles providing reliable real-time indications of collateral values are not readily available, and valuation can be highly subjective and variable between different transactions. Furthermore, it is important to note that traditional finance lending principles dictate that collateral valuation be a secondary consideration in any credit risk assessment, with debt serviceability as the primary consideration, primarily due to liquidity issues concerning the underlying collateral.

In essence, the MIP21 Toolkit provides the following custom components:

1. Customized Urns - that provide variations of standard vault functions to allow various aspects of vault operations (minting dai, releasing/pledging collateral)
2. Custom Conduits - conduits that allow non-maker governance token holders to route and send/receive DAI and provide for routing changes on a permissioned basis. Recent conduits developed by CES add the capability to swap received or minted DAI for USDC from the PSM.
3. Customized Liquidation Oracle - that allows manual liquidation of collateral and provides functions detailing the current status of collateral

While this toolkit has served CES well in terms of being able to quickly onboard real-world assets, invariably, for recent deals (SocGen, HVB, Monetalis), we have had to customize new conduits and urns to facilitate the unique features of these transactions and the different ways in which these collateral vaults are managed. Over the past several months, this led to the creation of a new urn component (SocGen), a new Jar component (HVB) and new input and output conduits allowing DAI to be swapped to USDC from the PSM before being routed to its destination address.

In the next section of this post, we will focus on some of the deficiencies of MIP21 in allowing the on-boarding of assets at scale and the potential risks this exposes the MakerDao protocol to.

Lessons Learned/MIP21 Deficiencies

This section discusses the CES assessment of deficiencies concerning the MIP21 toolkit and other risk issues related to the onboarding of RWAs.

These learnings/deficiencies are primarily concerning the following:

1. scalability of transactions;
2. transparency; and
3. lack of collateral management

And are discussed in further detail below.

Collateral Valuation is Reliant on Centralized Off-chain Counterparties - With No Reliable On-chain Valuation

MakerDAO uses a placeholder ERC20 token for RWA transactions when using the MIP21 toolkit to represent/abstract the real-world collateral value. As there are no oracles used for valuing the RWA collateral, the assessment as to the collateral value of an RWA vault, in the absence of a CU mandated with this responsibility, is solely based on a subjective evaluation by individual Maker community members of reports posted to the forum by the RWA obligor/borrower. Upon casting the executive spell, the value of the placeholder token is generally set to the Debt Ceiling. Beyond the initial drawdown and until the vault is closed, the DAO’s only way of determining whether the value of the collateral has been impaired is the reporting made by the borrower.

A sample report for new silver is detailed here and for HVB here.

For most MKR governance token holders, these reports are meaningless. They do not indicate whether the investment (vault) is performing as it should and whether the asset/collateral value has been impaired. Understanding what these reports mean entails perusing 1000s of pages of transaction documentation. This approach is not scalable and places a potential existential risk for the protocol, as one failure could have significant consequences.

It should be noted that even the DAO’s cash-like investments are not immune to this risk. MakerDao’s cash-like RWAs are expected to significantly increase as we implement the Endgame Plan, as USDC is redeployed to earn income. There is no reason that simple oracles could not be developed for the automated monitoring and management of these investments, especially as the returns on these investments are highly sensitive to yield curve changes/interest rates.

The reality is that a slight change in the US treasury markets along the relevant yield curve could significantly impact the returns generated by some underlying cash-like investments, both positively and negatively. Combined with commissions that appear to be in the range of 0.3% for investment in cash-like securities/ETFs, high initial set-up and documentation costs and arrangement fees, the DAO could face a surprise when it requires funds to be distributed to the surplus buffer, especially if US Treasury bond markets have moved in the wrong direction.

To address these issues and facilitate the scalability of RWAs, new features need to be incorporated within MIP21 to ensure a more automated and objective approach to collateral management. While most of the changes required for MIP21 to facilitate scalability and transparency are technical and would need time for implementation. In the interim, we feel that the following approaches merit consideration by the community:

• Proactively require new borrowers/proposers to incorporate how they plan to automate and create DAO-friendly reporting terms and technical approaches within their proposals.
• provide details on how external APIs and oracles can be used to automate collateral management

Liquidation and Enforcement of Collateralization Ratios is a Manual Process With No Single Point of Responsibility

In the absence of the originating CU, there is no single point of responsibility for ongoing Collateral Management and Monitoring of Maker’s Real World Assets.

Liquidating a vault where payment obligations are not met currently relies on an astute community member determining that the RWA collateral underpinning a vault might be impaired. Under this scenario, the community member must initiate a governance vote proposing that the collateral vault be liquidated.

Without some level of automation in managing the liquidation of RWAs, there is a significant risk that problems with underlying Real World Assets may not be detected promptly. Further, not being able to see these issues on a timely basis could lead to further impairment of the realizable value upon liquidation.

Regarding our recommendations, we must explore ways to bring more data on-chain to facilitate automated liquidation based on objective metrics and benchmarks. From a technical perspective, several approaches could be explored here in terms of expanding the capability of MIP21 to facilitate automated liquidation and automated indicators of potential collateral impairment. These could potentially include the following:

1. Creating an RWA Token wrapper to facilitate the availability of basic financial instrument data such as interest rate, spread and payment frequency.
2. Using oracles, trustees, and centralized APIs to update on-chain data to facilitate basic collateralization or other objective metrics.
3. Modifying MIP21 urns to use relevant on-chain data to provide automated early warnings/liquidation triggers based on debt serviceability (as opposed to collateralization ratio).

In the interim, proposers/arrangers should be rewarded with better rates if their proposals address automated liquidation, as this type of automation would lead to lower investment risk.

It is essential to remember that automated liquidation would, for RWA, require some manual intervention once liquidation has been triggered to initiate the liquidation process with Real World counterparties, given the high illiquidity within private credit markets.

While there are established secondary markets in distressed private credit, unfortunately, these are not yet automated. For the DAO to pursue liquidation, legal counsel will likely need to be retained as well as credit specialists. The associated costs of liquidation are likely to be significant. They will generally be larger for more complex transactions, especially as the liquidation of loans advanced by DAOs is relatively untested and without precedent. As a result, we would recommend that the DAO favour transactions with an established secondary market in the underlying collateral, even if not on-chain.

Stability Fees For RWA Provide No Objective Early Warning Signals For Potential Problem Vaults And Could Significantly Overstate The Surplus Buffer

The valuation of RWA collateral is subjective, mainly due to significantly less market liquidity for TradFi deals. In the TradFi world, the primary focus is on debt serviceability rather than collateral value. Aside from customary covenants covering cash flow and debt service ratios, most of these transactions contain, at a minimum, a single objective covenant to determine whether a transaction/loan is in default and should be liquidated. Namely, the non-payment of interest and principal when due.

So even if a borrower were to provide fraudulent reports concerning meeting other covenants and metrics or the calculation of these covenants were disputed. With the requirement to pay principal and interest payments periodically (monthly, quarterly, semi-annually), the lender/investor in the transaction would have an early warning of underlying issues with the financed assets and could very quickly take actions to protect and optimize the realizable value of any collateral.

MakerDAO’s Stability Fees have been designed for crypto-native assets where the near real-time automated valuation of these assets through oracles is possible. Under the crypto-native use case, where there is a high degree of confidence in the collateral valuation, then it is appropriate to capitalize the interest and accrue the stability fee as vault debt, as upon automated liquidation, there is a high probability that the accumulated stability fees (accrued every second) will be realized and that the reported surplus buffer balance reflects actual earnings from vault fees.

Essential questions need to be asked when considering whether a stability fee is appropriate for an RWA vault that is expected to be open for more than 6-12 months. Especially if the underlying collateral has illiquid secondary markets. The most important question is - Is there potential for collateral impairment, whether by loan mismanagement or by a bad actor? The reality here is while the stability fee is accruing as vault debt, its actual realization will never occur until the closure of the vault - presumably at the end of the loan term. Not only could we face non-realization of the accrued stability fee income in the case of complete mismanagement - but we may also encounter the unpleasant surprise of a partial or complete write-off of the underlying investment if the collateral value has been impaired.

More importantly, depending on how accrued stability fees are recognized in the surplus buffer, the accrual of stability fees on real-world asset vaults may significantly overstate the Surplus Buffer. The amount of potentially unrealizable stability fees within the Surplus Buffer increasing as we have high growth in real-world assets, especially for vaults that will be open for more than one year.

As a final consideration, from a risk perspective, utilizing the stability fee to generate the yield on RWA collaterals for underlying vaults that are expected to remain open for more than one year should only be permitted selectively for the lowest-risk collateral. As effectively, allowing the stability fee to return any yield to the Maker Protocol is akin to allowing the borrower to issue a zero coupon bond. A practice that even in liquid bond markets is considered to be only available to the highest credit-rated government and investment grade borrowers.

In addressing these deficiencies, we propose that the community consider the following recommendations and approaches.

• in the short term, restrict usage of accrued vault stability fees for RWA vaults expected to remain open for more than 6-12 months to only the lowest risk RWA asset transactions - ideally with more liquid underlying investments. Instead, consider the use of a jar with required periodic payments to the surplus buffer
• in the medium term, bring more data on-chain to facilitate the automatic verification of jar payments and or facilitate early warnings of potential collateral impairment

MIP21 Requires Technical Customization For Each RWA Limiting Scalability

As discussed above, Maker has experimented with RWAs using MIP21. With each experiment, CES CU has inevitably had to make new MIP21 components to ensure viable technical implementations with a single abstract token representing the transaction on-chain.

This entails a significant amount of engineering resources (depending on the complexity of the transaction, this could involve 2-3 engineering resources over two two-week sprints). Any smart contract code changes to the Maker Protocol must be carefully architected and reviewed before implementation to protect the protocol’s security, ensure coverage of all technical and RWA risks and determine whether additional security audits need to be obtained. The CES process is as follows:

Step	Task
1	Completion of a detailed transaction and technical assessment
2	Architecting using MIP21 an appropriate smart contract structure for the transaction and determining any new smart contracts or modifications required
3	Review of the proposed transaction structure with PE CU to define final transaction specs and whether any audit will be necessary
4	Smart Contract development and testing for the proposed design. CES code reviews
5	When final, generally a PE code review before opening a MIP21 PR
6	Coding of the spells to deploy the transaction on Goerli and Mainnet
7	Hand over of final code for final spell pull request

For every RWA transaction completed to date, custom modifications and new components (Urns, OutputConduits, InputConduits, Jars, Keeper Jobs) have been required to implement each deal requiring significant engineering effort primarily from CES for the actual development work and from PE resources to review the proposed implementation. The modifications have focused on finding the safest implementation with minimal changes to MIP21, and have not addressed more efficient collateral monitoring and management.

From a resourcing perspective, this approach is not scalable for RWAs, and the requirement for customization for each RWA transaction being considered will become a bottleneck for RWA integrations.

Our recommendation to ensure optimal usage of scarce engineering resources is that before finalizing any proposal for an RWA transaction, the originating/structuring team proactively consults with CES to ensure that a transaction is structured to minimize technical resources.

Limited Innovation in the Traditional Financing Process To Date

Amongst Defi Protocols, Maker is more advanced than other protocols with respect to real-world asset financing.

Notwithstanding this, it is important to note that Defi protocols and blockchain technology have not led to significant innovation in traditional financing. While many observers had predicted that smart contract technology and blockchains would lead to disintermediation in the traditional financing process and more efficiency in raising and providing access to capital, this has not occurred.

CES speculates that the main reason for little innovation has been applied to date is the deal pipeline and, more specifically, the types of arrangers structuring these deals. Specifically, we have seen arrangers for Defi transactions tend to be counterparties with significant traditional financing experience (lacking smart contract expertise) or, conversely, arrangers with significant technical Defi experience (lacking financial experience).

If disintermediation of traditional financing occurs, it will require the transaction arranger/structurer to work closely with technical specialists to identify areas ripe for disintermediation. This had already started in MakerDao, where CES worked closely with transaction originators to identify areas where technology could be used to enhance financings; examples of this are CES feedback provided in transactions and proposals such as those for HVB and Maple Finance.

One area ripe for innovation is currently amongst the various nascent digital asset trustees and custodians, who are proactively interested in finding new and unique approaches to digital asset custody. Especially relevant concerning the recent Celsius and Three Arrows Capital bankruptcies.

Furthermore, nearly every traditional finance custodian is exploring how they can participate in the digital assets space, especially as many of these institutions now have traditional fund clients seeking to custody digital assets. From that perspective, CES believes that a technical-driven approach which provides solutions for tokenizing assets at scale could lead to significant innovation and growth for Defi protocols such as Maker.

Summary

Within this post - we have shared CES’s assessment of some of our key learnings from onboarding RWAs and the challenges the Maker Protocol has faced. While the Endgame Plan leaves some uncertainty concerning how Real World Assets will be onboarded as we move through the PreGame and then the EndGame. We must share these learnings with the Maker Community and use them as we move forward in onboarding RWAs during the Pregame and as MakerDao develops detailed plans for the MetaDao Scopes and Vault Adoption by the MetaDaos.