# A technology-driven approach to RWA [DRAFT - MORE WORK TO DO]

To date, MakerDAO's experience with RWAs has primarily focused on small experiments - using MIP21. While MIP21 has been adequate for conducting these experiments and integrating these transactions with the MakerDAO protocol, CES has learned several lessons from these integrations.

In addition, the proposed off-boarding of the RWF Core Unit has highlighted additional deficiencies in the processes in place for ongoing collateral monitoring and management of RWA. CES believes that if MakerDAO is to scale its RWA exposure, whether under the endgame plan or otherwise, these deficiencies need to be addressed through technical changes to MIP21 and by taking a technical-driven approach to RWA.

CES believes that failure to address the deficiencies in MIP21 and Makers' collateral monitoring and management processes will limit MakerDAO's ability to scale and manage new RWAs effectively and potentially expose MakerDAO to significant existential risk unless addressed.

Summarized below are some critical lessons learned in implementing MIP21 and the identification of deficiencies we believe would be essential to address.

## Lessons Learned/MIP21 Deficiencies

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

MakerDAO uses a placeholder ERC20 token for RWA transactions to represent 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 MKR token holders of reports posted to the forum by the RWA obligor.

The reality is that given the extensive and complex reporting required for these RWAs and the complexity of the RWA transactions, most MKR token holders would not have the requisite knowledge to assess whether the RWA is performing as required and to decide whether the collateral value is impaired. This could lead to potential delays in identifying problem RWAs, and in a worst-case scenario no identification of a problematic RWA until repayment of vault debt is required.

For MakerDAO's initial experiments in RWA, the implicit assumption was that the originating CU - RWF - would ensure ongoing monitoring and management of RWA collateral and that this core unit would be staffed with the appropriate personnel to monitor and manage this collateral. Even if RWF were not off-boarded, this approach would not be scalable. Ultimately, RWF would have needed to staff the credit monitoring and management functionality much like a TradFi institution - to ensure effective management of RWA transactions using MIP21.

With the off-boarding of RWF and without changes and enhancements to MIP21 or the implementation of automated methods of collateral monitoring and management, identification of issues with RWA transactions is now solely adhoc and dependent on the assumption that one astute MKR token holder understands RWA and the complex transaction legal documentation and cares enough to read reports posted to the forum to decide whether collateral values and RWA obligations are being adhered to.

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.

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

In the absence of the originating CU, liquidating a vault where payment obligations are not met relies on an astute governance holder determining this. The implicit assumption is that there is at least a single governance token holder reading the detailed reports posted to the MakerDAO forum and manually reconciling that the actual payments received from the underlying real-world asset have been made as required or whether the RWA vault needs liquidation.

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

### 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, 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.

However, for real-world assets, especially for medium to longer term transactions, where the underlying RWAs within the vault may have a different interest rates (rates are floating based on SOFR, or US Treasury Benchmarks) and payment profiles (i.e. amortizing, revolving) - the expected vault yield is likely to be highly variable. Using a stability fee, for these cases, is not practical and if used would potentially exposes Maker to the risk of never realizing the stability fee if the vault is never closed.

More importantly, if the plan is to use the Surplus Buffer balance reported at any point in time to invest the surplus buffer in other assets such as staked ether or to make other DAO decisions, **Maker could be faced with the situation that the fees that have been accrued within the surplus buffer may be significantly overstated and in-fact may not be realizable**. This applies, regardless of whether the RWA is cash-like or otherwise, as defined in the endgame plan.

Notwithstanding, RWAs are proportionately a relatively small part of the DAOs collateral, with the move to invest Maker's USDC into bonds and in the endgame plan to grow assets significantly before reaching Eagle/Phoenix stance, more prudence is required in the use of the Stability Fee for these assets. As the income from these RWAs will become a significant portion of DAO reported income, and from an accounting perspective for RWAs, that income and the surplus buffer balance may significantly deviate from the income that has been reported depending on how the Stability Fee is implemented.

### 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 2 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 required|
|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.

### Summary - Lessons Learned

The use of MIP21 to date for collateral onboarding of RWA has been predicated on the assumption that a dedicated core unit is in place to provide ongoing collateral monitoring and management.

Given the off-boarding of RWF, if the DAO plans to scale RWAs moving forward, whether under the endgame plan or otherwise MIP21 will be a significant constraint to scaling and efficient collateral monitoring and management.

Failure to address these deficiencies and modify MIP21 to accomodate more automation could potentially expose MakerDAO to losses. Also, if Maker onboards a higher percentage of its "balance sheet" in RWA, ensuring confidence and transparency in the values and data being reported for RWA will be essential.

Notwithstanding, RWAs are proportionately a relatively small part of the DAOs collateral, with the move to diversify USDC collateral into bonds and in the endgame plan to grow assets significantly before reaching Eagle/Phoenix stance, more prudence is required as the income from these RWAs will become a significant portion of DAO reported income. It will be essential to ensure that reported income is realizable, especially when a Stability Fee is set for an RWA vault.

## A Technical Driven Approach to RWA

