We have lately seen a lot of heat in the forum regarding how Real-World Assets should move forward. While some become uncomfortable with the idea of a DAO having an internal conflict, I see this as an opportunity to surface and fix all the issues pending to ensure that we move sustainably.
Back to the drawing board, then, where we can all zoom out and focus on building!
- I think RWF is an avenue (if not the avenue) that will bring Maker to the next level. Let’s scale it (in a sustainable way).
- I am not a Real-World Finance expert. I don’t even play one on TV.
- My initial attempt at a Framework provides more questions than answers. Ideally, the real experts will join me (or take over).
I don’t want to become an expert in real estate. Or farming. Or solar projects. Or invoice factoring. I assume most MKR holders share this feeling. We need the relevant Core Units, the Community, partners, and external experts to take care of the details.
MKR holders want RWF to move forward. That said, it might be unfair to assume that they have thoroughly read the implementation details and want things to proceed precisely as outlined. It is possibly a full-time job to keep up with what is happening in the Real-World Finance area within Maker, and I tend to believe that voters have perhaps other duties.
Is it if the code is buggy? Or if it can be improved? I would not want our Protocol Engineering team to avoid making improvements on some module “because the MKR holders voted for that specific implementation”. I want to think that any MKR holder will vote for a “better” implementation.
There are different degrees of risk that, ideally, we can price accordingly. That said, anything that could lead to a critical failure should be sandboxed, tested, and improved until it is not critical anymore.
We need a framework to evaluate, audit, and prioritize all the deals coherently. That should lead to more transparency, less second-thinking intentions, and more trust across the ecosystem.
The framework does not need to be perfect. It needs to be a model for all to agree on how to evaluate a deal. Ideally, anyone can propose ideas to improve it.
Much like the risk team has established assessments to evaluate collateral types (and the Community does many), we need to replicate this model to remove bottlenecks and standardize the process as much as possible.
Ideally, we have some checkmarks and checkpoints that each deal or collateral type needs to prove to unlock more debt ceiling, reduce stability fees, etc. We have many parameters to limit and charge for risk. We need our brightest to start working on this.
We need to define a way of abstracting all the deals and making sure that they are comparable.
Some starting points:
What are they? Are there different groups for them? What are acceptable ranges? Which ones could be changed unilaterally, which ones could not, and which ones might be?
- How are the parameters defined?
- How can they be changed?
- Is an email an acceptable method for communicating anything?
- Should Maker approve all changes by default?
- Should there be a different process for changing a parameter from a group to another group?
- Can or should an Asset Originator be able to change something? If yes, what? If no, how should Maker react?
- Which documents should be public? In which form
- Should there be any proxies? Should we have several actors representing different parties to avoid conflicts of interest?
- Is a proxy (trusted actor by Maker) reviewing the contracts enough? Should they be public? Will the Assets Originators accept that? All of them?
- What are the incentives for all the actors in the value chain? Is there any type of subsidy that might be skewing the numbers? Would any actor have a reason to apply favouritism? How can this be avoided?
- Which documents need auditing? At which point?
- Which firms could provide an audit? How do we measure their reputation?
- Is there any way to evaluate their independence (agency problem) by anyone interested in doing so?
- How are bugs defined? Who defines them?
- What should we do when a bug is found? What is the procedure?
- What happens with different types of bugs (based on criticality)?
- Who is in charge of the Post Mortem?
- Can this framework be compatible with the one for digital assets?
- Is it possible to improve that framework based on this one?