TL;DR Split RWF into two CUs – one focused on negotiation of terms and one focused on risk assessment.
MakerDAO has the distinction of being a first-mover in the financing of real-world assets (RWA). As the protocol attempts to scale exposure to RWA, it is time to implement a process that is as rigorous and responsible as the one we utilize for onboarding new crypto assets.
To date, Maker’s process of onboarding and monitoring RWA is entirely centralized within the RWF CU. This was convenient when staff was limited and resources available were small. But just as regulated financial institutions are required to institute better internal controls as they become large enough to afford them, so should Maker.
At present, MIP6 applications are presented on the forum. This allows the community to ask initial questions and become familiar with applicants. This is a good beginning to the process and should be retained.
From here, however, the process needs an upgrade. Ironically, TradFi practices are much more decentralized – for a reason – than our own. As a starting point, we should look at something similar and then iterate to suit Maker’s specific needs.
The RWF CU should be split into two – one that is a “business” RWF CU and one that is a “risk” RWF CU. The roles of negotiating the best possible terms for Maker and that of risk assessment should not be housed within the same unit.
This lowers potential conflicts of interest, and also encourages multiple sets of eyes on the details of a deal, which needs not only a legal evaluation but also an economic one. This also prevents the siloing of information within a single CU or person.
These two separate CUs would then make the case for or against an MIP6 application before MKR holders.
The “business” RWF CU would have responsibilities for getting Maker the best deal possible in economic terms. Currently no one fulfills this role today, as deals have largely been of the “take it or leave it” sort. This makes sense in the case of securities, but Maker has clearly suffered by being absent from the bargaining table.
The “risk” RWF CU would have responsibilities for ensuring Maker was not taking on large amounts of risk without proper disclosure or emphasis. Examples of risks that a “risk” RWF CU would raise a warning about:
- No legal review of documentation to make sure it operates as assumed
- Incomplete restrictions on use of funds by borrower
- Incomplete bankruptcy remoteness
- The extent to which collateral is under Maker’s control either legally or in a smart contract
- Incomplete or inaccurate descriptions of what the end collateral is or is not
- Maturity/credit risk
- Presence/absence of independent documentation/verification beyond borrower-reported information
- Extent of buyback agreements or other forms of liquidity upon exit
- Ability for borrowers to alter terms without the affirmative assent of senior creditors
Both CUs would be jointly responsible for monitoring active credit lines. This keeps multiple sets of eyes on a project, each with a specialty. It also provides some level of redundancy to ensure credit lines are actually being monitored on a regular schedule.
Given that Maker wishes to offer financing across multiple, very different asset classes, a serious effort should be made to staff these RWF CUs with professionals that have experience in both the process of structured credit and the underlying assets. Those need not be the same people, and they need not be actual employees of a CU. There is no shortage of places to outsource some of this work to complement our own internal staff.
Maker is moving into a very lucrative, but very, very dangerous area of revenue-based finance. And our track record to date has been, quite frankly, subpar. Our great victory is that we have successfully bootstrapped a RWA program into existence, but we are already encountering significant problems. Those problems are directly linked to our own lack of well-developed process for non-crypto assets.
Just as we would never onboard a new crypto asset without independent reviews by such diverse stakeholders as Protocol Engineering, Oracles, and Risk, we should not be onboarding real-world assets without independent review by more than a single CU attempting to wear every hat at once.
To execute on this more professional process, we will also need to make sure there is high-caliber leadership and staff inside both the “business” and “risk” RWF CUs. I have no doubt that the current RWF full- and part-time employees would find a good fit in one or both core units.
The above proposal to split RWF into two CUs and reintroduce some level of adversarial thinking will both decentralize and de-risk our program as a whole. This is obviously not a very granular proposal, and suggestions for finer details are welcome as we get the conversation going.