If we are to scale RWAs moving forward, whether cashlike, clean-money or otherwise, the drawbacks of MIP21 detailed above need to be addressed. CES believes that failure to address these deficiencies significantly increases the existential risk to the Maker Protocol.

To address the deficiencies and scalability issues detailed above, **CES believes it is necessary to re-architect MIP21 and create a decentralized and automated approach to collateral monitoring and management**. Specifically, the objective of our technical driven approach would be in the short term, to allow for the following:

1. Automated liquidation for non-payment of fees, interest or debt principal when due - by making available objective RWA data on chain, so at a minimum liquidation can be automated for non payment of debt principal or interest when due;
2. Development of a new RWA Token/Token wrapper that will facilitate representation on-chain (or within immutable storage) of basic financial data, and at a minimum can be used as a stand-alone representation of the underlying RWA collateral to be liquidated;
3. New urns with the capability to use on-chain data to trigger objective covenant violations dealing with the aggregate collateral, i.e. portfolio debt service coverage portfolio defaults.
4. Urns that allow for multiple classes of debt - ie. Junior and senior debt levels
5. A "keeper" system in conjunction with the above changes to facilitate automated collateral monitoring and management as well as management of liquidations.
6. Automated reporting systems for trustee reporting as an alternative to forum posts. This will entail appropriate interfaces to allow our Trustees to complete transaction reporting directly on chain or within off-chain immutable storage.

Furthermore, with the development of innovative new multichain messaging systems (Maker Teleport), it may be possible to implement these systems without incurring extensive gas costs by using L2s.

To date, DeFi Protocols and blockchain technology have contributed little to minimal innovation to the Traditional Financing Process; RWA experiments have been about taking traditional financing structures and adding additional intermediaries and complexity. With the recent addition of new more innovative transaction structures for HVB and SocGen, we believe we can pursue new strategies to work with arrangers at scale by taking the above approach and using blockchain technology to disintermediate some of the existing counterparties involved in a traditional financing.

With the above technical capabilities in place, Maker will be better equipped to scale and manage RWA collateral as MakerDAO moves between the various stances described in the endgame plan (Pigeon/Eagle/Phoenix).

But the biggest benefit of the above approach is it allows a ProtectorDAO or other CUs to take a proactive approach to scale RWA deals as well the wholesale funding of other real world protocols (i.e. Centrifuge/Maple etc). Specifically, we could envision the following strategies:

## **HVB Like Deals**

Investing in bank participations where the originating bank is required to keep a significant portion of the syndicated loan is attractive for the following reasons:

- The bank has money in the game with the same risk exposure as MakerDAO and is therefore incented to optimize recovery value as losses are shared parri-passu with all participants
- The standards for structuring bank loan syndications and participations are globally accepted and fairly standard
- Through the HVB structure, MakerDAO can be selective about the classification and types of loans that are participated, i.e. loan terms and types
- Potential target arrangers for these transactions include banks in 63 countries adhering to BIS practices.
- There is a secondary market for bank participations.

A MetaDAO/Core Unit could implement a proactive strategy to assess and target, globally, potential arrangers that we could work with. In addition, we could selectively target short-term loans, trade financing, and clean money loans. Critical to the success of this type of strategy would be:

1. Assessing and determining the most attractive arranger banks (because target banks are BIS reporting banks - there is readily available information that would allow a credible marketing strategy to determine the banks we would want to work with)
2. Identify reputable security agents, lawyers, and trustees operating in these markets that can allow us to modify our current agreements to ensure compliance with legal requirements in those markets.

## RWA Protocol Tokens (Centrifuge and other RWA protocols)

Even when lending to other protocols, we are not immune to the deficiencies in MIP21 detailed above; by implementing the above technical changes, we are equipped to scale our indirect RWA investments through other protocols significantly. Furthermore, vaults/urns that allow us to customize the amount of Junior Cover enable arrangers to easily provide additional credit enhancement to address deficiencies in underlying protocols, so for example, an investment in an RWA pool of LP tokens could easily be enhanced without having to make changes within the underlying target protocol tokens.

In the case of a vault using centrifuge tokens, the most significant benefit is eliminating the need for extensive forum posts and reports that are required to track ongoing portfolio performance; instead, custom token wrappers would allow us to access the data on-chain or from ipfs.

From a marketing and implementation perspective, to expand the potentially available arrangers for these types of deals - CES would proactively assess other credible RWA protocols to prioritize viable target protocols and work with a marketing team to scale these RWAs.

In addition, with the enhancements proposed for MIP21, we can potentially use the developed token wrappers and custom urns to pursue other low-risk RWA financing, such as supply chain financing.

## CashLike RWA Deals

The Monetalis type of structure could significantly benefit from the technical enhancements completed above - our trustees could work with the Custody Agents and other Security Agent APIs to ensure an automated approach to tracking in near real-time the various real-world cash-like positions, providing a more reliable and near real-time updated valuation of MakerDAO's investment positions.

As more of our USDC is invested in cash-like RWAs for diversification, it will be essential to have access to real-time, reliable data, as real-time changes in bond markets could lead to significant changes in our collateral values.

## Clean Money [to do]

## Endgame Technical Enhancements D3M [to do]